Kubernetes란?

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

 

Orchestration이 필요한 이유

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

kubernetes가 존재해야 하는 이유?

• 분산시스템을 탄력적으로 실행하기 위한 프레임워크 제공
• 어플리케이션 배포, 스케일링, 장애조치를 할 수 있도록 만들어주는 환경 제공.

kubernetes의 장점

• kubernetes는 완전 오픈소스, 가장 풍부한 에코시스템
• kubernetes는 everything as code를 구현
• 어디서나 구동 가능(onprem, private/public cloud … local 까지)
• 넘쳐나는 레퍼런스 까지!

---

01. Container Orchestration 구조

kubernetes는 여러개의 노드에 걸쳐서 클러스터 형태로 오케스트레이션 하게 된다!!

• 노드 관리부터 위에 올라가는 서비스, 컨테이너 관리, 리소스 관리, 스케줄링, 스케일링, 배치 및 배포, 형상관리, 가용성 확보 등 운영 전반에 걸친 모든 작업에 관여를 하게 된다.

■ Kubernetes 아키텍처

 

kubernetes 전체를 통제/관리 하는 control plane과, 실제 사용자의 Application을 배포하는 data plane으로 나뉨.

 

1. Control plane

• kube-apiserver, etcd, kube-schduler, kube-controller-manager

2. Data plane

• kubelet, kube-proxy, container runtime

각 구성에 대한 자세한 내용은 아래에서 확인하자!!

 

---

02. minikube cluster 로 실습 시작

각 구성에 대해 자세하게 알아보기 전에, 실습용 도구로 'minikube'를 채택

필자 OS : Macbook M3 pro

 

■ terminal에서 minikube 실행

minikube start -- 클러스터 시작
minikube status -- 상태정보 보기

 

잠깐! minikube는 docker container 위에서 구동되는 도구이므로 docker 사전 설치가 되야한다!!!

 

■ minikube 동작 방식

클러스터 인증 정보와 context 정보를 알아보기 위해 'kubeconfig' 확인

• kubectl이 kubernetes와 통신할때 필요한 접속 대상의 서버정보, 인증정보 등을 정의
• 기본위치 : ~/.kube/config
• 관리정보 : cluster, users, context, current-context 등

 

2-1. kubectl을 간단하게 사용

이 part에서는 대단하게 실습을 하는 것이 아닌, kubernetes 노드 구성에 대해 알아보는 시간!!

node와 pod, namespace를 확인해보자.

 

< 노드 확인 >
kubectl get nodes

< 네임스페이스 확인> 
kubectl get namespace

< Pod와 namespace 까지 같이 확인 >
kubectl get pods
kubectl get pods -A
kubectl get all
kubectl get all -A

---

03. Kubernetes 구성 요소

위에서 다뤘던 control plane과 data plane에 대해 자세하게 알아보자.

 

3-1. Control plane

▶ etcd, api server, schduler

 

ETCD

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

■ HA 구성

클러스터에 단일 리더가 존재하며 나머지는 Follower로 존재한다. 단일 리더가 어느 이유에서든 health check에 실패하게 되면 Follower중 리더를 선출하여 서비스를 지속.

■ ETCD 구성 확인

kubectl describe pod etcd-minikube -n kube-system

 

■ etcdctl란?

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

 

kube-apiserver 역할

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

■ 구성 확인

kubectl describe pod -n kube-system kube-apiserver-minikube

 

kube-schduler

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

 

📌Pod 스케줄링

 

1. 필요성

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

 

2. 분류

• 사용자가 특정 노드에 pod를 배치하고 싶을 때
  • nodeSelector, Node Affinity, Node Anti-Affinity … 등 기술을 사용
• 관리자가 특정 노드에는 pod가 배치되는 것을 막고 싶을 때
  • Taints, Tolerations 기술을 사용.

 

■ Taints and Toleration

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

ex) kubernetes의 control node에는 pod가 스케줄링되지 않도록 taint가 되어 있다.

• Taints : node가 가지게 되는 성격. ex) taint: blue
• Toleration : pod가 가지게 되는 taint에 대한 toleration. ex) toleration: blue

즉, node에 taint가 blue로 설정되어 있다고 가정해보자.

pod에 toleration으로 blue가 설정되어 있다면 스케줄링 되고, 없다면 스케줄링 되지 않는다.

 

■ Labels and Selector (Affinity)

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

 

controller-manager

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

■ 역할

• 각 오브젝트의 상태를 관찰하고, 필요한 경우 state를 맞추는 역할을 한다.
• 컨트롤러 각각은 논리적이고 개별적인 프로세스지만 쿠버네티스의 복잡도를 줄이기 위해 패키지화 되어서 쿠버네티스 컨트롤러 매니저라는 싱글 프로세스로 관리된다.

