kubernetes 5/17

20220307 과제1_이호재.docx

0.73MB

파드(Pod)
 - Kubernetes에서 실행 가능한 가장 작은 오브젝트
 - 하나 이상의 컨테이너를 포함
 - 파드 내의 컨테이너는 IP 주소와 저장소를 공유함

레이블
 - Kubernetes 오브젝트에 관리목적의 부가 정보를 표시하는 것

레이블 확인
kubectl get pods --show-labels

레이블 지정
kubectl label OBJECT OBJECT_NAME LABEL_KEY=LABEL_VALUE

레이블 제거
kubectl label OBJECT OBJECT_NAME LABEL_KEY-

kube-node1 보면 performance가 label에서 제거됐음.

 

annotation

kubectl annotate pods kubernetes-simple-pod prod-code=newage

기존 레이블 수정
kubectl label OBJECT OBJECT_NAME LABEL_KEY=LABEL_VALUE --overwrite


네임스페이스


Probe
 - startupProbe (초기에 정상 실행 되는지?)
 - readinessProbe (컨테이너 구동 됐다고 서비스가 되는게 x. 애플리케이션이 초기화되서 서비스 요청받을 수 있는지를 체크)
 - livenessProbe (너 살아있니?)


초기화 컨테이너
 - 파드 생성시 애플리케이션 컨테이너 실행 전 먼저 실행되어 초기화 작업을 수행하는 컨테이너 (이 애플리케이션 실행되기 전에 이건 반드시 먼저 되어있어야 해 머 이런거라는데 와닿지는 않네.)
 - initContainers 하위에 정의되며 여러개의 초기화 컨테이너를 가질 수 있음

(mydb initContainer, myservice initContainer ... 이렇게?)

인프라 컨테이너(pause)
 - 파드 내의 컨테이너에게 네트워크 등을 제공하기 위한 컨테이너

스태틱 파드(Static Pod)
 - API 서버에 요청하지 않고 kubelet이 직접 생성하는 파드
 - /etc/kubernetes/manifests/

파드에 CPU, 메모리 할당 

limits:
  cpu: CORE
  memory: xxM
requests:
  cpu: CORE
  memory: xxM

kubectl get all

limits없이 requests만 해두 대나바?

 

limits이랑 requests랑 차이가 머임?

request는 컨테이너가 생성될때 요청하는 리소스 양이고, limit은 컨테이너가 생성된 후에 실행되다가 리소스가 더 필요한 경우 (CPU가 메모리가 더 필요한 경우) 추가로 더 사용할 수 있는 부분이다.

https://bcho.tistory.com/1291

쿠버네티스 #21 - 리소스(CPU/Memory) 할당과 관리

 

pod가 사용하는 resource를 확인하기 위해서는?

kubectl top pods pod-resources

metrics-server 설치

wget https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
vim components.yaml
=======

이거 추가 안하면 인증서 문제때문에 실행이 안된대. -> 이런건 얼케 알아? 공식 사이트에 나와있어.

(내용 중 metrics-server Deployment 부분에서 139번 행 밑에 개행하여 "- --kubelet-insecure-tls" 내용 추가)
...
133       containers:
134       - args:
135         - --cert-dir=/tmp
136         - --secure-port=4443
137         - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
138         - --kubelet-use-node-status-port
139         - --metric-resolution=15s
140         - --kubelet-insecure-tls
...

=======

 

갑자기 고민)

create -f와 apply -f의 차이?

https://stackoverflow.com/questions/47369351/kubectl-apply-vs-kubectl-create

create = 이미 리소스가 존재하면 에러가 발생

apply = 리소스가 존재해도 에러 발생 안함

https://kingofbackend.tistory.com/163

metrics-server 설치
kubectl create -f components.yaml

 

watch kubectl top nodes

각 노드들 실시간으로 status 볼 수 있네

 

그냥 kubectl top nodes하면 한번 딱 찍히고

watch kubectl top nodes하면 2초마다 갱신됨

 

kubectl top pods 요것도 되네 ㅋㅋ

kubectl top pods pod-resources

(metrics-server가 구성되는 동안 잠시 기다린 후) 
메트릭 정보 확인
kubectl top nodes
NAME            CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%   
kube-control1   444m         22%    1326Mi          45%       
kube-node1      108m         10%    679Mi           36%       
kube-node2      109m         10%    760Mi           40%       
kube-node3      107m         10%    668Mi           35%  

