5. 쿠버네티스 Workload / Config

1 1. Pod
- 1.1 1.1 Pod 개요
2 2. 워크로드 리소스
- 2.1 2.1 ReplicaSet
- 2.2 2.2 Deployment
- 2.3 2.3 DaemonSet
- 2.4 2.4 Static Pod
3 3. 컨피그맵
- 3.1 3.1 컨피그맵 사용
4 4.시크릿
- 4.1 4.1 불투명(Opaque) 시크릿 사용

실습환경 연결

먼저 Vagrantfile이 있는 폴더로 위치한다.
osc-edu1@DESKTOP-VLF5KR3 MINGW64 ~/vagrant/2024_k8s (main) $ ls Vagrantfile edu/ extra-k8s-pkgs.sh* k8s_pkg_cfg.sh* controlplane_node.sh* extra-k8s-pkgs/ k8s_env_build.sh* worker_nodes.sh*
현재 VM 상태를 확인한다.
$ vagrant status Current machine states: cp-k8s-1.29.2 running (virtualbox) w1-k8s-1.29.2 running (virtualbox) w2-k8s-1.29.2 running (virtualbox) w3-k8s-1.29.2 running (virtualbox) This environment represents multiple VMs. The VMs are all listed above with their current state. For more information about a specific VM, run `vagrant status NAME`.
master node에 들어간다.
osc-edu1@DESKTOP-VLF5KR3 MINGW64 ~/vagrant/2024_k8s (main) $ vagrant ssh cp-k8s-1.29.2
만일 poweroff라면 vagrant up 명령어를 수행한뒤 3번으로 진입한다.

TIp> 아래와같이 forwarding된 포트가 있으면 바로 진입이 가능하다.

이 세팅은 Vagrantfile에서 아래와 같이 세팅한다.

특정 포트를 열기위해서는 아래와 같이 세팅한다.

세팅후 reload로 cofiguration을 반영한다.

file위치는 master node의 아래에 위치한다.

root@cp-k8s:~/2024_k8s/edu# pwd
/root/2024_k8s/edu
root@cp-k8s:~/2024_k8s/edu# ls
10 12 13 15 3 5 6 7 8 9 Readme.md

1. Pod

1.1 Pod 개요

쿠버네티스 노드 내에 한개 이상의 컨테이너를 가진 파드가 각각 실행되고 있으며, 파드마다 다른 IP를 가지고 있고 파드 내의 컨테이너끼리는 통신이 가능합니다.
파드 내 컨테이너끼리 볼륨을 공유하며 컨테이너가 죽고 재시작 되어도 파드가 살아있는 한 shared volume은 유지할 수 있습니다.
init-container(초기화 컨테이너) :파드의 앱 컨테이너들이 실행되기 전에 실행되는 특수한 컨테이너로 유틸리티 또는 스크립트 등을 포함할 수 있습니다.

(1) Pod Lifecycle

value	description

value	description
Pending	파드가 클러스터에 승인되었지만, 하나 이상의 컨테이너가 설정되지 않았고 실행할 준비가 되지 않은 상태입니다.
Running	파드가 노드에 바인딩되었고, 모든 컨테이너가 생성된 상태. 하나의 컨테이너가 아직 실행 중이거나, 시작 또는 재시작 중에 있는 상태입니다.
Succeeded	파드에 있는 모든 컨테이너들이 성공적으로 종료되었고, 재시작되지 않는 상태입니다.
Failed	파드에 있는 모든 컨테이너가 종료되었고, 적어도 하나 이상의 컨테이너가 실패로 종료된 상태입니다.
Unknown	어떤 이유에 의해서 파드의 상태를 얻을 수 없는 상태. 일반적으로 파드가 실행되어야 하는 노드와의 통신 오류로 인해 발생합니다.

(2) kubectl run으로 pod 생성

또한 dry-run 옵션과 -o옵션을 이용하여 yaml파일을 간단하게 생성 할 수 도 있습니다

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

(3) yaml 형식으로 pod 생성

5/00-nginx-pod.yaml

value	description

value

description

apiVersion

오브젝트를 생성하기 위해 사용할 쿠버네티스 API 버전을 명세합니다.

https://kubernetes.io/ko/docs/concepts/overview/kubernetes-api/

kind

어떤 종류의 오브젝트를 생성하고자 하는지 명세합니다.

ex) pod, services, replicaset ...

metadata

name, UID, namespace 등을 기본적인 정보를 포함합니다.

name: 특정 namespace에서 유일한 값으로 설정
labels: 특정 오브젝트만 나열하거나 검색할 때 사용되는 key-value 쌍
spec: 생성할 오브젝트의 구체적인 내용을 정의. spec에 대한 포맷은 오브젝트의 종류마다 다릅니다.

(4) pod 조회, 수정 및 삭제

(5) 운영중에 이미지 버전 바꾸기 (===> nginx:latest로 변경 )

(6) Pod 설정 변경

파드 설정 변경 시, 변경 불가 항목인 경우 백업파일 생성 → 백업파일로 생성 가능
Pod.metadata.name: test-nginx ==> test-nginx3

