Rancher Communicating with Downstream User Clusters

이 문서는 Rancher가 하위 클러스터들과 통신하는 방법에 대해 설명합니다.

Rancher는 여러 개의 쿠버네티스 클러스터를 관리하는 플랫폼입니다.

Rancher는 어떻게 하위 클러스터를 프로비저닝하고 관리하는지 알아보도록 하겠습니다.

Rancher Docs에서 설명하는 하위 클러스터와의 통신 방법입니다.

위 그림의 숫자는 다음 설명과 같습니다.

The Authentication Proxy
Cluster Controllers and Clutser Agents
Node Agents
Authorized Cluster Endpoint

1. The Authentication Proxy

이 다이어그램에서 Bob이라는 사용자는 User Cluster 1이라는 하위 사용자 클러스터에서 실행 중인 모든 Pod를 보려고 합니다.
Rancher 내에서 Bob은 kubectl Pod를 확인하는 명령어를 실행할 수 있습니다.
Bob은 Rancher의 인증 프록시를 통해 인증되었습니다.

인증 프록시는 모든 Kubernetes API 호출을 하위 클러스터로 전달합니다.
로컬 인증, Active Directory, GitHub와 같은 인증 서비스와 통합됩니다.
인증 프록시는 모든 Kubernetes API 호출 시 호출자를 인증하고 적절한 Kubernetes 가장 헤더를 설정한 후 Kubernetes 마스터로 호출을 전달합니다.

Rancher는 서비스 계정을 사용하여 Kubernetes 클러스터와 통신합니다 .
Rancher의 각 사용자 계정은 하위 클러스터의 해당 서비스 계정과 연결됩니다.
Rancher는 서비스 계정을 사용하여 사용자를 가장하며, 이를 통해 사용자가 가져야 할 모든 권한을 부여받습니다.

기본적으로 Rancher는 Rancher 서버를 통해 하위 사용자 클러스터의 Kubernetes API 서버에 연결하기 위한 자격 증명이 포함된 kubeconfig 파일을 kube_config_rancher-cluster.yml 로 생성합니다.
kubeconfig 파일에는 클러스터에 대한 전체 액세스 권한이 포함되어 있습니다.

2. Clutser Controllers and Clutser Agents

Rancher는 Cluster Controller와 Cluster Agent를 Tunnel로 구성하여 하위 클러스터의 정보를 수집하고 명령을 전달합니다.

각 하위 사용자 클러스터에는 클러스터 에이전트가 있으며, 이 에이전트는 Rancher 서버 내의 해당 클러스터 컨트롤러로 터널을 엽니다.

각 하위 클러스터마다 클러스터 컨트롤러와 클러스터 에이전트가 하나씩 있습니다. 각 클러스터 컨트롤러는 다음과 같습니다.

2.1. Rancher Cluster Controller

– 하위 클러스터의 리소스 변경 사항을 감시합니다.

– 하위 클러스터의 현재 상태를 원하는 상태로 만듭니다.

– 클러스터 및 프로젝트에 대한 액세스 제어 정책을 구성합니다.

– GKE와 같은 필수 Docker 머신 드라이버 및 Kubernetes 엔진을 호출하여 클러스터를 프로비저닝합니다.

기본적으로 Rancher가 하위 클러스터와 통신할 수 있도록 클러스터 컨트롤러는 클러스터 에이전트에 연결합니다. 클러스터 에이전트를 사용할 수 없는 경우 클러스터 컨트롤러는 대신 노드 에이전트에 연결할 수 있습니다.

2.2. Rancher Cluster Agent

– Rancher로 시작 된 Kubernetes 클러스터의 Kubernetes API에 연결합니다.

– 각 클러스터 내의 워크로드, Pod 생성 및 배포를 관리합니다.

– 각 클러스터의 전역 정책에 정의 된 역할과 바인딩을 적용합니다.

– 클러스터와 Rancher 서버 간에 이벤트, 통계, 노드 정보 및 상태에 대한 통신을 제공합니다.