(만일 다음 에러 발생시 아직 metrics-server가 완전히 구성되지 않았으므로 잠시 대기 후 다시 명령어 실행하여 확인)
kubectl top nodes
Error from server (ServiceUnavailable): the server is currently unable to handle the request (get nodes.metrics.k8s.io)

kube-node3으루 갔네. ㅎ

잘 보면 pod2 새롭게 추가하고 cpu, memory limits들 걸어줌 ㅋㅋ

 

한번 cpu랑 memory를 미친듯이 크게 걸어보자. 무슨 일이 벌어지나 보자구.

pending이 뜨네. 3분 넘게 지나도 안올라옴. 확인함 내가.

 

kubectl describe pods kubernetes-simple-pod3 해보면 Events: 에서 cpu랑 memory 부족하다구 뜸.

잘 보면 Node, IP 이런거 다 빠져있음 ㅋㅋ

 

개꿀팁)

이렇게 하면 한방에 지울 수 있음.

kuberctl delete pod pod-resources kubernetes-simple-pod3

이렇게 limits만 걸면 requests가 같이 생긴다. ㅋㅋ

pod-resources-limit에 접속해서 top 켜려고 했는데 아래 오류 뜨면서 안됨 ㅡㅡ 개빡쳤는데

/bin/sh로 하니까 됨. <- https://p00hp00h.tistory.com/27 이 사이트가 알려줌 ㅎㅎ

 

resource limit이 제대로 걸렸나 확인해보자.

idle 상태에서 cpu는 10m (0.1% 사용률)

md5sum 연산을 시켜보면 cpu 사용률이 치솟게 된다!

md5연산 끄면 또 10m 수준으로 다시 내려오게 됨.

이걸 위해서 터미널을 2개 띄워놓고 했단 사실.

이것도 꿀팁임! ㅎ

 

 

 

파드에 환경 변수
kubectl run -e key1=value1 (이거 아마 맞을거같다시는데? ㅋㅋ 확신 100%는 ㄴ)

파드 구성 패턴

사이드카 패턴
앰배서더 패턴
어댑터 패턴

-------

Controller
 - 다수의 파드를 제어할 수 있는 오브젝트
 - ReplicationController, ReplicaSet, Deployment, DaemonSet, Job, CronJob, StatefulSet

ReplicationController
 - 동일한 파드를 일정 갯수의 파드 복제본을 유지해주는 컨트롤러
 - 항상 replicas에 정의된 파드의 복제본의 갯수를 유지하도록 함


ReplicaSet
 - 동일한 파드를 일정 갯수의 파드 복제본을 유지해주는 컨트롤러
 - 집합성 기준의 레이블 셀렉터를 지원함


ReplicaSet 레이블 셀렉터
matchLabels (일치성 기준 레이블 셀렉터)
     matchLabels:
       LABEL_KEY: LABEL_VALUE

matchExpressions (집합성 기준 레이블 셀렉터)

     matchExpressions:
     - key: LABEL_KEY
       operator: In
       values:
       - LABEL_VALUE

근데 name은 머구 labels는 머지?

 

셀렉터는 뭐냐하면,,,

특정 라벨이 붙은 pod를 관리하는거야.

그래서 셀렉터에다가 app=rs-matchexp (app label이 rs-matchexp면 관리) 라고 해둔 것임.

 

그런데 위의 예제에서는, rs-matchexp가  아 머지

rs-matchexp-kcj2f 컨테이너가 rs-matchexp인 replicaset에 의해 관리된다네

머지???? 

아 이 template의 app labels가 rs-matchexp이라서 그런가봄.

어차피 selector는 name이 아니라 label로 관리하니까.

https://bcho.tistory.com/1256
------------------------
  8     matchExpressions:
  9     - key: app
 10       operator: In
 11       values:
 12       - rs-matchexp
-----------------------


Deployment (ReplicaSet과 거의 유사한 구조)
 - ReplicaSet에서 발전된 형태의 Controller로 Kubernetes에서 애플리케이션을 배포할 때 많이 사용되는 컨트롤러
 - 애플리케이션 배포시 롤링 업데이트를 지원하며 애플리케이션 배포 중 잠시 배포 과정을 중단하거나 다시 배포할 수 있음