■ 구성 확인  [pod 상세 확인]

kubectl describe pod kube-controller-manager-minikube -n kube-system

 

■ 컨트롤러 동작 예시

 

노드에 문제가 생겼을때의 노드 컨트롤러 동작 (시간은 커스터 마이징이 가능하다)

1. 5s 마다 status check를 진행 (node monitor period)
2. hearbeat가 도착하지 않으면 40s를 대기하고, unreachable로 마킹한다.
3. (node monitor grace period)
4. 추가로 5m을 더 대기한다. (pod eviction timeout)
5. 복구되지 않으면 해당 node의 pod들을 정상 node로 재배포 (pod가 replicaset일 경우만 해당)

---

3-2. Data plane

▶ kubelet, kube-proxy, container runtime

 

kubelet

각 노드에서 실행되는 에이전트로, Kubernetes Master Node로부터 Pod 사양을 수신하고 이를 실행하는 역할.

• 각 kubernetes 노드에서 동작하는 node agent
• 컨테이너 런타임과 연계하여 컨테이너의 기동 및 정지 등을 관리
• Pod와 컨테이너 상태를 지속적으로 모니터링한다.
• 파드 스펙 설정을 kube-apiserver로 부터 전달받아 파드 컨테이너의 실행을 직접적으로 관리
• pod가 아닌 프로세스의 형태로 뜬다.

■ 주요 기능

1. Pod 관리

• kubelet은 특정 노드에서 실행되어야 할 Pod의 상태를 지속적으로 모니터링합니다.
• Pod의 상태가 사양과 일치하는지 확인하고, 필요한 경우 Pod를 시작하거나 재시작합니다.

2. 컨테이너 런타임 통합

• kubelet은 Docker, containerd 등과 같은 다양한 컨테이너 런타임과 통합되어 작동합니다.
• CRI (Container Runtime Interface)를 사용하여 다양한 컨테이너 런타임과 호환됩니다.

3. 헬스 체크

• kubelet은 Liveness Probe와 Readiness Probe를 통해 컨테이너의 상태를 주기적으로 확인합니다.
• 문제가 발생하면 컨테이너를 재시작하거나 다른 조치를 취합니다.

4. 로그와 모니터링

• kubelet은 각 Pod의 로그를 수집하고, 모니터링 도구와 통합하여 시스템의 상태를 보고합니다.

5. 노드 상태 관리

• kubelet은 노드의 리소스 사용량(CPU, 메모리 등)을 모니터링하고, 이를 API 서버에 보고합니다.
• 이를 통해 클러스터의 자원 관리가 원활하게 이루어집니다.

■ 구성 확인

< kubelet 확인 >
minikube status

< kube-system 네임스페이스의 configmap >
kubectl get configmap -n kube-system

< kubelet configmap 확인 >
kubectl describe configmap kubelet-config -n kube-system

< kubelet 확인 >
ps -ef | grep kubelet
systemctl status kubelet

< kubelet 로그 확인 >
journalctl -u kubelet

 

★ ★ kubelet은 configmap 으로 관리되며, 저장위치는 아래와 같다.

/etc/kubernetes/kubelet-config.yaml 파일에 저장

 

 

kube-proxy

node와 pod끼리 통신을 가능하게 하는 역할을 지닌다.

• worker node에 daemon set 형태로 하나씩 떠있음.
• 클러스터 내 각 노드에서 실행되는 네트워크 프록시
• 가상 네트워크의 동작을 관리
• IP translation과 Routing

■ 구성 확인

kubectl get configmap -n kube-system | grep -i kube-proxy
kubectl describe configmap -n kube-system kube-proxy

 

 

Core DNS (kube-dns)

• kubernetes 클러스터 내부의 주소 해석이나 서비스 디스커버리에 사용되는 내부 DNS 서버 (add-on)
• kube 1.12 버전 전에는 kube-dns 라는 이름이었으나, 이후에는 CoreDNS 라는 이름을 사용.

FQDN 방식으로 동작한다.

 

■ 구성 확인

kubectl describe configmap -n kube-system coredns

 

■ 도메인 호출 테스트

 

1. 네임스페이스 생성

kubectl create namespace app

2. test pod (nginx image) 생성

kubectl run nginx --image nginx -n app

3. test pod 생성 확인

kubectl get pod -n app

4. 상세 정보 확인

kubectl get pod -n app -o wide

 

■  서비스 호출

 

1. Static IP로 호출

kubectl run curl -it --rm --image curlimages/curl -- sh
curl 172.17.0.3 (pod IP 주소)

2. 서비스에 할당한 커스텀한 이름으로 호출

• [ curl podIP-네임스페이스-서비스타입-루트주소 ]

curl 172-17-0-3.app.pod.cluster.local