새로 yaml 파일을 만들어서 생성

(7) Pod 정보 확인

(8) Pod 구성 설명서

apiVerion은 아래와 같이 확인 할 수 있습니다

모든데이터는 key: value 형태로 정의 합니다 :(콜론)와 value 사이에는 꼭 띄어쓰기가 들어가야 합니다.

(9) kubectl 자동완성

2. 워크로드 리소스

2.1 ReplicaSet

파드를 생성 및 복제하고 복제된 파드의 개수를 yaml 파일에서 선언된 개수 만큼 지속적으로 유지합니다.

5/01-replicaset.yaml

yaml 파일에 선언된 대로 3개의 Pod가 실행되며, 하나의 Pod가 문제가 발생했을 경우 ReplicaSet은 문제가 생긴 파드를 지우고, 기존 것과 다른 IP와 Name을 가진 파드를 새롭게 구동시킵니다.

2.2 Deployment

Deployment는 쿠버네티스가 어플리케이션의 인스턴스를 어떻게 생성하고 업데이트 해야하는지를 지시합니다.
Replica 개수변경을 통해 손쉬운 Pod 증설/축소 가능합니다.
Deployment는 파드가 구동될 때, 가장 리소스 사용량이 적은 쪽으로 여러 개의 파드를 구동시킬 수 있습니다.

5/02-deployment.yaml

2.3 DaemonSet

모든 노드에 동일한 파드를 생성해야 할 필요가 있는 경우에 사용합니다.
쿠버네티스 클러스터에 Worker Node 증설 시, 자동으로 증설 된 Node에 Pod가 생성됩니다.
모니터링(데이터 수집) 등 경우에 사용합니다.

2.4 Static Pod

모든 Node가 Kubernetes Cluster 내에서 정상적으로 동작하기 위해서는 노드 시작(부팅)과 동시에 실행되어야할 Pod가 존재하며, 이를 Static Pod라고 지칭합니다.
Static Pod는 노드의 Kubelet 데몬이 실행되면서 자동으로 기동됩니다.
/etc/kubernetes/manifest 경로에 yaml 파일이 존재합니다.
- kube-apiserver, kube-controller-manager, kube-scheduler

3. 컨피그맵

Key-Value 쌍으로 기밀이 아닌 데이터를 저장하는 데 사용하는 API 오브젝트입니다.
컨테이너 이미지에서 환경 별 구성을 분리하여, 애플리케이션을 쉽게 이식할 수 있습니다.
개발/운영 환경의 컨테이너는 동일하게 구성하고, 컨피그맵 설정을 다르게 적용하여 서비스를 관리할 수 있습니다.
파드와 컨피그맵은 동일한 네임스페이스에 있어야 합니다.

3.1 컨피그맵 사용

(1) 컨피그맵을 생성합니다.

5/03-configmap.yaml

(2) 컨테이너에서 prod-account 컨피그맵의 LOG_LEVEL값을 가지고 오도록 설정합니다.

5/04-cm-deployment.yaml

(3) 설정이 제대로 되었는지 파드 안에서 확인합니다.

4.시크릿

비밀번호, OAuth 토큰, ssh 키와 같은 민감한 정보를 저장하는 용도로 사용됩니다.
시크릿 생성 시 데이터는 base64로 인코딩되어 저장됩니다.
컨피그맵은 보안/암호화를 제공하지 않기 때문에, 저장하려는 데이터가 기밀인 경우, Secret을 사용하여 데이터를 비공개로 유지합니다.
- 시크릿은 ETCD에 암호화되지 않은 상태로 저장되기 때문에, API 접근 권한이 있는 모든 사용자는 시크릿을 조회/수정 할 수 있습니다.
TLS 인증서를 시크릿으로 저장하여 사용하는 경우도 많습니다.
secret 리소스의 type 필드로 타입을 명시 할 수 있습니다.

빌트인 타입	사용처

빌트인 타입	사용처
`Opaque`	임의의 사용자 정의 데이터
`kubernetes.io/service-account-token`	서비스 어카운트 토큰
`kubernetes.io/dockercfg`	직렬화 된(serialized) `~/.dockercfg` 파일
`kubernetes.io/dockerconfigjson`	직렬화 된 `~/.docker/config.json` 파일
`kubernetes.io/basic-auth`	기본 인증을 위한 자격 증명(credential)
`kubernetes.io/ssh-auth`	SSH를 위한 자격 증명
`kubernetes.io/tls`	TLS 클라이언트나 서버를 위한 데이터
`bootstrap.kubernetes.io/token`	부트스트랩 토큰 데이터

4.1 불투명(Opaque) 시크릿 사용

(1) 명령어로 시크릿 생성

(2) yaml 파일로 시크릿 생성

yaml 파일로 생성시 필요 값들을 base64로 인코딩된 값을 넣어야 합니다.

시크릿을 생성합니다.

5/05-secret.yaml

생성된 시크릿을 확인합니다.

(3) 시크릿 사용

5/06-secret-deployment.yaml

파드 안에서 시크릿 데이터를 확인합니다.

실습파일을 정리합니다.