보통 업데이트를 할 때, v0.1 -> v0.2) pod를 내렸다가 다시 올려야 하는데, 그렇게 안해도 되게 지원해줌.

 

Deployment는 ReplicaSet을 포함하는 구조로 되어있음.

Deployment 아래에 여러 ReplicaSet이 물려있대. v1 버전을 운영하는 ReplicaSet에서 v2 버전을 운영하는 ReplicaSet으로 스위칭하는 느낌인거같음.

 

kubectl create -f MANIFEST.yaml

kubectl describe deployment DEPLOYMENT_NAME

kubectl describe deployment REPLICASET_NAME

kubectl describe pods POD_NAME

들여쓰기 엄청 중요함. replicas, selector, template가 동등하고, template 밑에 container를 위한 spec이 들어감.

잘 보면, replicaset이 자동으로 생성됐지. deployment가 만든거야.

deployment가 만들어지기 위해서 replicaset가 만들어져야하고, replicaset이 만들어지기 위해서 pod가 만들어져야함.

이게 맞는듯?

Deployment에서 애플리케이션 업데이트 방법

방법1. Deployment 로 이미지 설정 정보 업데이트
kubectl set image deployment DEPLOYMENT_NAME CONTAINER_NAME=IMAGE_REPO:TAG [ CONTAINER2_NAME=IMAGE_REPO2:TAG]

 

kubectl set image deployment nginx-deployment nginx-deployment=nginx:1.9.1

위의 명령어 치는 순간, pod이 하나씩 바뀌다가 새걸로 다 바뀜

방법2. Manifest File에서 수정 후 적용


Deployment 롤백(Rollback)

Deployment 변경 이력 확인
kubectl rollout history deployment DEPLOYMENT_NAME

첫번째가 구버전, 두번째가 신버전.

kubectl describe deployment nginx-deployment 하면 Events에서 히스토리 볼 수 있슴

 

Deployment에는 업데이트 방법이 2가지가 있음

1. Rolling Update

2. Recreate 

recreate : downtime 발생할 수 밖에 없음. replicaset 한번에 다 죽이고, 한번에 다시 올림. default는 rolling update임.

 

이건 무슨 뜻이냐하면, 25% max unavailable : 업데이트 도중에 25%는 작동이 불가할 수 있다. (4개 pod 중 1개는 서비스 불가능일 수 있음) 하나가 꺼져야 하니까. 25% max surge : 업데이트 도중에 pod 갯수가 최대 25%까지 더 늘어날 수 있다. (pod이 최대 5개가 될 수 있음.) 왜? 맨처음에 신 pod을 하나 늘리고나서 구 pod을 지우면 throughput이 안줄잖아.

 

특정 리비전 번호의 이미지 정보 확인
kubectl rollout history deployment DEPLOYMENT_NAME --revision=REVISION_NUM

특정 리비전 번호로 롤백(rollout)
kubectl rollout undo deployment DEPLOYMENT_NAME --to-revision=REVISION_NUM

Deployment 애플리케이션 배포 중지
kubectl rollout pause deployment DEPLOYMENT_NAME

Deployment 애플리케이션 배포 재개
kubectl rollout resume deployment DEPLOYMENT_NAME

개꿀팁)

kubectl get pods --watch 하면 실시간으로 계속 변화 확인할 수 있음. 

kubectl rollout history deployment nginx-deployment --revision=2 이거 치면 해당 리비전이 무슨 image인지 알 수 있어.

kubectl rollout undo deployment nginx-deployment --to-revision=2하면 rollback 됨. ㅋㅋ

이전 버전으로 바뀌었어

아까 1,2,3이었는데 2가 없어지고 4가 생겼어.

개꿀팁)

rs, deploy 이렇게 줄여써도 됨.

 

kubectl rollout pause deploy nginx-deployment

kubectl describe deploy nginx-deployment 하면 일케 paused 됐따구 나옴.

 

 

-> 도대체 무슨 변화가 있다는거야?

 

라고 생각했는데, rollout이 pause 되는건가봐.

(원래 이미지 업데이트를 하면 바로 새로운 컨테이너로 바뀌는데, pause하면 그게 안일어나는거지.)

https://kubernetes.io/ko/docs/concepts/workloads/controllers/deployment/

디플로이먼트

 

 

쿠버네티스 #2 - 개념 이해 (1/2)

ㄴ 이건 머지 왜 여기 추가된거임? ㅋㅋ