Cka 정리2

게시 2024/10/16 업데이트 2025/01/13

By 임도훈

조회 32 분읽는 시간

CKA 정리2

64: Taints and Tolerations vs Node Affinity

파랑 빨강 녹색의 색으로 각각 3개의 노드와 파드가 있다고 하자. 목표는 색깔에 맞는 노드에 파드를 배치하는 것

노드에 다른 색의 파드가 배치되거나 파드가 다른 색의 노드에 배치되는 것을 원하지 않는다.
Taint and Toleration으로 해결하기
파란색, 빨간색, 녹색으로 노드에 taint를 적용한 다음, 각 색상을 허용하도록 pod에 toleration을 설정합니다. 이제 파드가 생성되면 노드는 올바른 toleration을 가진 파드만 수용할 수 있습니다. 따라서 녹색 파드는 녹색 노드로, 파란색 파드는 파란색 노드로 가게 됩니다. 그렇지만 taint와 toleration은 라우팅을 보장해주는 것이 아니다. 빨간 파드의 라우팅에 있어 taint가 지정되지 않은 노드가 있을 때 의도치않게 해당 노드로 배정될 수 있다

Node affinity로 해결하기

node에 label을 지정하고 파드에 nodeSelector를 설정하여 파드를 노드에 연결한다. 색깔대로 라우팅될 수 있지만 여전히 색이 없는 파드가 있는 노드로 배치될 수 있다

taints tolerations & node affinity 조합해 해결하기

위 조합으로 특정 파드에 대한 전용 노드를 설정할 수 있다

taints tolerations 설정해 노드에 의도하지 않은 다른 파드가 배치되지 않게 한다(노드 방어)
node affinity 설정해 파드가 다른 노드에 배치되지 않게 한다 (파드 지키기)

65. Resource Requirements and Limits

k8s 스케쥴러는 파드를 배치하는데 필요한 자원이 있는 노드에 배치한다. 충분한 리소스가 없다먄 예약을 보류함 파드 자원 설정(definition yaml file) spec - containers - resources에 설정

resources: requests: memory: “1Gi” cpu: 1

Resource - cpu

0.1 소수점도 가능하며 aws의 vCPU와 같다

Resource - memory

mega 혹은 gib가능하다. G는 1000megabyte이고 Gi는 1024mib이다

Resource Limits

도커 세계에서 도커 컨테이너는 노드에서 사용할 수 있는 리소스에 제한이 없습니다. 컨테이너가 노드에 있는 하나의 vCPU로 시작한다고 가정하면, 노드에 있는 기본 프로세스나 다른 리소스 컨테이너를 질식시키는 데 필요한 만큼의 리소스를 사용할 수 있습니다.

그러니 파드에서 리소스 제한을 둘 수 있다. k8s는 default로 하나의 컨테이너에 1 vCPU와 512 MiB 메모리를 할당한다

resources: requests: memory: “1Gi” cpu: 1 limits memory: “2Gi”

Exceed Limits pod가 제한을 넘을 경우 vcpu는 제한하지만 메모리는 그렇지 않다. (단, 지속적으로 메모리 한도를 초과하려 하면 종료함)

Default resource limit은 세팅해야하는거임 pod가 생성될 때 default 0.5 cpu와 256Mi를 할당받으려면 해당 namespace에 LimitRange를 생성하고 요청 및 제한에 대한 디폴트값으로 설정해야함

67. A quick note on editing pods and deployments

이미 존재하는 pod의 spec은 다음 외에는 수정할 수 없다.

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

그래서 예를들어 실행중인 파드의 환경변수, 서비스 계정, 리소스 제한을 편집할 수 없다. 하지만 정말로 원한다면 두 가지 옵션이 있다.

edit으로 touch 하여 변경된 임시 복사본 만들기
- edit으로 변경할 수 없는 속성을 편집하고 저장하려면 거부되고 /tmp 예하 위치에 pod 정의 파일이 임시저장됨
- 기존 파드를 삭제하고 임시 정의 파일을 이용하여 새 파드 생성
yaml 형식의 파드 정의 추출
- running pod를 추출
- $ kubectl get pod webapp -o yaml > my-new-pod.yaml
- 원하는 변경사항을 파일에서 수정
- 기존 파드 삭제하고 정의 파일을 이용하여 파드 생성

