Kubernetes 기본 구성요소 - 1(for CKAD)

시작하며

CKAD를 준비하며 정리한 내용들

목차

Kubernetes 기본 구성요소

• Kubernetes Architecture
• Pod 생성 및 설정

Kubernetes Architecture

Kubernetes는 여러개의 노드들로 구성되어있습니다.
모든 클러스터는 하나 이상의 worker 노드로 구성되어 있습니다.
control plane은 worker node들과 클러스터 내부의 pod들을 관리합니다.

Node

Kubernetes는 node 유형은 master와 worker로 나뉩니다.
Master(Control Plane) : cluster의 컨트롤 타워 역할을 하며, cluster의 global 결정사항이나 cluster의 event들을 감지하고 응답하는 역할을 담당함
Worker(Data Plane) : worker machine으로 쿠버네티스가 컨테이너를 실행하는 곳이며, 과거에는 Minions라고 불리기도 함.

• Master Node
  • API-Server
  • ETCD
  • Scheduler
  • Controllers
• Node
  • kubelet
  • kube-proxy

Component

• API Server: 사용자들은 Command Line Interface들을 이용해서 API server와 통신하고, kubernetes cluster와 상호작용함
• ETCD: 분산 방식(distributed manner)이며, 신용가능한 key-value store. etcd는 lock 장치를 이용해서 master와 충돌되지 않도록 lock을 구현함
• Scheduler: 다중 노드에 일을 분산해서 처리하는거나 container를 할당하는걸 담당
• Controller: Controller는 Orchestration의 두뇌이며, node, container, endpoint들이 죽었을때 응답 또는 알림을 책임짐
• Container Runtime: 쿠버네티스에서 실행과 Container의 lifecycle을 담당함 (ex. docker)
• Kubelet: Kubelet agent는 예상대로 컨테이너가 노드에서 실행되는지 확인함
• Kube-Proxy : Kubernetes의 각각의 노드에서 실행되고 있으며, 노드들의 network rule등을 유지

CRI(Container Runtime Interface)

Kubenretes는 다양한 Container Runtime과도 호환을 하기 위해 CRI를 구성했습니다.
CRI는 아래 OCI 표준을 따르는 경우 가능하게 설계되었습니다.

OCI (Open Container initiative )

• Imagespec
• Runtimespec

다만 Docker는 CRI 표준을 지원하려고 만든게 아니고 한참 이전에 만들어졌었다.
그래서 docker를 계속 지원했고 고안해낸게 dockershim(임시방편)이란 걸 만들게됨
다만 결국 1.24인에서 dockershim에 대한 지원도 지우게 됨
다시 docker에서 OCI 표준에 맞춰서 개발해서 호환이 되기 시작함

POD 생성 및 설정

Pod는 Kubernetes에서 가장 작은 실행 단위입니다.
하나의 pod는 하나 또는 여러 개의 컨테이너의 그룹이며, 공유 저장소와 네트워크 리소스를 갖고 있으며, 컨테이너를 실행하는 방법에 대해서 정의해놨습니다.

Pod 정의

이제 Pod를 사용하는 방법에 대해서 확인해보겠습니다.
nginx image를 실행하는 pod의 예시를 보여드리겠습니다.

속성

• API Version
• Kind
• Metadata
• Spec

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80

다음과 같이 yaml 파일을 구성하고, kubectl 명령어로 실행을 진행합니다.

kubectl apply -f https://k8s.io/examples/pods/simple-pod.yaml

Command

pod 정보 확인
kubectl describe pod nginx 

pod 설정 편집 
kubectl edit pod nginx

pod 설정 적용
kubectl apply -f nginx-definition.yaml

kubectl run nginx --image=nginx123 --dry-run=client -o yaml > nginx-definition.yaml

kubectl run nginx: redis라는 이름의 파드를 생성합니다.
--image=nginx123: nginx123 이미지를 사용하는 컨테이너를 파드에 추가합니다.
--dry-run=client: 실제로 클러스터에 적용하지 않고, 클라이언트 측에서 실행하여 YAML 파일을 생성합니다.
-o yaml: 출력 형식을 YAML로 지정합니다.
> nginx-definition.yaml: 출력된 YAML을 nginx-definition.yaml 파일에 저장합니다.

ReplicationController vs ReplicaSet

ReplicationController는 특정 개수의 파드(pod)가 항상 실행되고 있는지 확인하는 역할을 합니다.
ReplicaSet은 ReplicationController의 개선된 버전으로, 주로 Deployment와 함께 사용됩니다.

차이점

• apiVersion이 다릅니다.
  RC(v1)과 다르게 RS(apps/v1) 버전은 다양한 기능을 포함하고 있습니다.
• ReplicaSet은 selector 정의가 필요합니다.
  ReplicaSet은 ReplicationController와 다르게 template으로 생성하지 않은 Pod도 관리할 수 있습니다.

ReplicaSet은 Pod을 지속적으로 모니터링합니다.
그리고 모니터링을 수행할 때 Label 필터링을 통해 선별합니다.

replica set 오류 상황의 경우 대처 방법

matchlabel의 이름과 template 하단에 있는 label과 동일한지 체크를 진행합니다. 
Kubectl edit rs new-replica-set  
해당 명령어를 통해서 label 또는 특정 데이터를 수정합니다.

기존 pod들은 오류난 채로 그대로 있을경우 이때 pod들을 삭제하며 replica set들이 적용됩니다.
Kubectl delete pod replica-set   

replica set 크기를 수정하는 방법
Kubectl scale rs new-replica-set —replicas=5 

Kubernetes의 기본 요소들을 확인해봤습니다.
다음 포스팅에서는 Configuration들을 확인해보겠습니다.

reference : https://velog.io/@chancehee/%EC%BF%A0%EB%B2%84%EB%84%A4%ED%8B%B0%EC%8A%A4-ReplicationController-vs-ReplicaSet

Deployment

Deployment를 사용하면 애플리케이션의 버전을 업데이트하고 롤백하는 등의 작업을 쉽게 할 수 있습니다.
Deployment를 정의하면 Kubernetes는 해당 애플리케이션을 실행하는 Pod들을 생성하고 관리합니다.
또한 Deployment는 원하는 상태를 지속적으로 유지하도록 보장하며, 필요한 경우 자동으로 Pod를 복제하거나 스케일링할 수 있습니다.
이를 통해 애플리케이션의 가용성과 안정성을 높일 수 있습니다.

Kubectl 옵션들

dry run

--dry-run=client: 클라이언트 측에서만 리소스를 확인하고, API 서버와 상호작용하지 않습니다. 로컬에서 리소스 정의가 유효한지 확인할 때 사용됨
아래 예시의 경우는 nginx deployment를 만들지 않지만 yaml파일로 만들어서 검증을 하는데 사용함

kubectl create deployment nginx --image=nginx --dry-run=client -o yaml

expose 옵션

nginx라는 이름의 파드를 생성하면서, 해당 파드에 대해 서비스도 생성하고, 포트 80도 노출함

kubectl run https —image=httpd:alpine —port —expose=true