Post

Section 2-0. Core Concepts

udemy의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의 및 쿠버네티스 인 액션 (마르코 룩샤)를 참고하여 정리한 글입니다.

Section02. Core Concepts

Cluster Architecture

Cluster Architecture

  • 쿠버네티스 클러스터는 물리적 또는 가상의 노드 집합으로 구성되어 있다.
  • 이 노드 집합의 클러스터는 Master 노드Worker 노드로 구분된다.
    • Master 노드는 쿠버네티스 클러스터를 관리하고 통신, 스케줄링 및 컨트롤러를 처리한다.
    • Worker 노드는 컨테이너를 띄우고 제어한다.

Master 노드

  • Master 노드는 kube-apiserver, kube-scheduler, kube-controller-manager, etcd 로 구성되어 있다.

ETCD

  • 쿠버네티스 클러스터의 상태 값(Node, Pod, Config 등 쿠버네티스 오브젝트들의 상태 값)을 KEY-VALUE 형태로 저장하는 DB이다.

kube-apiserver

  • 쿠버네티스 컨트롤 플레인의 프론트엔드로 클러스터 내에서 모든 작업을 오케스트레이션한다.
  • 즉 요청의 인증과 유효성을 확인하고 ETCD에서 데이터 검색 및 업데이트 하는 일을 한다.
  • REST 호출이나 kubectl 커맨드라인 인터페이스 또는 kubeadm과 같은 기타 CLI(command-line interface)를 통해 API에 액세스할 수 있다.
    • 예를 들어 kubectl을 통해 get nodes와 같은 명령을 전달하면 HTTP 형태로 kube-apiserver에 명령이 전달되며, HTTP request 헤더에 있는 Authorization 정보를 통해 인증하고 ETCD에서 정보를 가져와 값을 리턴해준다.
    • 또한 kubectl을 통해 파드를 배포하는 명령어를 전달하면 kube-apiserver는 인증 후 ETCD의 값을 가져와 다른 경우 상태 값을 갱신하고 이를 Scheduler에 전달한다. (Scheduler는 적절한 노드를 선정해 파드를 띄운다)

kube-scheduler

  • kube-scheduler는 CPU 또는 메모리와 같은 파드의 리소스 요구 사항과 함께 클러스터의 상태를 고려한 이후 파드를 적절한 컴퓨팅 노드에 예약한다.

kube-controller-manager

  • 컨트롤러 프로세스를 실행하는 컨트롤 플레인 컴포넌트로써 클러스터의 상태를 지속적으로 모니터링 및 관리를 한다.
  • 쿠버네티스는 각각의 컨트롤러들이 포드들을 관리하는 역할을 하는데 kube-controller-manager는 이런 각각의 컨트롤러들을 실행하는 역할을 한다.
  • 클러스터 내에서 새로운 컨트롤러가 사용될 때는 그 컨트롤러에 해당하는 구조체가 만들어진 후 이를 kube-controller-manager가 관리하는 큐에 넣어서 실행하는 방식으로 동작한다.

Worker 노드

  • Worker 노드는 kubelet, kube-proxy, pod 집합으로 구성되어 있다.

kubelet

  • node를 쿠버네티스 클러스터에 등록하고, pod이나 container를 실행 및 모니터링하는 역할을 한다.
    • 노드에 컨테이너나 파드를 로드하라는 지시를 받으면 컨테이너 런타임 엔진을 이용하여 작업을 수행한다.
    • 파드와 컨테이너의 상태를 계속 모니터링 하고 동시에 kube-apiserver에 보고한다.

kube-proxy

  • 클러스터의 각 노드에서 실행되는 네트워크 프록시로 노드의 네트워크 규칙을 유지 관리한다. 이 네트워크 규칙이 내부 네트워크 세션이나 클러스터 바깥에서 파드로 네트워크 통신을 할 수 있도록 해준다.
  • 쿠버네티스 클러스터 내의 각 파드들은 파드 네트워킹 솔루션을 클러스터에 배치함으로써 서로 통신할 수 있다.
    • 파드 네트워크는 내부 가상 네트워크로 모든 파드가 연결되는 클러스터 내 모든 노드에 걸쳐있다.

pod

  • 쿠버네티스에서 생성하고 관리할 수 있는 배포 가능한 가장 작은 컴퓨팅 단위이다.
  • 일반적으로는 각 파드 하나에는 하나의 컨테이너만 실행하지만 그렇지 않은 경우도 있다.
    • 단일 컨테이너를 실행하는 파드 : 이 경우, 파드를 단일 컨테이너를 둘러싼 래퍼(wrapper)로 생각할 수 있다.
    • 여러 컨테이너를 실행하는 파드 : 리소스를 공유해야 하는 여러 개의 컨테이너로 구성된 애플리케이션을 캡슐화할 수 있다. 이런 함께 배치된 컨테이너는 하나의 결합된 서비스 단위를 형성한다.

PODs with YAML

YAML 파일을 통해 파드를 생성하는 방법

1
2
3
4
5
6
7
8
9
10
11
apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
    type: front-end
spec:
  containers:
  - name: nginx-container
    image: nginx
  • 정의 파일은 항상 4가지 상위 필드를 포함한다.
    • apiVersion: 생성하려는 오브젝트를 만들기 위해 사용하는 쿠버네티스 api의 버전을 나타낸다.
    • kind: 생성하려는 오브젝트의 유형을 나타낸다.
    • metadata: 오브젝트의 이름, 라벨 등을 딕셔너리 형태로 나타낸다.
    • spec: 오브젝트에 대한 추가적인 설정을 나타낸다. (컨테이너의 이름, 이미지 등)
  • 생성한 파일을 통해 파드를 띄우는 방법은 다음과 같다.
    • kubectl create -f pod.yaml
    • kubectl apply -f pod.yaml

YAML 파일을 통해 파드를 조회하는 방법

  • kubectl get pods
  • kubectl describe pod myapp-pod
This post is licensed under CC BY 4.0 by the author.