Edit Deployments

deployments를 사용하면 POD 템플릿의 모든 필드/속성을 쉽게 변경할 수 있다. 파드 템플릿은 deployment spec의 하위 항목이므로 변경하면 deployment가 자동으로 삭제되고 새 변경사항이 포함된 새 파드가 생성된다. 따라서 deployment의 POD 부분 속성을 편집할 때는 다음 명령어

$ kubectl edit deployment my-deployment

70. DaemonSets

replicaset처럼 여러 pod를 배포하는 것이지만 클러스터의 모든 노드에 한 pod의 사본들을 배치한다. 즉, 노드들이 하나쯤 가져야할 공통의 베이스 파드를 설정해놓는 것

로거, 모니터링 도구
kube-proxy
network

definition file replicaset과 똑같으며 kind만 다르다

apiVersion: apps/v1 kind: DaemonSet metadata: name: monitoring-daemon labels: app: nginx spec: selector: matchLabels: app: monitoring-agent template: metadata: labels: app: monitoring-agent spec: containers: - name: monitoring-agent image: monitoring-agent

생성

$ kubectl create -f def.yaml 확인
$ kubectl get daemonset

73.Static Pods

선장인 kubelet이 마스터노드나 다른 k8s 오브젝트 없이 혼자서 해낼 수 있는 것. 스태틱 팟 (원래 kubelet은 master의 api server로부터 pod 상세 정보를(definition file) 받고, scheduler를 통해 노드에 파드를 적재함)

kubelet 혼자 있는 워커 노드는 docker가 있고 pod를 생성할 능력은 있지만 상세 정보 (definition file) 제공할 api server가 없다 이 때 방법은 kubelet을 설정하여 서버의 특정 경로 디렉토리를 넘겨주어 pod definition file들을 읽도록 하는 것이다.

그럼 kubelet은 해당 디렉토리를 주기적으로 읽고 파드를 띄우며 생존을 보장한다

이러한 파드를 static pod라고 하는 이유는 다른 k8s 클러스터 오브젝트(api server 포함)나 외부 의 간섭을 받지 않기 때문임 단, pod 제외한 다른 오브젝트들은 만들 수 없음

이 디렉토리는 어떤 경로든 상관 없으며 kubelet service가 가동되는동안 –pod-manifest-path 로 넘겨진다

확인

static pods는 docker ps 명령어로 확인한다.
k8s cluster object의 통제에서 벗어난 정적 파드라는 것은 master node의 etcd에 기록되지 않고 pod controller와 api server가 알지 못하는 파드라는 것이다

근데 또 k get pods로 읽기 전용으로 읽히는데 먼지모르겠음

76: Multiple Schedulers

k8s 클러스터에 여러 스케줄러를 배포할 수 있다. 기본 스케줄러가 노드 전체에 균등하게 분배하는 알고리즘을 갖고 지정한 다양한 조건(taints, tolerations, node affinity)을 고려한다.

복잡한 체크를 한 뒤 노드에 배치해야하는 애플리케이션이 있을 때 커스텀 조건을 추가할 수 있는 자체 스케줄링 알고리즘을 만들어야 한다.

자체 스케줄러를 default 스케줄러로 배포가능
애플리케이션마다 다른 스케줄러 사용하게 할 수 있음
k8s 클러스터는 한번에 여러 스케줄러를 가질 수 있음
파드 or deployment를 생성할 때 특정 스케줄러에서 파드를 스케줄링하도록 k8s에 지시할 수 있음

정의 파일 apiVersion: kubescheduler.config.k8s.io/v1 kind: KubeSchedulerConfiguration profiles:

schedulerName: name

Deploy Additional Scheduler

