Static Pod

Static Pod는 Kubernetes 클러스터에서 kubelet에 의해 직접 관리되는 Pod이다.

API 서버를 통해 관리되는 일반적인 Pod와는 달리, Static Pod는 Kubernetes API 서버의 개입 없이 kubelet에 의해 직접 생성 및 관리된다.

특징:

• Static Pod는 control plane의 일부(예: kube-apiserver, etcd, kube-scheduler 등)와 같은 중요 구성 요소를 실행하기 위해 주로 사용된다.
• Pod 정의 파일이 직접 노드의 특정 경로(일반적으로 /etc/kubernetes/manifests/)에 저장되며, kubelet은 해당 경로를 지속적으로 모니터링하고 그 정의에 따라 Pod를 실행한다.
• Static Pod는 kube-apiserver와 같은 중앙 관리 서비스 없이도 노드에서 자동으로 실행됩니다. 즉, API 서버가 다운되더라도 Static Pod는 계속 실행된다.
• Static Pod는 Deployment, ReplicaSet과 같은 리소스 관리 기능을 사용하지 않는다. 만약 Static Pod가 종료되면, kubelet이 이를 감지하고 다시 시작한다.
• Static Pod가 실행 중일 때, kubelet은 해당 Pod에 대한 정보를 API 서버로 전달하며, 이를 통해 kube-apiserver에서 간접적으로 Static Pod의 상태를 확인할 수 있다.

Static Pod 정의 파일을 다른 경로에서 사용하는 방법:

1. Kubelet 실행 시 command 옵션 사용:

kubelet을 실행할 때, --pod-manifest-path 플래그를 사용하여 Static Pod의 정의 파일을 저장할 경로를 지정할 수 있다.

kubelet --pod-manifest-path=원하는 경로

이 경우 kubelet은 원하는 경로를 모니터링하여 그곳에 있는 정의 파일을 기반으로 Static Pod를 실행한다.

2. Kubelet 설정 파일 수정:

kubelet이 실행될 때 참조하는 설정 파일 /var/lib/kubelet/config.yaml 또는 /etc/kubernetes/kubelet.conf에서

podManifestPath 옵션을 설정하여 Static Pod 정의 파일을 읽을 경로를 변경할 수 있다.

$ cat /var/lib/kubelet/config.yaml
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
...
staticPodPath: /etc/kubernetes/manifests <- 원하는 경로로

Control Plane

Control Plane은 Kubernetes 클러스터에서 클러스터 전반을 관리하고 제어하는 중앙 관리 시스템이다.

Control Plane은 여러 컴포넌트로 구성되며, 이 컴포넌트들은 클러스터의 상태를 조정하고, desired state와 actual state가 일치하도록 만든다.

Control Plane 주요 component

• kube-apiserver:
  • 클러스터의 중앙 통신 허브 역할
  • 모든 컴포넌트 및 사용자 요청이 API 서버를 통해 이루어지며, Kubernetes 클러스터와 상호작용하는 주요 진입점.
  • kubectl을 통해 클러스터에 명령을 내리거나 클러스터 상태를 조회할 때 모두 kube-apiserver를 거친다.
• etcd:
  • Kubernetes의 분산 키-값 저장소 
  • 모든 클러스터 상태 정보(노드, Pod, 서비스, 설정 등)를 저장하는 곳이다.
  • Control Plane의 다른 컴포넌트들은 모두 etcd에서 데이터를 읽거나 수정하면서 클러스터의 상태를 유지 및 관리한다.
• kube-scheduler:
  • 새로운 Pod가 생성되면, 이를 어느 노드에 할당할지 결정하는 역할을 한다.
  • 클러스터의 리소스 사용량을 고려하여, Pod를 적절한 노드에 배치하는 것이 주요 역할
• kube-controller-manager:
  • 다양한 컨트롤러를 실행하여 클러스터의 상태를 유지하고 관리합니다. 각 컨트롤러는 클러스터의 상태를 모니터링하고, desired state에 맞게 조정하는 역할을 한다.
  • 예: ReplicaSet 컨트롤러, 노드 컨트롤러, Job 컨트롤러 등

