Kubernetes

쿠버네티스란 컨테이너화된 워크로드와 서비스를 관리하기 위한 오픈소스 컨테이너 오케스트레이션 플랫폼

Orchestration

컨테이너는 원래 프로세스나 애플리케이션을 기반 시스템으로부터 격리하기 위해 만들어졌기 때문에, 개별 컨테이너를 생성하고 배치하는 것은 쉬움
하지만 컨테이너의 수가 많아지게 되면 관리와 운영에 어려움이 따름
각각 독립적으로 배치된 컨테이너를 연결하고 관리하고 확장하면서 이 요소들 전체가 하나로 실행되도록 할 수 있어야 함. 이렇게 다수의 컨테이너 실행을 관리하고 조율하는 것을 컨테이너 오케스트레이션이라고 함

• 자동화된 스케일링
• 자동화된 롤아웃과 롤백
• 자동화된 복구 (self-healing)
• 자동화된 빈 패킹 (bin packing)
• 시크릿과 구성관리
• 서비스 디스커버리와 로드 밸런싱
• 스토리지 오케스트레이션
• 선언적 코드를 사용한 운영 (IaC)

Kubernetes 아키텍처

Control plane (Master node): Kubernetes 전체를 통제/관리

• kube-apiserver
• etcd
• kube-scheduler
• kube-controller-manager (cloud-controller-manager)

Data Plane (Worker node): 실제 사용자의 애플리케이션 배포

• kubelet
• kube-proxy
• container runtime

kubeconfig

kubeconfig 컨텍스트

컨텍스트 전환

$ Kubectl config use-context minikube

현재 컨텍스트 확인

$ kubectl config current-context

컨텍스트 목록 조회

$ kubectl config get-contexts

kubeconfig 컨텍스트 내용 변경: yaml 파일 편집 or kubectl

minikube 명령어

alias k=kubectl 으로 alias 설정

노드 확인

$ k get node

네임스페이스 확인

k get ns

포드확인

$ k get pod
$ k get pod -A
$ k get all
$ k get all -A

control plane

etcd

• 쿠버네티스에서 필요한 모든 데이터를 키-값 형태로 저장하는 데이터베이스
• etcd가 다운되면 모든 컴포넌트가 미아가 되기 때문에 가용성이 매우 중요
• 클러스터링하여 분산 실행하는 RSM (Replicated State Machine) 구조

etcd 구성 확인

# etcd pod 상세 확인
$ k describe pod etcd-minikube -n kube-system

ETCDctl

• ETCD를 다루기 위한 유틸리티
• api version 2/3 있음 (설정이 없으면 기본적으로 v2를 사용)
• ETCDCTL이 ETCD API Server에 인증할 수 있도록 인증서 파일 경로 지정 필요

-cacert /etc/kubernetes/pki/etcd/ca.crt
-cert /etc/kubernetes/pki/etcd/server.crt
-key /etc/kubernetes/pki/etcd/server.key
-endpoints=[127.0.0.1:2379]

ETCDctl로 클러스터 정보 조회

# etcd pod 로 shell 실행 
$ kubectl exec -it \
  -n kube-system etcd-minikube \
  -- sh -c 'ETCDCTL_CACERT=/var/lib/minikube/certs/etcd/ca.crt \
    ETCDCTL_CERT=/var/lib/minikube/certs/etcd/peer.crt \
    ETCDCTL_KEY=/var/lib/minikube/certs/etcd/peer.key \
    ETCDCTL_API=3  \
    etcdctl \
      get \
      --keys-only \
      --prefix=true \
      "/registry/pods/" '

# etcd pod 로 shell 실행
$ kubectl -n kube-system exec -it etcd-minikube -- /bin/sh

# member 조회
$ ETCDCTL_API=3 etcdctl \
  --cacert /var/lib/minikube/certs/etcd/ca.crt \
  --cert /var/lib/minikube/certs/etcd/peer.crt \
  --key /var/lib/minikube/certs/etcd/peer.key \
  put Name limsangkyu

$ ETCDCTL_API=3 etcdctl  --cacert /var/lib/minikube/certs/etcd/ca.crt  --cert
/var/lib/minikube/certs/etcd/peer.crt  --key /var/lib/minikube/certs/etcd/peer.key
get Name

# 모든 값 출력
$ ETCDCTL_API=3 etcdctl \
  --cacert /var/lib/minikube/certs/etcd/ca.crt \
  --cert /var/lib/minikube/certs/etcd/peer.crt \
  --key /var/lib/minikube/certs/etcd/peer.key \
  get / --prefix --keys-only