이전에 k8s kube-scheduler를 배포할 때 wget으로 바이너리 다운로드하고 직접 cli로 실행했다.
추가 스케줄러 배포에 동일한 kube-scheduler 바이너리를 사용하거나 직접 정의한 것을 사용할 수 있다.

Deploy Additional Scheduler - kubeadm kubeadm을 활용해 배포하면 모든 controlplane component가 pod 또는 k8s 클러스터 내 배포되고 실행되므로 요즘 커스텀 스케줄러를 배포할 때에는 이런식으로 하지 않는다.

Deploy Additional Scheduler - Pod 스케쥴러를 파드로 배포할 수 있다.

pod definition file 생성
k8s API 서버에 연결하기 위해 인증 정보가 있는 scheduler config 파일 경로인 kubeconfig 지정

apiVersion: v1 kind: Pod metadata: name: my-custom-scheduler namespace: kube-system spec: containers:

command:
- kube-scheduler
- —address=127.0.0.1
- —kubeconfig=/etc/kubernetes/scheduler.conf
- —leader-elect=true
- —lock-object-name=my-custom-scheduler image: k8s.gcr.io/kube-scheduler-amd64:v1.11.3 name: kube-scheduler

옵션

리더 선출 옵션은 서로 다른 마스터

(이해 안되는 구간)

Use the Custom Scheduler pod definitino의 spec에 schedulerName을 추가하고 스케쥴러 이름을 기입하면 된다. spec: containers:

image: nginx name: nginx schedulerName: my-custom-scheduler

파드가 생성될 때 스케줄러가 선택되고 스케줄링된다. View Events 어떤 스케쥴러가 파드를 선택해 스케쥴링했는지 확인하는 방법

$ kubectl get events (-o wide 옵션)

79: Configuring Kubernetes Schedulers

스케쥴링을 기다리는 파드들은 스케쥴링 큐에서 정의된 우선순위에 따라 정렬된다. 우선순위를 설정하려면 우선순위 클래스를 생성하고 이름, 우선순위 값을 설정해야 한다. 우선순위대로 정렬이 되면 필터 단계로 들어간다. 파드를 실행할 수 없는 노득 필터링된다.

84: Monitoring Cluster Components

Node, Pod의 자원 cpu, memory, disk 등을 알고싶음 k8s에는 빌트인 모니터링 솔루션이 없지만 요즘 오픈소스로 다양하게 많이 있다 .

Kubelet은 서브 컴포넌트인 cAdvisor를 갖고 있다. (Container advisor) 이는 pod의 성능 metric을 검색 수집하고 kubelet API를 통해 성능을 외부로 공개해서 결국 Metrics Server가 사용할 수 있게한다.

minikube를 사용한다면
- $ minikube addons enable metrics-server
그 외
- metrics-server를 git clone
- kubectl create -f deploy/1.8+/

metrics-server는 deployment, service, clusterrole을 배포해 서버가 클러스터 내에서 성능을 측정할 수 있게 한다. 메트릭 서버가 수집할 시간을 준 뒤 다음 명령어를 사용하면 사용량을 알 수 있다.

$ kubectl top node # 노드 사용량
$ kubectl top pod # 파드 사용량

87: Managing Application Logs

k8s의 다양한 로깅 메커니즘을 알아보자 도커의 로깅

도커 이미지를 background 모드인 -d 옵션을 주고 돌리면 표준출력 print 가 안보인다.
다음 명령어를 통해서 실행중인 도커 컨테이너의 출력 로그를 볼 수 있다.
$ docker logs -f [continaer_id}

kubernetes의 로깅 pod가 동작하면 logs를 볼 수 있다 도커와 같음

$ kubectl logs -f test-pod
k8s의 pod는 여러 개의 컨테이너를 실을 수 있다. 만약 여러 컨테이너를 사용하면 어떤 컨테이너의 로그가 출될까?
이 경우 컨테이너 이름을 명시해야한다. 그렇지 않으면 에러 발생
$ kubectl logs -f test-pod container1

90: Application Lifecycle Management

애플리케이션 수명주기에 대하여

