Kubernetes: Nodes 이해하기

Posted on by
Contents hide
1 Kubernetes Nodes
1.1 Concept
1.2 Minion
1.3 Key elements of the node
1.4 Node type
1.5 Node management
2 What is kube control?
2.1 Concept of kubelet
2.2 Features
3 What is kube-proxy?
3.1 Concept
3.2 Features
4 What is CNI Pluggin?
4.1 Concept
4.2 Features
5 Additional
5.1 kubectl apply –dry-run=client -f [file-name]

Kubernetes Nodes

Concept

Kubernetes에서 “노드”는 쿠버네티스 클러스터의 워커 머신을 나타내며, 이전에는 “미니언”이라고도 불렸습니다.
노드는 클러스터의 일부로서, 쿠버네티스에서 실행되는 파드의 컨테이너가 실행되는 곳입니다.

Minion

Kubernetes의 초기 버전에서 워커 머신(즉, 파드를 실행하는 서버)은 “미니언”이라는 이름으로 불렸습니다.
그러나 이후의 버전에서 이 이름은 “노드”로 변경되었습니다.
“미니언”은 쿠버네티스의 마스터-워커 구조에서 “하수인” 또는 “하인”의 의미를 가진 워커를 의미하는 것으로 생각되지만, 공식적인 이유나 근거는 쿠버네티스의 공식 문서에 명시되어 있지 않습니다.

Key elements of the node

  1. Kubelet: 각 노드에서 실행되는 에이전트로서, 노드에서 컨테이너가 올바르게 실행되는지 확인합니다.
    Kubelet은 쿠버네티스 API 서버와 통신하며, 파드의 상태 정보를 보고하고 새로운 파드 할당을 받아 해당 노드에서 실행합니다.
  2. Kube Proxy: 각 노드에서 실행되는 네트워크 프록시로서, 쿠버네티스 서비스 개념의 실제 구현을 담당합니다.
    Kube Proxy는 네트워크 트래픽을 적절한 파드로 라우팅하는 역할을 합니다.
  3. 컨테이너 런타임: 노드에서 컨테이너를 실행하기 위한 소프트웨어. 예로 Docker, containerd, CRI-O 등이 있습니다.

Node type

  1. 마스터 노드 (제어 플레인 노드): 클러스터의 관리와 조정을 담당하는 노드입니다.
    여기에는 쿠버네티스 API 서버, etcd, 스케줄러, 컨트롤러 매니저 등의 컴포넌트가 포함됩니다.
  2. 워커 노드: 실제로 애플리케이션 컨테이너가 실행되는 노드입니다.
    워커 노드는 클러스터의 실제 작업 부하를 처리합니다.

Node management

  • kubectl get nodes: 현재 클러스터의 모든 노드의 상태와 정보를 조회합니다.
  • kubectl describe node [노드 이름]: 특정 노드의 자세한 정보를 확인합니다.

노드는 물리적인 서버나 클라우드의 VM, 베어메탈 서버 모두 가능하며, 노드의 헬스 체크는 Kubelet이 주기적으로 수행합니다.
Kubelet이 일정 시간 동안 쿠버네티스 API 서버와 통신하지 못하면 해당 노드는 NotReady 상태가 될 수 있습니다.

What is kube control?

Concept of kubelet

kubectl (발음: “kube control” 또는 “kube cuddle”)는 Kubernetes 클러스터와 통신하고 관리하기 위한 커맨드라인 도구입니다.
사용자가 쿠버네티스 클러스터를 제어하고, 리소스를 생성/수정/삭제하며, 디버깅과 로깅 등 다양한 작업을 수행할 수 있게 도와줍니다.

Features

