쿠버네티스는 모든 리소스가 오브젝트 형태로 관리된다.
예를 들어 컨테이너의 집합인 포드, 컨트롤러, 사용자 혹은 노드가 쿠버네티스의 오브젝트로 생성이되서 관리가 된다.
쿠버네티스의 오브젝트에는 어떤 것이 있는지 보려면 kubectl api-resources 명령어를 사용해 확인할 수 있다.
apiversion 은 yaml 파일 생성할 때 각 오브젝트마다 지정해야 할 apiversion이 있고 나중에 다룰 네임스페이스 개념을 포함하는지에 대한 여부 등을 확인할 수 있다.
포드(pod)
쿠버네티스 오브젝트 중 가장 작고 기본 단위는 포드이다. 포드는 1개 이상의 컨테이너로 구성된 컨테이너의 집합이며 같은 포드에 속한 컨테이너들은 동일한 네트워크를 가지고 있다. 도커 네트워크에서 컨테이너 네트워크의 개념과 흡사하다.
보통 하나의 포드 안에는 컨테이너 하나가 작동하는것이 원칙이지만 사이드카 컨테이너라는 것과 함께 1개 이상의 컨테이너와 같이 포드를 구성할 수도 있다. 예를 들어 웹서버 컨테이너와 이 해당 웹서버의 로그를 수집하는 컨테이너는 같은 포드로 구성하는 것이 편리할 수 있다. 로그 수집 컨테이너가 사이드카 컨테이너로 웹서버와 같이 동작된다.
포드와 같은 오브젝트를 생성할때 kubectl 명령어로 run 또는 create를 통해 생성할 수 있지만 YAML 파일로 오브젝트를 생성하는 것이 더 일반적이다. 기록이 남기도하고 추후 오브젝트의 상태를 변경할 때도 편리하기 때문이다.
apiVersion: v1
kind: Pod
metadata:
name: my-nginx-pod
spec:
containers:
-name: my-nginx-container
image: nginx:latest
ports:
- containerPort: 80
protocol: TCP
YAML 파일은 일반적으로 apiVersion, kind, metadata, spec 네가지 항목으로 구성이 된다
- apiVersion: 각 오브젝트마다 명시해야 할 apiVersion이 존재한다. kubectl api-resources 명령어로 확인 가능하다
- kind: 해당 리소스의 종류를 나타낸다. api-resources로 확인할 수 있다.
- metadata: 라벨, 주석 등 리소스의 부가 정보를 입력한다
- spec: 리소스를 생성하기 위한 자세한 정보를 입력한다.
작성한 YAML 파일은 kubectl create -f 혹은 kubectl apply -f 명령어로 생성할 수 있다. create는 처음 리소스를 생성할 때 써야 하고 apply는 처음과 수정할 때 사용해야 한다.
kubectl apply -f nginx-pod.yaml
kubectl get <오브젝트 이름> 하면은 특정 오브젝트의 목록을 확인할 수 있다.
kubectl get pods
또는 api-resources에서 확인할 수 있는 shortnames를 사용해도 된다
kubectl get po
--output 혹은 -o 옵션으로 다양한 형태의 목록을 확인할 수 있다. 포드를 더 자세하게 보려면 -o wide 옵션으로, json은 -o json으로 yaml은 -o yaml로 확인한다
kubectl get pods -o wide
kubectl get pods -o json
kubectl get pods -o yaml
get 명령어 말고 describe <오브젝트 이름> 하면 자세하게 특정 오브젝트를 확인할 수 있다.
kubectl desribe pods my-nginx-pod
도커와 같이 exec, logs 명령어도 사용할 수 있다.
kubectl exec -it my-nginx-pod bash
kubectl logs my-nginx-pod
포드 안에 컨테이너가 여러 개 있다면 -c 옵션으로 컨테이너 이름을 정해 특정 컨테이너에 명령어를 실행할 수 있다
생성된 오브젝트의 상태를 수정하고 싶을 때는 kubectl edit 명령어 혹은 생성할 때 사용한 YAML파일을 수정한 뒤 kubectl apply -f 명령어를 사용하면 처음 지정한 값들을 변경할 수 있다.
오브젝트를 삭제할 때는 kubectl delete -f nginx-pod.yaml 혹은 kubectl delete pod my-nginx-pod로 삭제할 수 있다.
처음 쿠버네티스 오브젝트를 생성할 때 YAML 파일로 시작하게 된다면 어떤 옵션들이 있는지 잘 모르고 어렵고 낯설게 느낄 수 있다. 그래서 --dry-run 옵션으로 kubectl 명령어를 YAML 파일로 출력해 줄 수 있는 기능을 사용하는 것이 처음에는 권장한다.
kubectl run webserver --image=nginx:1.14 --port 80 --dry-run -o yaml > webserver-pod.yaml
YAML파일 작성하는 공식문서는 아래와 같다
https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/
Liveness Probe
쿠버네티스는 liveness probe를 통해 포드가 self-healing 하는 기능을 포함한다.
apiVersion: v1
kind: Pod
metadata:
name: nginx-pod
spec:
containers:
- name: nginx-container
image: nginx:1.14
livenessProbe:
httpGet:
path: /
port: 80
위와 같이 livenessProbe를 설정하고 포드가 건강한지에 대한 방법을 명시해 건강상태를 체크한다.
Liveness Probe 종류
- httpGet probe:
- 지정한 IP주소, port, path에 HTTP GET 요청을 보내, 해당 컨테이너가 응답하는지를 확인한다. 반환 코드가 200이 아닌 값이 나오면 오류, 컨테이너를 다시 시작한다.
-
livenessProbe: httpGet: path: / port: 80
- tcpSocket probe
- 지정된 포트에 TCP 연결을 시도. 연결되지 않으면 컨테이너를 다시 시작한다.
-
livenssProbe: tcpSocket: port: 22
- exec probe
- exec 명령을 전달하고 명령의 종료 코드가 0이 아니면 컨테이너를 다시 시작한다.
-
livenessProbe: exec: command: - ls - /data/file
Livenss probe 매개 변수
- periodSeconds: health check 반복 실행 시간(초)
- initialDelaySeconds: Pod 시행 후 delay 할 시간(초)
- timeoutSeconds: health check후 응답을 기다리는 시간(초)
- failureThreshold: Minimum consecutive failures for the probe to be considered failed after having succeeded. Defaults to 3. Minimum value is 1.
- successThreshold: Minimum consecutive successes for the probe to be considered successful after having failed. Defaults to 1. Must be 1 for liveness and startup. Minimum value is 1.
'Kubernetes' 카테고리의 다른 글
쿠버네티스 포드 디자인 패턴 및 포드 설계 (0) | 2021.11.06 |
---|---|
쿠버네티스 잡(Job) 및 크론잡(CronJob) (0) | 2021.10.18 |
쿠버네티스 데몬셋 (0) | 2021.10.17 |
쿠버네티스 컨트롤러 (0) | 2021.10.17 |
쿠버네티스 설치 (0) | 2021.09.22 |