(클러스터 컨트롤러와의 터널을 통해)

2.3. remotedialer

Rancher는 Cluster Controller와 Cluster Agent를 Tunnel로 구성하여 하위 클러스터의 정보를 수집하고 명령을 전달합니다. 라고 Rancher Docs에서 설명하고 있습니다.
이 Tunnel의 핵심 구현체는 바로 Rancher의 remotedialer 입니다.

자체 엔진인 RKE, RKE2 뿐만 아닌 EKS, GKE 또는 직접 설치한 쿠버네티스 등 다양한 플랫폼에 올라가 있는 쿠버네티스 클러스터 지원을 가능하게 하는 핵심 기술입니다.

remotedialer를 쉽게 이해하기 위해, ssh 리버스 터널링에 대한 개념을 짚고 넘어가겠습니다.

SSH 리버스 터널링(Reverse Port Forwarding)은 외부에서 직접 접근할 수 없는 내부 시스템에 대해, 내부 시스템이 먼저 외부로 연결을 맺고 그 연결을 통해 외부에서 내부로 접근할 수 있도록 하는 기술입니다.

일반적인 SSH 접속 (Forward 방향)

먼저 일반적인 SSH 접속 구조는 아래와 같습니다.

[내 PC] ───────▶ [서버]

(22/tcp)

SSH 리버스 터널링 구조

SSH 리버스 터널링에서는 연결 흐름이 반대가 됩니다.

[내부 서버] ───────▶ [중계 서버 (Public)]

(ssh outbound)

[외부 사용자] ─────▶ [중계 서버:포트]

└──▶ [내부 서버:서비스 포트]

SSH 리버스 터널링 동작 방식

내부 서버가 외부에 노출 된 중계 서버로 SSH 연결을 먼저 생성하고
이 때 -R 옵션을 사용하여 중계 서버의 특정 포트로 들어오는 연결을 내부 서버의 특정 포트로 전달 하도록 설정합니다.
외부 사용자는 중계 서버의 포트로 접속하지만 실제로는 내부 서버의 서비스에 접근하게 됩니다.

SSH 리버스 터널링 명령 예시

ssh -R 8080:localhost:80 user@test.example.com

해당 명령의 의미는 다음과 같습니다.

test.example.com:8080으로 들어오는 모든 연결을 SSH 연결을 통해 내부 서버의 localhost:80 으로 전달합니다.

Rancher remotedialer

SSH 리버스 터널링의 기술을 WebSocket + net.Dial 추상화로 재구현한 기술입니다.

Rancher remotedialer는 SSH 리버스 터널링과 유사하게, NAT 또는 방화벽 뒤에 있는 클러스터에서 Rancher Server로 outbound 연결을 먼저 생성합니다.

이 연결은 WebSocket 기반으로 유지되며, 단일 연결 위에서 다수의 net.Dial 요청을 멀티플렉싱하여 처리합니다.

그 결과 포트 포워딩이 아닌 연결(스트림) 단위의 터널링을 제공하는, Kubernetes 관리 환경을 위해 설계된 reverse dial 프록시입니다.

[Rancher Server]
└─ Cluster Controller
↑ (Tunnel / WebSocket)
↓
└─ Cluster Agent
↑
Kubernetes API / Node / Kubelet

Data flow

remotedialer와 ssh 리버스 터널링의 공통점

NAT / 방화벽 뒤 등 접근이 불가능한 내부 리소스에 접근하기 위한 목표를 가진 기술
내부 시스템이 외부로 Outbound 연결을 먼저 생성
해당 연결을 재사용하여 외부에서 내부 서비스에 접근이 가능

remotedialer와 ssh 리버스 터널링의 차이점

rancher remotedialer

– net.Conn 기반 / 애플리케이션 레벨 / net.Dial() 추상화 / 코드가 동적으로 Dial 요청 -> Cluster Agent가 수행

ssh 리버스 터널링

– 포트 기반 / OS 네트워크 레벨 / ssh -R 포트:호스트:포트 개념 / 사람이 터널 정의