다음은 kubectl의 주요 기능 및 사용 예입니다:

  1. 리소스 관리: 파드, 서비스, 디플로이먼트 등의 쿠버네티스 리소스를 생성, 업데이트, 삭제합니다.
    • 예: kubectl create, kubectl delete, kubectl apply, kubectl edit
  2. 정보 조회: 클러스터와 관련된 다양한 정보를 조회합니다.
    • 예: kubectl get, kubectl describe, kubectl logs
  3. 디버깅 및 문제 해결: 실행 중인 파드와 관련된 문제를 진단하거나 해결합니다.
    • 예: kubectl logs, kubectl exec, kubectl attach
  4. 클러스터 관리: 클러스터 설정과 관련된 작업을 수행합니다.
    • 예: kubectl config
  5. 리소스 파일 검증: YAML 또는 JSON 리소스 파일의 유효성을 검사합니다.
    • 예: kubectl apply --dry-run=client -f [file-name]
  6. 스케일링 및 업데이트: 실행 중인 애플리케이션의 복제 수를 조정하거나 새 버전으로 업데이트합니다.
    • 예: kubectl scale, kubectl rollout

또한, kubectl의 자동 완성, 별칭 설정 등 다양한 플러그인과 확장 기능을 사용하여 사용자 경험을 향상시킬 수 있습니다.

kubectl 사용 시에는 대부분의 명령어가 kubectl [명령] [타입] [이름] [플래그]의 형식을 따릅니다.
예를 들어, 모든 파드를 조회하려면 kubectl get pods를 사용하면 됩니다.

쿠버네티스의 주요 컴포넌트 및 리소스와 상호 작용할 때 kubectl은 필수 도구입니다.
공식 쿠버네티스 문서에서 제공하는 kubectl 철저한 가이드와 함께 많은 실습을 통해 효과적으로 학습할 수 있습니다.

What is kube-proxy?

Concept

kube-proxy는 쿠버네티스 클러스터의 각 노드에서 실행되는 네트워크 프록시입니다.
kube-proxy는 쿠버네티스 서비스 추상화의 일부를 구현하는데 중요한 역할을 합니다.

Features

kube-proxy의 주요 기능과 역할은 다음과 같습니다:

  1. 서비스 네트워킹:
    • kube-proxy는 쿠버네티스 서비스의 IP 주소와 포트에 대한 트래픽을 적절한 파드로 전달합니다.
      즉, 서비스의 클러스터 IP로 들어오는 트래픽을 실제로 서비스를 제공하는 파드의 IP로 라우팅합니다.
  2. 로드 밸런싱:
    • 하나의 서비스는 여러 개의 파드에서 제공될 수 있습니다. kube-proxy는 서비스에 대한 요청을 이러한 파드들 사이에 로드 밸런싱합니다.
  3. 세션 어피니티:
    • 일부 서비스는 세션 기반의 어피니티를 필요로 합니다. kube-proxy는 이러한 설정을 지원하여 특정 클라이언트의 요청을
      항상 동일한 파드로 라우팅하게 할 수 있습니다.
  4. 네트워크 프록시 모드:
    • kube-proxy는 여러 네트워크 모드를 지원합니다. 가장 일반적으로 사용되는 두 가지 모드는 iptables 모드와 ipvs 모드입니다. iptables 모드는 리눅스의 iptables를 사용하여 트래픽을 라우팅하는 반면, ipvs 모드는 리눅스의 IP Virtual Server를 사용하여 로드 밸런싱 및 트래픽 라우팅을 수행합니다.
  5. 서비스 헬스 체크:
    • kube-proxy는 서비스에 연결된 파드의 상태를 계속 확인합니다.
      만약 파드가 종료되거나 건강하지 않은 상태로 간주되면, 해당 파드로의 트래픽 전달을 중지합니다.

kube-proxy는 쿠버네티스 클러스터에서 서비스의 신뢰성과 효율성을 보장하는 중요한 구성 요소입니다.
그러나 최근의 네트워크 솔루션, 특히 서드파티 CNI 플러그인에서는 kube-proxy의 기능을 대체하거나 확장하는 기능을 제공하기도 합니다.

What is CNI Pluggin?