92: rolling Updates and Rollbacks

deployment의 업데이트와 롤백

첫 배포때 rollout이 실행됨. 새 롤아웃은 새로운 배포 revisions를 생성한다. 코드의 수정이 일어나고 컨테이너 버젼이 올라가며 배포할 때 새 rollout이 발생하고 새 배포 revision이 생긴다 이는 이전 배포와의 차이점을 추적할 수 있게 해주고 또한 필요하다면 롤백할 수 있게 한다.

Rollout Command

$ kubectl rollout status deployment/myapp-deployment
배포 진행(롤아웃) 상태 확인 가능

이전 배포 rollout 배포 내역을 확인하고자 할 때

$ kubectl rollout history deployment/myapp-deployment

Deployment Strategy

replicaset으로 5개의 pod가 배포돼있다고 가정해보자 StrategyType에 하위 2개를 지정하면 된다.

Recreate
- 기존 5개를 모두 내리고 신규 5개를 올린다.
- application downtime 발생
Rolling
- pod 하나씩 내리고 올린다
- default deployment 전략임

Kubectl apply

deployment를 업데이트하는 법 (도커 컨테이너 이미지 버젼만 바꾸고 싶은 경우)

정의파일 직접 수정
- $ kubectl apply -f deployment-def.yaml
cli로 이미지만 편하게 수정
- $ kubectl set image deployment/myapp-deployment nginx-container=nginx:1.9.1
- 하지만 이러면 원본 deployment-def.yaml 은 바뀌지 않아 차후 문제 동기화 생길 수 있음

Upgrades

deployment가 어떻게 upgrade를 진행할까?

롤링 업데이트 전략을 쓴다고 가정하자 deployment는 기존 ReplicaSet-1을 유지하고 신규 ReplicaSet-2을 만들고 하나씩 신규 pod를 ReplicaSet-2에 띄우고 기존 ReplicaSet-1에서는 지우는 것을 반복한다

이는 $ kubectl get replicaset에서 확인할 수 있다.

Rollback

롤백은 마찬가지로 2개의 ReplicaSet을 통해 수행하고 이전 ReplicaSet의 이전 Pod를 불러온다. $ kubectl rollback undo deployment/myapp-deployment

명령어 톺아보기

생성
- $ kubectl create -f deployment-definition.yaml
확인
- $ kubectl get deployments
업데이트
- $ kubectl apply -f deployment-definition.yaml
- $ kubectl set image deployment/myapp-deployment nginx-container=nginx:1.9.1 (이미지만)
배포 및 출시 상태 확인
- $ kubectl rollout status deployment/myapp-deployment
내역 확인
- $ kubectl rollout history deployment/myapp-deployment
롤백
- $ kubectl rollout undo deployment/myapp-deployment

95: Commands

pod definition file의 커맨드 및 arguments에 대해 다룬다.

우선 Docker의 커맨드, arguments 그리고 entrypoint에 대해 알아보자. 컨테이너는 웹 서버, 애플리케이션 서버 또는 db 인스턴스를 호스팅하거나 특정 태스크 또는 프로세스를 실행하기 위해 존재하고 작업이 완료되면 컨테이너는 종료된다. 컨테이너는 내부에서 실행되는 프로세스가 살아있어야 유지되고 중지되거나 충돌하면 종료된다.

컨테이너에서 실행할 프로세스는 CMD 커맨드에서 정의된다. (bash shell script를 실행함) 그렇다면 컨테이너를 시작하기 위한 다른 커맨드를 지정하고자 할 때는 어떻게 할까?

Docker run 명령에 커맨드를 추가한다.
- docker run ubuntu sleep 5 (ubuntu 컨테이너에 sleep 5 커맨드 추가)

영구적으로 추가하고자 할때는 도커 이미지를 정의한다. FROM Ubuntu CMD sleep 5 (혹은 CMD [“sleep”, “5”])

96: Commands and Arguments

k8s pod의 COMMAND와 arguments를 다룬다.