3. Node Agents

클러스터 에이전트(cattle-cluster-agent)를 사용할 수 없는 경우 노드 에이전트 중 하나가 클러스터 컨트롤러와 터널을 생성하여 Rancher와 통신합니다.

cattle-node-agent는 DaemonSet 리소스를 사용하여 배포되므로 Rancher로 시작된 Kubernetes 클러스터의 모든 노드에서 실행됩니다. 이 에이전트는 클러스터 작업을 수행할 때 노드와 상호 작용하는 데 사용됩니다. 클러스터 작업의 예로는 Kubernetes 버전 업그레이드, etcd 스냅샷 생성 또는 복원 등이 있습니다.

4. Authorized Cluster Endpoint

Authorized Cluster Endpoint (ACE)를 사용하면 사용자는 Rancher 인증 프록시를 거치지 않고도 하위 클러스터의 Kubernetes API 서버에 연결할 수 있습니다.

*** ACE는 Rancher에 프로비저닝되거나 등록된 RKE2 및 K3s 클러스터에서 사용할 수 있습니다.
Amazon EKS와 같은 호스팅 Kubernetes 공급자의 클러스터에서는 사용할 수 없습니다 ***

사용자가 인증된 클러스터 엔드포인트가 필요한 주요 이유는 두 가지입니다.

Rancher가 다운된 동안 하위 사용자 클러스터에 액세스 하기 위해
Rancher 서버와 하위 클러스터가 멀리 떨어져 있는 상황에서 지연 시간을 줄이기 위해

kube-api-auth 마이크로서비스와 Authorized Cluster Endpoint

kube-api-auth 마이크로서비스는 Authorized Cluster Endpoint(ACE) 를 위한 사용자 인증 기능을 제공하기 위해 배포됩니다.

사용자가 kubectl을 통해 사용자 클러스터에 접근할 경우, 해당 클러스터의 Kubernetes API 서버는 웹훅(Webhook) 방식으로 kube-api-auth 서비스를 호출하여 사용자를 인증합니다.

Authorized Cluster Endpoint와 마찬가지로, kube-api-auth 인증 서비스 또한 Rancher를 통해 생성된(Rancher-launched) Kubernetes 클러스터에서만 제공됩니다.

예시 시나리오

Rancher 서버가 미국에 위치해 있고, 사용자 클러스터 1이 호주에 위치해 있다고 가정해보겠습니다. 사용자 Alice 역시 호주에 거주하고 있습니다.

Alice는 Rancher UI를 통해 사용자 클러스터 1의 리소스를 조작할 수 있지만, 이 경우 요청은 다음과 같은 경로를 거치게 됩니다.

호주(Alice) → 미국(Rancher Server) → 호주(User Cluster)

이처럼 지리적으로 먼 거리를 왕복하게 되면 상당한 네트워크 지연(latency)이 발생할 수 있습니다.

Alice는 Authorized Cluster Endpoint를 사용함으로써 이러한 지연을 줄일 수 있습니다.

Authorized Cluster Endpoint 사용 시 동작 방식

Authorized Cluster Endpoint가 해당 downstream 클러스터에 활성화되면, Rancher는 클러스터에 직접 연결할 수 있는 추가 Kubernetes context를 kubeconfig 파일에 생성합니다.

이 kubeconfig 파일에는 다음과 같은 정보가 포함됩니다.

kubectl을 위한 인증 정보
helm을 위한 인증 정보

이를 통해 사용자는 Rancher 서버를 경유하지 않고, 클러스터의 Kubernetes API 서버에 직접 연결하여 리소스를 관리할 수 있습니다.

참고 문서

https://github.com/rancher/remotedialer

https://ranchermanager.docs.rancher.com/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters

자유롭게 댓글을 달아주세요! 언제나 환영합니다.
기타 문의: info@neoclova.co.kr
네오클로바 기술블로그 홈 바로가기: https://neoclova.net
네오클로바 홈페이지: http://neoclova.co.kr

Post Views: 98