참고
쿠버네티스 오브젝트
NOTE
쿠버네티스 오브젝트 ⇒ 쿠버네티스 시스템 내에서 영속성을 가지는 오브젝트!
YAML(의도 표현) ⇒ apiVersion, kind, metadata, spec 4가지 요소를 잘 기억하자
쿠버네티스 오브젝트는 스펙과 상태를 가지고 있으며, 스펙과 상태간의 차이에 대해서 계속해서 확인하고 대응한다.
•
apiVersion : 오브젝트를 생성하기 위해 사용하고 있는 쿠버네티스의 API 버전
•
kind : 어떤 종류의 오브젝트를 생성하고자 하는지
•
metadata : 오브젝트를 구분지어 줄 데이터
•
sepc : 오브젝트에 대한 어떤 상태를 의도하는지
쿠버네티스에서 사용가능한 API 버전은 kubectl api-versions 명령으로 확인이 가능하다.
버전에 따라 다르게 나온다.
Pod
NOTE
쿠버네티스가 배포할 수 있는 가장 작은 단위
Pod 생성과정
# 실행중인 포드 확인
kubectl get pod
# 실행중인 포드 상세확인
kubectl describe pod [포드이름]
# 포드 생성
kubectl apply -f [yaml 파일이름]
kubectl run [pod 이름] --image=[이미지 이름]
# 포드 삭제
kubectl delete pod [포드 이름]
Bash
복사
Pod 관련 명령어
Pod 생성
NOTE
apiVersion: v1
kind: Pod # 타입지정
metadata:
name: redis
spec:
containers:
- name: redis
image: redis # 이미지 지정
YAML
복사
Pod 생성 (기본방법)
apiVersion: v1
kind: Pod
metadata:
name: counter
labels:
app: counter
spec:
containers:
- name: app
image: ghcr.io/subicura/counter:latest
env:
- name: REDIS_HOST
value: "localhost"
- name: db
image: redis
YAML
복사
Pod에 2개의 컨테이너를 사용하는 방법
각 pod마다 고유한 IP를 부여받기 때문에, ip를 통해 내부적으로 통신이 가능하다.
보통 pod에는 컨테이너가 1개 있지만, 여러개가 존재할 수도 있다.
•
pod로 묶이면 host 폴더를 공유할 수 있고,localhost 네트워크 포트번호를 공유할 수 있다!
컨테이너 상태 모니터링
NOTE
컨테이너 생성과 서비스 준비는 약간의 차이가 있다!
컨테이너가 만들어졌지만, 내부에서 실행준비하는 텀이 존재한다. (라이프사이클 존재)
•
서버를 실행하자마자 바로 접속할 수 없으며, 초기화 시간이 필요하다.
•
실제로 서비스 접속이 가능할 때, 서비스가 준비되었다고 할 수 있다.
•
아래에 /non/exist요청은 실제로 존재하지 않는다.
상태 체크(livenessProbe, readinessProbe)
NOTE
컨테이너 생성과 서비스 준비는 약간의 차이가 있다!
apiVersion: v1
kind: Pod
metadata:
name: echo-lp
labels:
app: echo
spec:
containers:
- name: app
image: ghcr.io/subicura/echo:v1
livenessProbe:
httpGet:
path: /not/exist
port: 8080
initialDelaySeconds: 5 # 컨테이너를 시작한후 증명예약 시간
timeoutSeconds: 2 # # 해당 시간안에 증명못하면 실패
periodSeconds: 5 # 해당 시간초마다 livenessProbe 수행
failureThreshold: 1 # 한번이라도 실패하면 컨테이너 재시작
YAML
복사
실패시 컨테이너를 몇번 재시작할것인가?
RESTARTS가 4번 진행되고, CrashLoopBackOff 상태로 변경됨
apiVersion: v1
kind: Pod
metadata:
name: echo-rp
labels:
app: echo
spec:
containers:
- name: app
image: ghcr.io/subicura/echo:v1
readinessProbe:
httpGet:
path: /not/exist
port: 8080
initialDelaySeconds: 5
timeoutSeconds: 2 # Default 1
periodSeconds: 5 # Defaults 10
failureThreshold: 1 # Defaults 3
YAML
복사
실패시 컨테이너를 실행하지 않는다.
증명에 실패하므로 실행되지 않음
컨테이너 보안설정(securityContext)
NOTE
securityContext는 파드 및 컨테이너의 실행과 관련된 보안 관련 설정을 정의할 수 있게해주며, 다양한 보안 기능과 제한을 적용할 수 있다!
apiVersion: v1
kind: Pod
metadata:
spec:
containers:
- name: #...
securityContext: # 컨테이너 수준
capabilities:
add: ["SYS_TIME"]
apiVersion: v1
kind: Pod
metadata:
spec:
containers:
- name: # /...
securityContext: # 컨테이너 수준
readOnlyRootFilesystem: true
allowPrivilegeEscalation: false
securityContext: # 파드수준
runAsUser: 1000
runAsGroup: 3000
fsGroup: 2000
YAML
복사
파드 수준의 설정
해당 파드 내의 모든 컨테이너와 볼륨에 대한 기본 보안 설정이된다.
•
runAsUser: 파드 내의 모든 컨테이너가 실행될 사용자 ID
•
runAsGroup: 파드 내의 모든 컨테이너가 실행될 그룹 ID
•
fsGroup: 파드에 의해 마운트된 모든 볼륨에 대한 파일 시스템 그룹 ID
컨테이너 수준의 설정
특정 컨테이너에 대한 보안관련 설정을 진행할 수 있다.
•
privileged: 컨테이너가 특권모드로 실행될지 여부
•
readOnlyRootFilesystem: 컨테이너의 루트 파일시스템을 읽기 전용으로 설정
•
allowPrivilegeEscalation: 컨테이너 내에서 권한상승이 가능한가?
•
capabilities: 컨테이너 프로세스에 부여하거나 제거할 기능
정적포드
NOTE
특정 경로(/etc/kubernetes/manifests/)에 존재하는 yaml팡리에 대해 kublet이 자동으로 Pod로 생성하는 것!
해당 폴더의 경로에 yaml이 있다면, 자동으로 Pod가 생성된다.
정적포드 vs 데몬
•
kube-APIServer에 의하지 않고 kubelet이 Pod를 생성 및 관리하는것이 특징이다.
•
정적 파드는 Pod만 생성이 가능하고, ReplicaSet 등의 리소스는 생성이 불가능하다.
•
클러스터의 컴포넌트(kube-API, etcd 등)을 정적 파드로 생성해 장애를 방지하고 설치를 용이하게 하는 등의 목적으로 사용한다.
•
정적 포드는 controlplane의 이름으로 생성된다.
파드 라이프사이클
NOTE
파드의 라이프사이클은 쿠버네티스에서 파드가 생성되어 종료될때까지의 여러 단계를 포함한다!
라이프 사이클 흐름
파드가 실행되는 동안, kubelet은 일종의 오류를 처리하기 위해 컨테이너를 다시 시작할 수 있다. 파드내에서 쿠버네티스는 다양한 컨테이너 상태를 추적하고 파드를 다시 정상 상태로 만들기 위해 취할 조치를 결정한다.
Pod - Pending
NOTE
파드가 쿠버네티스 클러스터에서 승인되었지만, 하나 이상의 컨테이너가 설정되지 않았고 실행할 준비가 되지 않았다는 의미이다!
이미지의 크기가 크면 pending 시간이 오래걸린다. 하지만 이미지를 다 받았음에도 pending 상태라면 문제가 있다는 의미이다.
pending이 지속되는 이유
•
배치할 수 있는 노드가 없어(자원부족 및 스케줄링 조건) 스케줄링 불가
•
이미지를 잘못 지정해서 이미지를 못받는 경우
•
프라이빗 레지스트리 인증이 잘못된 경우
•
컨테이너가 만들어 졌지만 실행될 준비가 되지 않음
•
볼륨이 연결되지 않음
Pod 상태 - Running, Succeeded, Failed
NOTE
Running
•
파드가 노드에 바인딩 되었고, 모든 컨테이너가 생성되었다.
•
적어도 하나의 컨테이너가 아직 실행중이거나, 시작/재시작 중에 있다.
Succeeded
•
파드에 있는 모든 컨테이너들이 성공적으로 종료되었고, 재시작되지 않는다.
•
Return Code, Exit Code이 0인것은 정상 종료
Failed
•
파드에 있는 모든 컨테이너가 종료되었고, 적어도 하나 이상의 컨테이너가 실패로 종료되었다.
•
즉 해당 컨테이너는 non-zero, 혹은 시스템에 의해서 종료되었다.
Pod 문제상태 - Unknown, CrashLoopBackOff, ImagePullBackOff
NOTE
Unknown
•
어떤 이유로 파드의 상태를 결정할 수 없을 때의 상태입니다.
•
일반적으로 파드를 호스트하는 노드와의 통신 문제로 인해 발생합니다.
CrashLoopBackOff
•
파드 내의 컨테이너가 반복적으로 시작을 시도하고 계속 실패하여 재시도 사이에 백오프(back-off) 대기 시간을 갖고 있는 상태입니다.
ImagePullBackOff
•
파드가 컨테이너 이미지를 가져오는데 실패하여 백오프 상태에 있는 경우입니다.