만약 sleep하는 시간초 파라미터를 받는 컨테이너가 있을 때 pod definition에 어떻게 전달할까? ex) 원래는 다음 명령어로 띄우던 컨테이너 $dockeru run –name ubuntu-sleeper ubuntu-sleeper 10

pod def yaml의 containers의 args에 기입한다. spec: containers:

name: ubuntu-sleeper image: ubuntu-sleeper args: [“10”]

기존 도커 파일 예시 FROM Ubuntu ENTRYPOINT [“sleep”] CMD [“5”] entrypoint는 시작 시 실행되는 커맨드고 CMD는 커맨드에 전달되는 default 파라미터이다. pod def yaml 파일의 args 옵션으로 docker 파일의 CMD를 덮어쓸 수 있다. 그러나 entrypoint를 재정의해야하는 경우 즉, 명령어 실행 프로그램인 sleep을 imaginary sleep 2.0으로 전환해야하는 경우엔 어떻게 해야 할까요?

pod definition의 “command” 인자를 활용해 재정의한다.

spec: containers:

name: ubuntu-sleeper image: ubuntu-sleeper command: [“sleep2.0”] args: [“10”]

command 필드는 도커 이미지의 ENTRYPOINT를 재정의하고 args 필드는 CMD를 재정의한다. +그래서 물론 def yaml의 command에서 ENTRYPOINT로 sleep 10 이렇게 파라미터까지 다 해도 된다.

cli로 default command를 사용하고 custom args를 설정하는 방법 $ kubectl run webapp-green –image=kodekloud/webapp-color – arg1 arg2 … argN ex) $ kubectl run webapp-green –image=kodekloud/webapp-color – –color green cli로 command도 바꾸면서 custom arguments까지 설정하는 방법 $ kubectl run webapp-green –image=kodekloud/webapp-color –command – cmd arg1 … argN ex) $ kubectl run webapp-green –image=kodekloud/webapp-color –command – python3 app.py –color green

99: Configure Environment Variables in Applications

k8s에서 환경변수 설정하는 방법! docker에서는 docker run -e 옵션을 이용하는데 k8s pods에서는 env 필드를 이용한다

spec: containers:

name: ubuntu-sleeper image: ubuntu-sleeper env:
- name: APP_COLOR value: pink

일반적인 key-value env들과 다르게 ConfigMap과 Secrets는 다른 방식으로 정해야한다

100: Configuring ConfigMaps in Applications

pod definition yaml file에서 환경 변수 env를 다뤄보았다. 하지만 env가 엄청 많으면 관리가 어려워진다. 그래서 미리 config map에 여러 변수들을 정리해놓고 파드 def file에서는 이 ConfigMap을 가져와 사용한다.

config map은 k8s에서 key-value 형태로 config 구성 정보들을 전달한다.

config map는 생성하고 파드에 주입하면 되지만 다른 k8s 오브젝트들처럼 만드는 데에는 두 가지 방법이 있다.

config map definition 파일을 만드는 declarative 방식
config map definition 파일 없이 cli로 생성하는 imperative 방식

ConfigMap 정의 yaml 파일 만들기 apiVersion: v1 kind: ConfigMap metadata: app-config data: APP_COLOR: blue APP_MODE: prod …

$ k create -f config-map.yaml

spec 대신 data가 있다.

kubectl create configmap 명령어 이용하기
- 문자열로 만들기
- $ kubectl create configmap config-name –from-literal=key=value … - 파일로부터 만들기
- $ kubectl create configmap config-name –from-file=path-to-file

확인

$ kubectl get configmaps

pods yaml에도 포함된다

spec: containers:

name: ubuntu-sleeper image: ubuntu-sleeper envFrom:
- configMapRef: name: app-config

혹은 single env의 경우 아래와 같다. spec: containers:

name: ubuntu-sleeper image: ubuntu-sleeper env:
- name: APP_COLOR valueFrom: configMapRef: name: app-config key: APP_COLOR
  103: Configure Secrets in Applications
  k8s의 secrets에 대해 알아보자 Secrets는 민감 정보를 저장하는 데 사용된다. configmap과 유사하지만 암호화된 형식 혹은 해시 형식으로 저장된다.