Static Pod와 Control Plane의 관계:

Control Plane의 핵심 구성 요소들은 일반적으로 Static Pod로 실행되며 master node에 주로 배치된다.

즉, kube-apiserver, etcd, kube-scheduler와 같은 중요한 Control Plane 컴포넌트들이 Static Pod로 설정되어 있기 때문에, API 서버에 의존하지 않고도 실행 및 복구될 수 있다.

따라서 API 서버가 다운되거나 문제가 생겼을 때에도 클러스터가 완전히 멈추지 않도록 한다.

직접 Static Pod 생성해보기 

1. static-busybox.yaml 파일 작성 

kubectl run static-busybox --image=busybox:1.28.4 --dry-run=client -o yaml --command -- sleep 1000

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: static-busybox
  name: static-busybox
spec:
  containers:
  - command:
    - sleep
    - "1000"
    image: busybox:1.28.4
    name: static-busybox
    resources: {}
  dnsPolicy: ClusterFirst
  restartPolicy: Always
status: {}

2. /etc/kubernetes/manifests 하위로 yaml 파일 이동

mv /etc/kubernetes/manifests

3. 결과 확인 

요약:

• Static Pod는 API 서버를 거치지 않고, 노드에서 직접 kubelet에 의해 실행되는 Pod이다. 주로 Control Plane 구성 요소를 실행하는 데 사용된다.
• Control Plane은 Kubernetes 클러스터를 관리하는 중심부로, 클러스터의 상태를 조정하고 필요한 작업을 수행하는 여러 컴포넌트들로 이루어져 있다.
• Control Plane의 주요 구성 요소인 kube-apiserver, etcd, kube-scheduler 등은 Static Pod로 실행되며, 클러스터의 가용성과 안정성을 보장한다.
• Custom Static Pod를 사용하기 위해선 /etc/kubernetes/manifests/에 yaml 파일을 위치시키면 된다. 

Pod 수정 

기존 Pod의 스펙 중 아래 항목들을 제외하고는 수정할 수 없다.

• spec.containers[*].image
• spec.initContainers[*].image
• spec.activeDeadlineSeconds
• spec.tolerations

예를 들어, 실행 중인 Pod의 환경 변수, 서비스 계정, 리소스 제한 등의 설정은 수정할 수 없다.

하지만 정말 수정하고 싶다면 방법이 두 가지가 있다.

방법 1

kubectl edit pod <pod 이름> 명령어를 실행하여 Pod의 스펙을 편집할 수 있다.

vi 에디터를 통해 필요한 속성을 수정한 후 저장하려고 하면, 저장이 거부된다.

이는 수정할 수 없는 필드를 편집하려고 했기 때문이다.

하지만 수정한 내용이 포함된 파일이 위에 표시된 것처럼 임시 위치에 저장된다.

다음 기존에 있던 Pod를 삭제한다.

kubectl delete pod webapp

그 후 임시 위치에 저장된 파일로 다시 pod를 생성한다.

kubectl create -f /tmp/kubectl-edit-ccvrq.yaml

최종적으로 변경 사항이 적용된다. 

방법 2

 다음 명령어를 사용하여 Pod 정의를 YAML 형식으로 파일에 추출한다.

kubectl get pod webapp -o yaml > my-new-pod.yaml

그 후 yaml 파일을 수정한다.

vi my-new-pod.yaml

수정 후 pod를 삭제한다.

kubectl delete pod webapp

수정된 파일로 새 pod를 생성한다.

kubectl create -f my-new-pod.yaml

방법 2

Deployment는 Pod 템플릿의 모든 필드나 속성을 쉽게 수정할 수 있다.

Pod 템플릿은 Deployment 스펙의 하위 항목이기 때문에, 수정이 있을 때마다 Deployment는 자동으로 기존 Pod를 삭제하고, 변경 사항이 반영된 새 Pod를 생성한다.

따라서 Deployment의 일부로 속한 Pod의 속성을 수정해야 한다면, 아래 명령어로 간단히 수정할 수 있다.

kubectl edit deployment my-deployment