kube-apiserver

• 쿠버네티스 API를 제공하는 핵심 구성 요소
• 쿠버네티스 프론트 엔드로서 클러스터로 온 유청의 유효성을 검증
• 다른 컴포넌트 간 통신을 중재
• kubectl 유틸리티가 접근하는 주체

kube-apiserver 구성 확인

# kube-apiserver pod 상세 확인
$ k describe pod kube-apiserver-minikube -n kube-system

kube-scheduler

• 클러스터 안에서 자원 할당이 가능한 노드 중 알맞은 노드를 선택하는 역할
• Label / Selector / Affinity / Taint / Toleration 기능과 함께 동작

kube-scheduler가 없다면?

pod를 manual scheduling 해주어야 함

pod 스케줄링의 필요성

• 머신러닝 워크로드를 돌리는 특정 pod는 GPU가 탑재된 node에서만 돌아야 함
• consumer들은 네트워크 intensive하므로 전용 node group을 사용
• 팀별로 node를 나눠서 사용

pod 스케줄링 분류

사용자가 특정 노드에 pod를 배치하고 싶을 때
→ nodeSelecor, Node Affinity, Node Anti-Affinity, Inter Pod Affinity, Inter Pod Anti-Affinity

관리자가 특정 노드에는 pod가 배치되는 것을 막고 싶을 때
→ Taints, Tolerations

Taints and Toleration

• 어떤 pod가 어떤 node에 스케줄링 될 수 있는지를 제한

• 대표적인 예) kubernetes의 control node에는 pod가 스케줄링되지 않도록 taint가 되어있음

• Taints: node가 가지게 되는 성격. 예) taint:blue

• Toleration: pod가 가지게 되는 taint에 대한 toleration. 예) toleration: blue

# Node
$ kubectl taint nodes node1=blue:NoSchedule(|PreferNoSchedule|NoExecute)

# Pod
apiVersion: v1
kind: pod
metadata:
  name: myapp-pod
spec:
  containers:
    - name: nginx
      image: nginx
  tolerations:
    - key: "app"
      operator: "Equal"
      value: "blue"
      effect: "NoSchedule"

Label and Selector (Affinity)

• NodeSelector
  • 노드에는 라벨을 할당하고, 파드에는 nodeSelector 필드를 추가하여 특정 노드에서 구동되도록 함
  • 다만, NodeSelector는 여러 값을 할당하거나 not 예외처리를 하거나 하는등을 하기에는 어려움
• NodeAffinity
  • 여러 advanced 할당을 할 수 있는 만큼 문법이 다소 복잡

# Labels and Selector

# Node
$ kubectl label nodes node1 size=Large

# Pod
apiVersion: v1
kind: pod
metadata:
  name: myapp-pod
spec:
  containers:
    - name: nginx
      image: nginx
  nodeSelector:
    size: Large

# Labels and NodeAffintiy

# Pod
apiVersion: v1
kind: pod
metadata:
  name: myapp-pod
spec:
  containers:
    - name: nginx
      image: nginx
  affinitiy
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpreesions:
          - key: size
            operator: In(|NotIn|Exists)  // Exist 인 경우 value가 필요없음
            value:
            - Large
            - Medium

kube-controller-manager

• 다양한 컨트롤러를 실행하는 구성요소
• 노드 컨트롤러 / 잡 컨트롤러 / 엔드포인트 컨트롤러 / 레플리케이션 컨트롤러 등 각 오브젝트를 관할

kube-controller-manager 구성 확인

# kube-controller-manager pod 상세 확인
$ k describe pod kube-controller-manager-minikube -n kube-system

컨트롤러 동작 예시

• 노드에 문제가 생겼을 때의 노드 컨트롤러 동작
  • 5s 마다 status check를 하다가 (node monitor period)
  • heartbeat가 도착하지 않으면 40s를 대기하고 unreachable로 마킹하고
    (node monitor grace period)
  • 추가로 5m을 더 대기 (pod eviction timeout)
  • 복구되지 않으면 해당 node의 pod들을 정상 node로 재배포
    (pod가 replica set에 해당되는 경우)

cloud-controller-manager

• 쿠버네티스의 컨트롤러들을 클라우드 서비스 API와 연결해서 관리하는 컴포넌트
• CSP에 특화된 컨트롤러만을 관리
• 따라서 on-premiss 환경인 경우 이 컴포넌트는 없음