Secrets을 사용하는 방법

Secret을 생성한다
POD에 secret을 삽입한다.

Secret 생성하는 방법

방법1: Imperative way $ kubectl create secret generic secret-name –from-literal=key=value $ kubectl create secret generic secret-name –from-file=path-to-file

방법2: declarative way apiVersion: v1 kind: Secret metadata: app-secret data: DB_Host: bXlzcWw= DB_User: cm9vdA== …

$ k create -f secret-data.yaml

spec 대신 data가 있다.

확인 $ k get secrets $ k describe secrets 내용 확인 $ k get secret secret-name -o yaml secret값 암/복호화

암호화
- $ echo - n “db_name” base64
복호화
- $ echo - n “bX1zc” base64 -d

POD definition에 secret을 넣어 구성하기 apiVersion: v1 kind: Podmetadata: name: simple-webapp-color spec: containers: - name: simple-webapp-color image: simple-webapp-color ports: - containerPort: 8080 envFrom: - secretRef: name: app-secret (app-secret 은 사전에 정의한 secret yaml파일에 metadata-name에 입력된 이름 정보이다)

env 파일의 특정 single env만을 pod def에 넣어줄 수도 있다

104: a note about Secrets!

Secrets는 base64 형식으로 데이터를 인코딩한다. 누구나 decode하면 비밀을 알 수 있으므로 정말 안전하도 safe한 것은 아니다 그래서 다음처럼 다뤄야한다

secret definition yaml을 git에 업로드하지 않는다
ETCD에 암호화되어 저장되도록 secret에 대한 _Encrytion at REST_를 활성화합니다. 또한 아래는 kubernetes가 secret을 처리하는 방식입니다.
secret은 해당 노드의 파드에 필요한 경우에만 노드로 전송됩니다.
Kubelet은 secret이 디스크 저장소에 기록되지 않도록 비밀을 tmpfs에 저장합니다.
secret에 의존하는 Pod가 삭제되면 kubelet은 secret 데이터의 로컬 복사본도 삭제합니다.

107: Demo: Encrypting Secret Data at Rest

유휴상태의 secret 데이터를 암호화하는 법

Secret 오브젝트 생성

etcdctl cli로 etc의 secret을 읽어낸다

$ ETCDCTL_API=3 etcdct get /registry/secrets/default/secrets […] hexdump -C

$ ETCDCTL_API=3 etcdct \ —cacert=/etc/kubernetes/pki/etcd/ca.crt \ —cert=/etc/kubernetes/pki/etcd/server.crt \ —key=/etc/kubernetes/pki/etcd/server.key \ get /registry/secrets/default/secrets

hexdump -C

cert crt key는 etcd 서버에 연결 및 인증하는데 필요한 인증서 파일들

etcdctl cli 설치
- $ apt-get install etcd-client

etcdctl get을 통해 etcd에 저장된 secret 데이터를 읽어낼 수 있고 데이터는 암호화되지 않은 형식으로 저장되어 etcd에 접근할 수 있는 사람은 누구나 기밀 정보를 얻을 수 있다.

우리가 해결하려는 문제는 이것이다.

미사용 암호화 활성화 확인
- $ ps -aux grep kube-api grep “encryption-provider-config”
- 결과가 없고 활성화되지 않았다면 config 파일을 만들어야함
암호화 옵션 encryption-provider-config 전달
- config 파일 만들기
- —encryption-provider-config 옵션으로 전달

config 파일 살펴보기

reousrces - resources에서 암호화할 리소스를 선택할 수 있다. pod, deployment,secret, service 등이 있으나 모든 정보가 기밀이진 않을 것이다. 우리는 우선 secret을 다루자 providers를 이용해 데이터를 암호화할 수 있다. 여러 provider가 있다. secret box가 있고, AES, DCM, AES CBC, CBC가 있다. 이것들은 모두 다른 암호화 알고리즘 첫 공급자인 identity는 암호화를 하지 않겠다는 뜻이다

