꾸준히 오래오래

데이터 엔지니어의 공부 곳간✏️

Data/Kubernetes

[Kubernetes] 쿠버네티스 클러스터 아키텍쳐

zzi_yun 2024. 3. 24. 22:10

노드

쿠버네티스 워커머신으로 각 노드는 컨트롤 플레인에 의해 관리된다.

하나의 노드는 여러 개의 파드를 가질 수 있으며, kubelet과 컨테이너 런타임 그리고 kube-proxy로 구성된다.

 

노드 상태

노드의 상태의 경우 다음과 같이 확인 가능하다.

kubectl describe node <insert-node-name-here>

여기서 얻을 수 있는 상태 정보의 경우는 다음과 같다.

  • 주소
    • HostName(노드의 커널에 의해 알려진 호스트명)
    • ExternalIP (외부로 라우트 가능한 ip)
    • InternalIP(클러스터 내에서만 라우트 가능한 ip)
  • 컨디션
    • 먼저, conditions 필드는 모든 Running 노드의 상태를 기술한다.

  • 그 외에 용량과 할당 가능 그리고 기타 세부 정보
    • 노드 상에 사용 가능한 리소스
    • 커널 버전, 쿠버네티스 버전, 컨테이너 런타임 상세 정보 등

 

컨트롤 플레인 - 노드 간 통신

노드에서 컨트롤 플레인으로 통신

노드 또는 파드의 모든 API 사용은 API 서버에서 종료된다.

다른 컨트롤플레인 컴포넌트 중 어느 것도 원격 서비스를 노출하도록 설계되지 않았다.

API 서버는 하나 이상의 클라이언트 인증 형식이 활성화된 보안 HTTPS 포트(일반적으로 443)에서 원격 연결을 수신하도록 구성된다.

노드는 kubelet을 통해서, 파드는 서비스 어카운트를 활용하여 kube-proxy를 통하여 API 서버의 HTTPS 엔드포인트로 리디렉션 되는 가상 IP주소를 통해 보호되어 통신이 가능하다.

 

노드는 kubelet을 통해서 API 서버와 통신하고 파드는 서비스 어카운트나 액세스 토근을 사용하여 kube-proxy를 통한 네트워크 통신을 통하여 API 서버와 통신한다.

 

컨트롤 플레인에서 노드로 통신

  1. API서버에서 kubelet으로 통신
    1. 파드에 대한 로그를 가져오거나, 실행 중인 파드를 연결하거나, kubelet의 포트-포워딩 기능을 제공하는 방식
  2. API 서버에서 노드, 파드 및 서비스로의 통신
    1. 안전하지 않다.

리스(Lease)

모든 노드에 같은 이름을 가진 Lease 오브젝트가 kube-node-lease 네임스페이스에 존재한다.

노드 하트비트 및 컴포넌트 수준의 리더 선출과 같은 시스템 핵심 기능에서 사용된다.

리스 API를 사용하여 kubelet 노드의 하트비트를 쿠버네티스 API 서버에 전달한다.

 

컨트롤러

컨트롤러 루프는 시스템 상태를 조절하는 종료되지 않는 루프이다.

쿠버네티스는 이 컨트롤러를 통해서 사용자가 의도한 상태로 클러스터를 유지하기 위해 관찰하고, 필요 시에 생성 혹은 변경을 요청하는 작업을 한다.