이렇게 하면 Deployment와 관련된 Pod들이 자동으로 갱신된다.

kubectl apply와 같이 선언형 명령어는 미리 yaml 파일을 작성해야 하기에 실제 시험 환경에서는 많은 시간 낭비를 불러올 수 있다. 

반면에 명령형(Imperative) 명령어는 일회성 작업을 빠르게 처리하거나, 템플릿을 쉽게 생성하는 데 유용할 수 있다. 이는 시험 중 상당한 시간을 절약하는 데 도움이 될 것이다.

명령형 명령어를 사용하려면 먼저 2가지 옵션에 대해 익숙해질 필요가 있다.

1) 

--dry-run

기본적으로 명령어가 실행되면 리소스가 즉시 생성된다. 하지만 명령어를 단순히 테스트하고 싶다면,  --dry-run=client 옵션을 사용하면 리소스를 생성하지 않고, 리소스를 생성할 수 있는지와 명령어가 올바른지 확인해준다.

2)

-o yaml

이 옵션을 사용하면 화면에 리소스 정의를 YAML 형식으로 출력한다.

--dry-run= client 옵션과 -o yaml 옵션을 사용해서 나온 결과값을 복사해 빠르게 새로운 templete을 만들 수 있다. 이는 시간 절약에 도움이 될 것이다. 

pod

1) NGINX POD 생성

kubectl run nginx --image=nginx

2) POD 실행하지 않고 Manifest YAML 파일 생성 

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

Deployment

1)  deployment 생성

kubectl create deployment --image=nginx nginx

2) deployment 실행하지 않고 YAML 파일 생성

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

3) 복제본 선택 옵션

kubectl create deployment nginx --image=nginx --replicas=4

기존에 만들어져있는 Deployment scale을 통해 수정 가능

kubectl scale deployment nginx --replicas=4

4) '>'을 사용해 화면에 출력하지 않고 바로 yaml 파일 생성

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

이렇게 완성된 yaml 파일 kubectl apply하면 선언적 접근법으로 사용 가능하다. 

Service

1) redis pod를 접근하기 위한 CluserIP Yaml파일 생성

kubectl expose pod redis --port=6379 --name redis-service --dry-run=client -o yaml

redis pod가 이미 생성되어 있어야 사용 가능하다.

kubectl run redis --image=redis

kubectl create service clusterip redis --tcp=6379:6379 --dry-run=client -o yaml

이 옵션으로도 yaml 파일 생성 가능하나 기본적으로 selector로 app = redis를 가정하고 selector에 접근하지 않기 때문에 만약 Pod에 다른 label이 있다면 이 방법은 잘 작동하지 않는다. 따라서 파일을 생성한 후, Service를 생성하기 전에 셀렉터를 수정해야 한다.

2) 외부에서 service에 접근하기 위한 NodePort 생성 

kubectl expose pod nginx --type=NodePort --port=80 --name=nginx-service --dry-run=client -o yaml

이 방법은 selector를 자동적으로 추적 가능하나 NodePort의 port 번호를 지정해줄 수 없기 때문에 yaml 파일을 생성한 뒤 수정해 줄 필요가 있다. 

kubectl create service nodeport nginx --tcp=80:80 --node-port=30080 --dry-run=client -o yaml

이 명령어는 clusterip와 마찬가지로 label selector 추적 불가능하다. 

두 옵션 중 더 나은 옵션으로 추천받는 것은 expose 옵션이다. label을 다시 다는 것보다 NodePort를 직접 지정해주는 것이 빠르기 때문이다. 

CKA 시험 환경에서 직접 vim 에디터로 처음부터 yaml 파일을 만드는 것은 불편하고

시간이 오래걸리니 kubectl command를 통해 yaml templete을 생성할 수 있다. 

1) Create an NGINX Pod

kubectl run nginx --image=nginx

2) Generate POD Manifest YAML file (-o yaml). Don't create it(--dry-run)

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

3) Create a deployment

kubectl create deployment --image=nginx nginx

4) Generate Deployment YAML file (-o yaml). Don't create it(--dry-run)

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