Concept

CNI (Container Network Interface)는 컨테이너 실행 환경을 위한 네트워크 인터페이스 규격입니다.
CNI는 컨테이너를 실행하거나 중지할 때 네트워크 리소스를 할당하고 회수하는 기능을 정의합니다.

쿠버네티스는 CNI를 사용하여 파드 네트워킹을 구성합니다. 즉, 쿠버네티스 클러스터에서 파드가 생성될 때마다 CNI 플러그인이 호출되어 해당 파드를 위한 네트워크 인터페이스, IP 주소 및 라우팅 규칙을 설정합니다.

Features

CNI 플러그인의 주요 특징 및 기능은 다음과 같습니다:

  1. 플러그인 체인:
    • 여러 CNI 플러그인을 연결하여 실행할 수 있습니다.
      예를 들어, 하나의 플러그인이 네트워크 인터페이스를 생성하고 다른 플러그인이 그 인터페이스에 IPAM (IP 주소 관리)을 수행할 수 있습니다.
  2. 다양한 구현:
    • CNI 명세에는 다양한 구현이 가능하며, 여러 공급업체와 커뮤니티에서 다양한 CNI 플러그인을 개발했습니다.
      예로, Calico, Weave, Flannel, Cilium 등이 있습니다.
  3. IPAM:
    • IP 주소 할당과 관리를 위한 별도의 서브플러그인 규격입니다.
  4. 네트워크 분리:
    • 일부 CNI 플러그인은 네트워크 분리 또는 네트워크 폴리시를 지원하여 파드 간의 트래픽을 제어할 수 있습니다.
  5. 고성능 네트워킹:
    • 일부 CNI 플러그인은 고성능 네트워킹, 예를 들면 DPDK나 SR-IOV, 복잡한 라우팅 규칙을 지원합니다.
  6. 서드파티 연계:
    • 일부 CNI 플러그인은 기존의 온프레미스 또는 클라우드 네트워킹 솔루션과 통합될 수 있습니다.

쿠버네티스 클러스터를 설정할 때, 원하는 CNI 플러그인을 선택하고 설치해야 합니다.
선택한 CNI 플러그인은 클러스터의 네트워크 성능, 기능 및 구성 방식에 큰 영향을 미칩니다.

Additional

kubectl apply –dry-run=client -f [file-name]

kubectl apply --dry-run=client -f [file-name] 명령어는 쿠버네티스 리소스의 변경사항을 실제로 적용하지 않고
검증만 수행하는 명령어입니다. 이 명령어를 사용하면 리소스 파일의 문법 오류나 구성 오류를 확인할 수 있습니다.

각 부분의 상세 설명은 다음과 같습니다:

  1. kubectl apply: kubectl apply는 선언적 방식으로 쿠버네티스 리소스를 생성하거나 업데이트합니다.
    즉, 주어진 구성 파일의 상태를 클러스터의 현재 상태와 동기화하려고 시도합니다.
  2. –dry-run=client: 이 플래그는 실제로 리소스를 클러스터에 적용하지 않고 로컬에서만 검증합니다.
    client는 검증을 로컬에서만 수행하라는 것을 의미하며, 이로 인해 API 서버에 전송되는 요청이 없습니다.
  3. -f [file-name]: -f 플래그는 리소스의 구성을 담고 있는 파일을 지정합니다.
    [file-name] 부분에는 해당 구성 파일의 경로를 지정해야 합니다.

예를 들어, my-pod.yaml이라는 파일이 있고, 이 파일의 내용을 검증하려면 다음 명령어를 사용할 수 있습니다:

kubectl apply --dry-run=client -f my-pod.yaml

만약 구성 파일에 문법적인 오류나 구성 오류가 없다면, 명령어는 해당 리소스의 구성이 유효하다는 메시지를 출력할 것입니다.
만약 오류가 있다면, 해당 오류와 관련된 메시지를 출력해 줍니다.