Kubernetes 3일차 주요사용 리소스, Label, 파드의 생명주기, Replication Controller, Replicaset

*리소스 분류

<Workload>

pods

 

<Workload-Controller>

replicationcontrollers

daemonsets

deployments

replicasets

statefulsets

horizontalpodautoscalers

cronjobs

jobs

 

<Network>

services

endpoints

ingresses

 

<Storage>

persistentvolumeclaims

persistentvolumes

storageclasses

 

secrets

configmaps

 

<RBAC>

clusterrolebindings

clusterroles

rolebindings

roles

serviceaccounts

certificatesigningrequests

 

<Resource>

limitranges

namespaces

resourcesquotas

 

<Etc>#기타..

nodes

 

*파드 지우기

kubectl delete pods myapp-pod

 

*3장 POD label selector

**Label

라벨 기능을 통해 검색을 용이하게 할 수 있다.

metadata 항목에 labels 로 지정할 수 있고, 딕셔너리 형태로 키,value를 갖는다.

 

kubectl get pods --show-labels # 파드의 레이블까지 확인 kubectl get pods -L env,tier # 특정 레이블을 필드로 표시

 

현재 myapp-pod 파드에는 레이블이 없는 상태

kubectl label myapp-pod env=dev # env 키에 dev 밸류를 레이블로 수정

 

현재 myapp-pod-label 에는 레이블이 env=dev 가 이미 있는 상황에서 덮어씌우고 싶다?

kubectl label myapp-pod-label env=debug --overwrite # --overwrite로 덮어씌우기

 

*label 지우기

test 파드의 label이 현재 app=myapp-sp, env=debug 라 하자

kubectl label po test app- env- # app라벨 삭제, env라벨 삭제

**selector

1)일치성 기준 

kubectl get pods --show-labels -l tier # tier 키가 있는 파드를 레이블과 함께 확인 kubectl get pods --show-labels -l tier=frontend kubectl get pods --show-labels -l env!=debug # env 키 값을 갖지만 value로 debug가 아닌 것

 

2)집합성 기준

kubectl get pods --show-labels -l 'env in (debug,dev)' kubectl get pods --show-lables -l 'tier notin (frontend)'

 

**어노테이션(annotation)

주석같은것이지만 주석은 아니고, 참조값?

alias 같은 느낌? vm의 description 의 느낌? 으로 생각하면 될 것 같다.

지금 환경이 calico 네트워크면 파드 생성시 기본적으로 

Annotations 로 cni.projectcalico.org/podIP: 머시기 이렇게 되어있는데

kuectl describe pod myapp-pod 를 통해 정보를 확인할 수 있는 것

 

**네임스페이스(namespace)

리소스들을 분리시키는 역할을 한다.

kubectl get pods -n kube-system #kube-system namespace의 파드들을 보여준다

 

kubectl get ns # namespace를 보여준다

#yaml 파일에 metadata 하위에 namespace 를 지정해줄 수 있다

<yaml 파일을 이용하여 namespace 생성>

kubectl create -f qa-ns.yaml

 

kubectl create -f myapp-pod.yaml -n development # 오브젝트 생성 시 네임스페이스 지정

***네임스페이스를 활용한 파드 검색

kubectl get pods -n development # development namespace를 갖는 파드들 정보

 

-n으로 지정해주지 않으면 namespace는 default 네임스페이스이다.

 

kubectl delete namespace development # development namespace 삭제 kubectl delete pods -l tier=frontend # 레이블을 이용한 오브젝트 삭제도 가능

 

! 네임스페이스를 삭제한다고 해당하는 pod가 삭제X, namespace가 default로 변경되는 것 !

 

**파드의 생명주기와 프로브

***파드 생명주기 

kubectl get pods -o json 으로 status 밑에 phase 로 확인 가능

kubectl get pods -o jsonpath='{.status.phase}'

pending -> running -> succedded or failed

1)pending 파드가 스케줄링되기 전, 이미지 풀링 까지의 과정

2)running 파드가 노드에 할당됨, 하나 이상의 컨테이너가  실행중 

3)succeeded 모든 컨테이너가 정상적으로 종료, 재시작 X

