Section 2: Core Concepts

in Study on Cka

Kubelet

  • 워커 노드에 있는 kubelet은 쿠버네티스 클러스터에 노드를 등록합니다.
  • 노드에 컨테이너 또는 파드를 띄우라는 지시를 받으면, 도커와 같은 컨테이너 런타임 엔진에 필요한 이미지를 pull하고 인스턴스를 실행해달라고 요청합니다.
  • 파드와 파드 안의 컨테이너들의 상태를 계속 모니터링 하고, kube-apiserver에 적시에 보고합니다.
  • 다른 컴포넌트들과 달리, kubeadm을 통해 배포하지 않으므로 수동으로 설치해야 합니다.

아래 명령어로 워커 노드에서 kubelet을 살펴 보면, 실행 중인 kubelet 프로세스와 적용된 옵션들을 볼 수 있습니다.

ps -aux | grep kubelet

Kube-proxy

쿠버네티스 클러스터 내에서 파드 끼리는 서로 통신할 수 있습니다. 파드 네트워크라고 불리는 클러스터 내의 모든 노드에 걸쳐 있으며, 모든 파드와 연결된 내부 가상 네트워크 덕분에 가능한 것인데, 이런 네트워크를 배포하기 위한 많은 솔루션이 있습니다.

1번 노드에 웹 어플리케이션이, 2번 노드에 데이터베이스 어플리케이션이 있다고 합시다. 윕 앱은 단순히 파드의 IP를 통해 데이터베이스에 접근할 수 있지만, 항상 데이터베이스 파드의 IP가 같을 거라는 보장은 없습니다. 웹 앱이 데이터베이스에 접근하는 더 나은 방법은 서비스를 이용하는 것입니다. 클러스터 전체에 데이터베이스 어플리케이션을 노출시키는 서비스를 만들어봅시다. 웹 앱은 이제 DB라는 서비스 이름으로 데이터베이스에 접근할 수 있습니다. 서비스도 IP 주소를 할당받기 때문에, 파드는 서비스의 IP나 이름으로 서비스에 접근할 때마다 서비스는 트래픽을 백엔드 파드(데이터베이스)로 보냅니다.

이러한 서비스는 무엇이고 어떻게 IP를 받아오는걸까요? 서비스가 같은 파드 네트워크에 있는걸까요? 서비스는 실제로 존재하는 것은 아니기 떄문에 같은 파드 네트워크에 있을 순 없습니다. 서비스는 파드같은 컨테이너가 아니어서 어떤 인터페이스나 능동적으로 listen하는 프로세스가 없습니다. 단지 쿠버네티스 메모리에 있는 가상의 컴포넌트일 뿐이죠. 근데 클러스터 내의 모든 노드에서 서비스에 접근할 수 있다고 했는데요. 이게 어떻게 가능한걸까요? 여기서 kube-proxy가 등장합니다.

kube-proxy는 클러스터 내의 각 노드에서 실행되는 프로세스입니다. 새로운 서비스를 찾고, 서비스가 생성될 때마다 각 노드에 해당 서비스에 대한 트래픽을 백엔드 파드로 전달하는 적절한 규칙을 세우는 역할을 합니다. 규칙을 세우는 한 가지 방법은 iptables 규칙을 사용하는 것입니다. 클러스터의 각 노드에서 iptables 규칙을 생성해서 서비스의 IP(10.96.0.12)로 향하는 트래픽을 실제 파드의 IP(10.32.0.15)로 전달합니다. 이렇게 kube-proxy는 서비스를 구성합니다.

Pod

쿠버네티스로 이루고자 하는 궁극적인 목표는 클러스터에서 워커 노드로 구성된 머신에 컨테이너 형태로 어플리케이션을 배포하는 것입니다. 하지만, 쿠버네티스는 컨테이너를 워커 노드에 직접 배포하지 않습니다. 컨테이너들은 파드라는 쿠버네티스 오브젝트로 캡슐화되어있습니다. 파드는 애플리케이션의 단일 인스턴스이며, 쿠버네티스에서 만들 수 있는 가장 작은 오브젝트입니다.

쿠버네티스 클러스터에 한 노드에 파드로 캡슐화된 하나의 도커 컨테이너가 있다고 합시다. 애플리케이션 사용자 수가 증가해 애플리케이션을 확장하려면, load를 분산하기 위해 애플리케이션의 인스턴스를 추가해야 하는데요. 이 때, 같은 파드에 새 컨테이너 인스턴스를 만드는 것이 아니라, 새로운 인스턴스가 담긴 파드를 만들면 됩니다. 사용자가 더 많아져서 현재 노드에 충분한 용량이 없다면 새 노드를 추가해서 파드를 더 배포하면 됩니다. 이렇게 파드는 일반적으로 컨테이너와 1:1 관계를 가집니다.

YAML

쿠버네티스는 파드, replica, deployments, 서비스와 같은 오브젝트를 생성하기 위해 yaml 파일을 인풋으로 사용합니다. definition file은 항상 다음 4가지 항목을 포함합니다.

  • apiVersion
  • kind
  • metadata
  • spec 이 네 가지는 최상위(또는 루트 레벨) 속성들로, configuration file에 필수적으로 입력되어야 합니다.
apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    app: nginx
    tier: frontend
spec:
  containers:
  - name: nginx
    image: nginx

kubectl apply로 yaml 파일 적용하여 파드 생성

kubectl apply -f pod.yaml