109: Multi-Container Pod

모놀로틱 아키텍쳐를 MSA로 바꾸면 개별 마이크로 서비스들의 scalability가 있지만 가끔은 서비스에 로그 서비스가 붙는 것처럼 두개가 하나로 묶여있는 서비스가 필요할 때가 있다

멀티 컨테이너 파드가 필요한 이유는 다음과 같다

서로 같은 네트워크 안에 있으므로 서로를 localhost로 호출할 수 있다
동일한 스토리지 볼륨에 액세스할 수 있다. 파드 간에 통신을 활성화하기 위해 파드 간 볼륨 공유 또는 서비스를 설정할 필요가 없다

k exec -it app -n elastic-stack – cat /log/app.log

k8s pod에 들어가서 명령어를 날릴 수 있다. (docker랑 같은 방식으로 execute에 it 옵션 사용

112: Multi Container PODs Design Patterns

멀티컨테이너 파드 구조는 일반적으로 3가지 패턴이 있다

사이드카: 앞선 로깅 서비스처럼
어댑터
앰버서더 근데 이들은 ckad 과정임
113: Init Containers
로깅 에이전트 컨테이너와 웹 애플리케이션 컨테이너는 항상 활성상태여야한다. 둘중 하나가 죽으면 둘다 재부팅해야함 그렇지만 코드, 바이너리파일이나 혹은 외부 서비스나 데이터베이스를 기다리는 작업 등 초기 한번만 동작하기 원하는 케이스도 있습니다. 이것이 초기 설정 세팅용으로 init container가 필요한 이유입니다

initcontainer는 파드 정의문 내에 구성되며 다른 파드처럼 만들어준다 apiVersion: v1 kind: Pod metadata: name: myapp-pod labels: app: myapp spec: containers:

name: myapp-container image: busybox:1.28 command: [‘sh’, ‘-c’, ‘echo The app is running! && sleep 3600’] initContainers:
name: init-myservice image: busybox command: [‘sh’, ‘-c’, ‘git clone some-repository-that-will-be-used-by-application ; done;’]

POD가 처음 생성되면 initContainer이 실행되고 애플리케이션을 호스팅하는 실제 컨테이너가 시작되기 전에 initContainer의 프로세스가 완료되어야 합니다.

멀티 initContainer도 구성할 수 있습니다. 각 초기화 컨테이너는 한 번에 하나씩 순차적으로 실행됩니다.

initContainer 중 하나라도 완료되지 않으면 Kubernetes는 Init Container가 성공할 때까지 Pod를 반복 시작

116: Self Healing Applications

k8s는 replicaset과 replication controller로 self healing app을 구축한다 replication 컨트롤러는 POD 내의 애플리케이션이 충돌할 때 POD가 자동으로 재생성되게 한다

근데 이것도 ckad내용임

infra

k8s

CKA 정리2

64: Taints and Tolerations vs Node Affinity

Taint and Toleration으로 해결하기

Node affinity로 해결하기

taints tolerations & node affinity 조합해 해결하기

65. Resource Requirements and Limits

Resource - cpu

Resource - memory

Resource Limits

67. A quick note on editing pods and deployments

Edit Deployments

70. DaemonSets

73.Static Pods

76: Multiple Schedulers

79: Configuring Kubernetes Schedulers

84: Monitoring Cluster Components

87: Managing Application Logs

90: Application Lifecycle Management

92: rolling Updates and Rollbacks

Deployment Strategy

Kubectl apply

Upgrades

Rollback

95: Commands

96: Commands and Arguments

99: Configure Environment Variables in Applications

100: Configuring ConfigMaps in Applications

103: Configure Secrets in Applications

Secrets을 사용하는 방법

Secret 생성하는 방법

104: a note about Secrets!

107: Demo: Encrypting Secret Data at Rest

109: Multi-Container Pod

112: Multi Container PODs Design Patterns

113: Init Containers

116: Self Healing Applications

인기 태그