4)Failed 모든 컨테이너 종료, 하나 이상 컨테이너가 실패

 

***컨테이너 상태

waiting = running 또는 termicated 상태가 아닌 상태

ruuning = 실행중

terminated = 컨테이너 실행이 완료, 실패

 

***컨테이너 프로브

kubelet이 컨테이너를 주기적으로 진단하는 프로브 핸들러를 호출한다

HTTPGetAction, TCPSocketAction, ExecAction 세가지의 매커니즘을 갖고 컨테이너 상태를 진단

****프로브 핸들러 상태 세가지

success: 진단통과, Failure: 진단에 실패, Unknown: 진단 자체가 실패

 

****프로브의 종류

1)livenessProbe: 컨테이너가 동작중인지 확인, 진단 실패 시 재시작 정책적용,기본 상태는 success

2)readinessProbe: 컨테이너가 요청을 처리할 준비가 되었는지 확인

3)startupProbe: 컨테이너 내의 어플리케이션이 시작됐는지 확인, startupProbe가 진단을 통과하기 전에느 다른 프로브 활성 X

path: /health?code=404 로 일부러 오류를 내서 오류확인해보자

<정상적으로 200 코드 응답이 돌아올 것을 예측가능>

 

<일부러 오류를 낸것이기 때문에 계속 restarts를 할것이다>

<지수 백오프 지연이 발생한 모습>

 

kubectl describe pod myapp-pod-liveness-404 #event 로그 확인

*워크로드-컨트롤러

**레플리케이션 컨트롤러

파드가 특정개수만큼 복제되고 동작하는 것을 보장한다.

복제본3개다! 라고 선언하면 컨트롤러가 복제본 3개를 유지시켜주는 것 

최초의 레플리케이션 리소스 만들기 위해서는 파드를 생성해야함, 파드-템플릿으로..

selector를 통해 label 을 선택하고 label에 해당하는 파드를 관리한다

 

apiVersion: v1 kind: ReplicationController metadata:   name: myapp-rc spec:   replicas: 3   selector: app: myapp-rc   #select 할 label   template:            #파드 템플릿 metadata:   labels:     app: myapp-rc    #컨테이너의 label spec:   containers:   - name: myapp     image: ghcr.io/c1t1d0s7/go-myweb     ports:     - containerPort: 8080 #myapp-rc.yaml

 

kubectl get rc myapp-rc # 레플리케이션 컨트롤러 확인

 

kubectl label pod myapp-rc-fb8sr app=abc --overwrite # label을 기준으로 관리하기 때문에 overwriting하여 label이름을 교체하면 그냥 새로운 하나의 파드가 되고, 기존에 관리하던 label을 갖는다

 

kubectl scale rc myapp-rc --replicas=4#복제할 파드의 수를 scale 명령어로 늘리거나 줄일수있다

 

위와같이 

kubectl edit rc myapp-rc # editing을 통해 replicas의 integer를 수정하고 관리파드수를 조절가능

 

yaml 파일에서 replicas=3 으로 해주었기 때문에 돌리려면

kubectl replace -f myapp-rc.yaml 로 다시 관리 파드수를 3개로 설정해줄 수 있다.

 

**레플리카셋

레플리케이션 컨트롤러의 대체, 똑같은 기능을 한다

레이블 selector의 인자를 두개중에 선택가능하다.

1. matchLabels

레플리케이션 컨트롤러와 똑같이 작동, label의 key와 value 모두 필요하다

1. matchExpressions

label의 key,value 일치 뿐만아니라 key값만 일치시키거나 불일치 시킬 수 있다.

 

***matchExpressions 를 이용한 작성 

apiVersion: apps/v1 kind: ReplicaSet metadata:   name: myapp-rs-exp spec:   replicas: 3   selector:     matchExpressions:   - key: app     operator: In     values:         - myapp-rs-exp   - key: env     operator: Exists   template: metadata:   labels:     app: myapp-rs-exp     env: dev spec:   containers:   - name: myapp     image: ghcr.io/c1t1d0s7/go-myweb     ports:     - containerPort: 8080

probe 설정을 해주려면? ⇒ template 안에다가 작성 

template의 spec이 pod의 spec이기 때문이다.