Pod args - Exec Form
args 를 사용하면 docker container에 인수를 전달할 수 있다.
06-pod-args.yaml
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
restartPolicy: Never
containers:
- name: ubuntu
image: ubuntu
# 이 방법도 가능하고 아래 방법도 가능하다
# args: ["date"]
args:
- "date"
Pod container logs
kubectl logs [파드 이름]
ex) kubectl logs my-pod
Pod args - shell form
docker 내부에 bash로 진입해서 shell 명령어를 실행하는 방법을 pod 정의 yaml 파일에서 정의한다.
07-pod-shell-args.yaml
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
restartPolicy: Never
containers:
- name: ubuntu
image: ubuntu
args:
- "/bin/sh"
- "-c"
- "echo This is my path: $PATH"
이후 파드를 실행하고 로그를 확인해보면 yaml에 정의한 쉘 명령어가 실행된것을 확인할 수 있다.
Termination Grace Period
Pod의 종료 과정에서 kubelet이 컨테이너에게 종료 명령을 보내서 안전한 종료를 유도한다.
하지만 때로는 pod가 실제로 반응하지 않는 절전 모드에 들어갈 수 있다.
그래서 k8s는 기본적으로 30초동안 기다린 후 pod 를 삭제한다.
이 값을 변경할 수 있다.
08-pod-termination-garce-period.yaml
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
restartPolicy: Never
containers:
- name: ubuntu
image: ubuntu
args:
- "sleep"
- "3600"
해당 pod를 정의하고 실행후 삭제해보면 Status가 Terminating으로 변경되고
30초 후에 해당 pod가 삭제되는걸 확인할 수 있다.
이 때 terminationGracePeriodSeconds 를 사용해서 종료되는 시간을 변경할 수 있다.
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
restartPolicy: Never
# 이 부분을 추가한다.
terminationGracePeriodSeconds: 1
containers:
- name: ubuntu
image: ubuntu
args:
- "sleep"
- "3600"이후 pod 를실행하고 삭제해보면
1초 후 바로 pod가 삭제되는걸 확인할 수 있다.
Pod command
docker의 entrypoint가 정의되어있으면 기존 args로 명령을 내려도 반응이 없다.
09-pod-command.yaml
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
restartPolicy: Never
containers:
- name: entrypoint
image: vinsdocker/k8s-entrypoint
args:
- "date"해당 pod를 정의하고 실행해서 로그를 확인해보자
date 명령어가 제대로 실행되지 않은것을 확인할 수 있다.
command를 사용해서 명령어를 재정의할 수 있다.
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
restartPolicy: Never
containers:
- name: entrypoint
image: vinsdocker/k8s-entrypoint
command:
- "date"yaml 파일을 변경하고 다시 실행해서 로그를 확인해보면 재정의가 된 것을 확인할 수 있다.
Environment variable
pod yaml을 통해 생성하는 docker 컨테이너에 환경 변수를 전달하는 방법을 알아보자
몇가지 방법이 더 있지만 가장 기본적인 방법을 소개한다.
env를 통해서 전달할 수 있다.
10-pod-env.yaml
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
restartPolicy: Never
containers:
- name: ubuntu
image: ubuntu
env:
- name: "request.timeout"
value: "10ms"
- name: "spring.profiles.active"
value: "dev"
args:
- "env"
이제 pod를 실행하고 로그를 확인해보면
정상적으로 환경 변수들이 전달된 것을 확인할 수 있다.
Exploring Pod Container
원격 클러스터에서 실행중인 Pod에 접근하는 방법을 설명한다.
기존에 생성했던 01 pod 를 실행 시키고 내부로 접근해보자
# 파드 실행
kubectl create -f 01-simple-pod.yaml
# 파드 내부 컨테이너에 bash 쉘로 접속
kubectl exec -it my-pod -- bash내부 쉘로 접근 후 아래 명령어를 통해 내부 컨테이너에 접속한 것을 확인할 수 있다.
# 폴더 구조 보기
ls
# nginx container 이므로 curl 명령어를 통해 확인
curl localhost가가기 위해선 exit를 입력하면 된다.
Multi Container Pod - 1
지금까지는 yaml 파일을 생성해서 하나의 컨테이너만 생성을 했다.
이 부분에서는 여러개의 컨테이너를 생성해보자
11-multi-containers.yaml
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: nginx-1
image: nginx
- name: nginx-2
image: nginx
이처럼 입력하고 실행 후 확인해보면 2개의 컨테이너중 하나만 실행되고 에러가 난다.
describe를 통해 확인 해보자
이미지를 가져오는건 성공을 했고, 컨테이너 옆에서 nginx-2를 실행하는데 실패해서 재시작을 하는 것을 확인할 수 있다.
이제 문제는 nginx-2에서 발생하는 점을 확인했고
logs를 확인해보면 컨테이너가 2개이기 때문에 기본으로 nginx-1의 로그만 주는것을 확인할 수 있다.
이제 nginx-2의 대해서 로그를 확인 해보자
kubectl logs my-pod -c nginx-2
로그를 확인 해보면 이미 포트가 사용 중이기 때문에 에러가 나는것을 확인할 수 있다.
Multi Container Pod - 2
아래와 같이 변경한다
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: nginx-1
image: nginx
- name: util
image: vinsdocker/util
log를 확인해보면 util은 ubuntu 기반의 이미지 이기 때문에 실행이 완료되고 죽기 때문에 무한히 반복되는것을 확인할 수있다.
아래처럼 파일을 변경해보자
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
terminationGracePeriodSeconds: 1
containers:
- name: nginx-1
image: nginx
- name: util
image: vinsdocker/util
args:
- "sleep"
- "3600"
다시 확인을 해보면 정상적으로 2개의 컨테이너가 잘 실행되고 있는것을 확인할 수 있다.
pod로 접속해보면 기본적으로 nginx-1 로 접근되는것을 확인할 수 있다.
kubectl exec -it my-pod -- bash
# 접근 후 뜨는 log
Defaulted container "nginx-1" out of: nginx-1, util
아래 명령어를 통해 특정 컨테이너로 접근할 수 있다.
kubectl exec -it [pod name] -c [container name] -- bash
ex) kubectl exec -it my-pod -c util -- bash
이제 util 컨테이너로 접근 후 curl localhost를 입력하면 nginx에 접근하는것을 볼 수 있다.
실제로 한 pod 에서 2개의 컨테이너가 떠있지만 같은 pod 안에서는 네트워크를 공유하기 때문에 요청이 가능하다.
그래서 서로 다른 컨테이너에 접속해서 hostname 을 확인해보면 같은 호스트 name을 응답하는것을 확인할 수 있다.
요약
pod
- K8S에서 배포 가능한 가장 작은 단위이다.
- pod는 하나이상의 컨테이너로 실행할 수 있다.
- 오직 하나의 컨테이너만 어플리케이션 컨테이너여야 한다.
- 나머지 컨테이너는 도우미여야 한다. (sidecar container)
- 파드의 모든 컨테이너는 하나의 노드에서 실행된다. (파드 하나에서 여러개의 컨테이너를 실행한 경우 노드 하나에서 모두 실행된다.)
- 실제로는 직접 yaml 파일을 생성하지 않는다.
- 파드는 VM과 비슷하고 컨테이너들은 프로세스와 비슷하다.
Pod status
Pending: 노드가 아직 할당되지 않았음
ContainerCreating: kubelet이 컨테이너 생성중
Running: kubelet이 컨테이너를 시작함
ErrImagePull / ImagePullBackOff : 이미지 pull 실패. kubelet이 약간의 지연후 재시도함
Completed: 컨테이너가 성공적으로 종료됨
Error: 컨테이너가 오류와 함께 종료됨
CrashLoopBackOff: 컨테이너를 실행하는데 문제가 있음. kubelet이 지연후 재시도함 (이미지 풀링에 문제가 없을 때)
Terminating: pod 삭제중
Pod Container Restart policy
Never: Completed / Error 어떤 상황도 다시 시작하지 않음
Always: Completed / Error 어떤 상황에서도 다시 시작함
OnFailure: Error 인 경우에만 다시 시작함.
Kubectl Commands
kubectl get nodes: 클러스터의 모든 노드 확인
kubectl create -f [파일이름]: yaml파일을 기준으로 리소스 생성
kubectl delete -f [파일 이름]: yaml파일을 기준으로 리소스 삭제
kubectl get pod: 모든 파드 목록을 보여줌
kubectl get pod --show-lables: 파드의 레이블들을 보여줌
kubectl get pod -l [레이블 이름]=[레이블 값]: label을 기준으로 쿼리해서 파드를 보여줌
kubectl get pod -l [레이블 이름]!=[레이블 값]: label을 기준으로 쿼리해서 파드를 보여줌
kubectl get pod [파드 이름] -o yaml: 파드 정보를 yaml 형식으로 보여줌
kubectl describe pod [파드 이름]: 파드의 세부 정보를 보여줌
kubectl delete pod [파드 이름]: 파드 이름을 기준으로 파드 삭제
kubectl delete pod --all: 모든 파드 삭제
kubectl logs [파드 이름]: 파드의 log 확인
kubectl logs [파드 이름] -c [컨테이너 이름]: 파드의 여러개의 컨테이너중 특정 컨테이너 로그 확인
kubectl exec -it [파드이름] -c [컨테이너 이름] --bash: 파드의 컨테이너안에 쉘로 접속
kubectl port-forward [파드 이름] [호스트 포트]:[컨테이너 포트]: 디버깅을 위해 API 접속을 위해 사용
'Kubernetes' 카테고리의 다른 글
| [Kubernetes] Deployment (0) | 2024.12.16 |
|---|---|
| [Kubernetes] ReplicaSet (0) | 2024.12.12 |
| [Kubernetes] Pod 기초 - 1 (0) | 2024.11.27 |
| [Kubernetes] Cluster 학습 (0) | 2024.11.19 |
| [K8S] 쿠버네티스 기본 개념 (1) - 파드(Pod) (0) | 2023.03.18 |
Pod args - Exec Form
args 를 사용하면 docker container에 인수를 전달할 수 있다.
06-pod-args.yaml
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
restartPolicy: Never
containers:
- name: ubuntu
image: ubuntu
# 이 방법도 가능하고 아래 방법도 가능하다
# args: ["date"]
args:
- "date"
Pod container logs
kubectl logs [파드 이름]
ex) kubectl logs my-pod
Pod args - shell form
docker 내부에 bash로 진입해서 shell 명령어를 실행하는 방법을 pod 정의 yaml 파일에서 정의한다.
07-pod-shell-args.yaml
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
restartPolicy: Never
containers:
- name: ubuntu
image: ubuntu
args:
- "/bin/sh"
- "-c"
- "echo This is my path: $PATH"
이후 파드를 실행하고 로그를 확인해보면 yaml에 정의한 쉘 명령어가 실행된것을 확인할 수 있다.
Termination Grace Period
Pod의 종료 과정에서 kubelet이 컨테이너에게 종료 명령을 보내서 안전한 종료를 유도한다.
하지만 때로는 pod가 실제로 반응하지 않는 절전 모드에 들어갈 수 있다.
그래서 k8s는 기본적으로 30초동안 기다린 후 pod 를 삭제한다.
이 값을 변경할 수 있다.
08-pod-termination-garce-period.yaml
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
restartPolicy: Never
containers:
- name: ubuntu
image: ubuntu
args:
- "sleep"
- "3600"
해당 pod를 정의하고 실행후 삭제해보면 Status가 Terminating으로 변경되고
30초 후에 해당 pod가 삭제되는걸 확인할 수 있다.
이 때 terminationGracePeriodSeconds 를 사용해서 종료되는 시간을 변경할 수 있다.
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
restartPolicy: Never
# 이 부분을 추가한다.
terminationGracePeriodSeconds: 1
containers:
- name: ubuntu
image: ubuntu
args:
- "sleep"
- "3600"이후 pod 를실행하고 삭제해보면
1초 후 바로 pod가 삭제되는걸 확인할 수 있다.
Pod command
docker의 entrypoint가 정의되어있으면 기존 args로 명령을 내려도 반응이 없다.
09-pod-command.yaml
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
restartPolicy: Never
containers:
- name: entrypoint
image: vinsdocker/k8s-entrypoint
args:
- "date"해당 pod를 정의하고 실행해서 로그를 확인해보자
date 명령어가 제대로 실행되지 않은것을 확인할 수 있다.
command를 사용해서 명령어를 재정의할 수 있다.
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
restartPolicy: Never
containers:
- name: entrypoint
image: vinsdocker/k8s-entrypoint
command:
- "date"yaml 파일을 변경하고 다시 실행해서 로그를 확인해보면 재정의가 된 것을 확인할 수 있다.
Environment variable
pod yaml을 통해 생성하는 docker 컨테이너에 환경 변수를 전달하는 방법을 알아보자
몇가지 방법이 더 있지만 가장 기본적인 방법을 소개한다.
env를 통해서 전달할 수 있다.
10-pod-env.yaml
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
restartPolicy: Never
containers:
- name: ubuntu
image: ubuntu
env:
- name: "request.timeout"
value: "10ms"
- name: "spring.profiles.active"
value: "dev"
args:
- "env"
이제 pod를 실행하고 로그를 확인해보면
정상적으로 환경 변수들이 전달된 것을 확인할 수 있다.
Exploring Pod Container
원격 클러스터에서 실행중인 Pod에 접근하는 방법을 설명한다.
기존에 생성했던 01 pod 를 실행 시키고 내부로 접근해보자
# 파드 실행
kubectl create -f 01-simple-pod.yaml
# 파드 내부 컨테이너에 bash 쉘로 접속
kubectl exec -it my-pod -- bash내부 쉘로 접근 후 아래 명령어를 통해 내부 컨테이너에 접속한 것을 확인할 수 있다.
# 폴더 구조 보기
ls
# nginx container 이므로 curl 명령어를 통해 확인
curl localhost가가기 위해선 exit를 입력하면 된다.
Multi Container Pod - 1
지금까지는 yaml 파일을 생성해서 하나의 컨테이너만 생성을 했다.
이 부분에서는 여러개의 컨테이너를 생성해보자
11-multi-containers.yaml
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: nginx-1
image: nginx
- name: nginx-2
image: nginx
이처럼 입력하고 실행 후 확인해보면 2개의 컨테이너중 하나만 실행되고 에러가 난다.
describe를 통해 확인 해보자
이미지를 가져오는건 성공을 했고, 컨테이너 옆에서 nginx-2를 실행하는데 실패해서 재시작을 하는 것을 확인할 수 있다.
이제 문제는 nginx-2에서 발생하는 점을 확인했고
logs를 확인해보면 컨테이너가 2개이기 때문에 기본으로 nginx-1의 로그만 주는것을 확인할 수 있다.
이제 nginx-2의 대해서 로그를 확인 해보자
kubectl logs my-pod -c nginx-2
로그를 확인 해보면 이미 포트가 사용 중이기 때문에 에러가 나는것을 확인할 수 있다.
Multi Container Pod - 2
아래와 같이 변경한다
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: nginx-1
image: nginx
- name: util
image: vinsdocker/util
log를 확인해보면 util은 ubuntu 기반의 이미지 이기 때문에 실행이 완료되고 죽기 때문에 무한히 반복되는것을 확인할 수있다.
아래처럼 파일을 변경해보자
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
terminationGracePeriodSeconds: 1
containers:
- name: nginx-1
image: nginx
- name: util
image: vinsdocker/util
args:
- "sleep"
- "3600"
다시 확인을 해보면 정상적으로 2개의 컨테이너가 잘 실행되고 있는것을 확인할 수 있다.
pod로 접속해보면 기본적으로 nginx-1 로 접근되는것을 확인할 수 있다.
kubectl exec -it my-pod -- bash
# 접근 후 뜨는 log
Defaulted container "nginx-1" out of: nginx-1, util
아래 명령어를 통해 특정 컨테이너로 접근할 수 있다.
kubectl exec -it [pod name] -c [container name] -- bash
ex) kubectl exec -it my-pod -c util -- bash
이제 util 컨테이너로 접근 후 curl localhost를 입력하면 nginx에 접근하는것을 볼 수 있다.
실제로 한 pod 에서 2개의 컨테이너가 떠있지만 같은 pod 안에서는 네트워크를 공유하기 때문에 요청이 가능하다.
그래서 서로 다른 컨테이너에 접속해서 hostname 을 확인해보면 같은 호스트 name을 응답하는것을 확인할 수 있다.
요약
pod
- K8S에서 배포 가능한 가장 작은 단위이다.
- pod는 하나이상의 컨테이너로 실행할 수 있다.
- 오직 하나의 컨테이너만 어플리케이션 컨테이너여야 한다.
- 나머지 컨테이너는 도우미여야 한다. (sidecar container)
- 파드의 모든 컨테이너는 하나의 노드에서 실행된다. (파드 하나에서 여러개의 컨테이너를 실행한 경우 노드 하나에서 모두 실행된다.)
- 실제로는 직접 yaml 파일을 생성하지 않는다.
- 파드는 VM과 비슷하고 컨테이너들은 프로세스와 비슷하다.
Pod status
Pending: 노드가 아직 할당되지 않았음
ContainerCreating: kubelet이 컨테이너 생성중
Running: kubelet이 컨테이너를 시작함
ErrImagePull / ImagePullBackOff : 이미지 pull 실패. kubelet이 약간의 지연후 재시도함
Completed: 컨테이너가 성공적으로 종료됨
Error: 컨테이너가 오류와 함께 종료됨
CrashLoopBackOff: 컨테이너를 실행하는데 문제가 있음. kubelet이 지연후 재시도함 (이미지 풀링에 문제가 없을 때)
Terminating: pod 삭제중
Pod Container Restart policy
Never: Completed / Error 어떤 상황도 다시 시작하지 않음
Always: Completed / Error 어떤 상황에서도 다시 시작함
OnFailure: Error 인 경우에만 다시 시작함.
Kubectl Commands
kubectl get nodes: 클러스터의 모든 노드 확인
kubectl create -f [파일이름]: yaml파일을 기준으로 리소스 생성
kubectl delete -f [파일 이름]: yaml파일을 기준으로 리소스 삭제
kubectl get pod: 모든 파드 목록을 보여줌
kubectl get pod --show-lables: 파드의 레이블들을 보여줌
kubectl get pod -l [레이블 이름]=[레이블 값]: label을 기준으로 쿼리해서 파드를 보여줌
kubectl get pod -l [레이블 이름]!=[레이블 값]: label을 기준으로 쿼리해서 파드를 보여줌
kubectl get pod [파드 이름] -o yaml: 파드 정보를 yaml 형식으로 보여줌
kubectl describe pod [파드 이름]: 파드의 세부 정보를 보여줌
kubectl delete pod [파드 이름]: 파드 이름을 기준으로 파드 삭제
kubectl delete pod --all: 모든 파드 삭제
kubectl logs [파드 이름]: 파드의 log 확인
kubectl logs [파드 이름] -c [컨테이너 이름]: 파드의 여러개의 컨테이너중 특정 컨테이너 로그 확인
kubectl exec -it [파드이름] -c [컨테이너 이름] --bash: 파드의 컨테이너안에 쉘로 접속
kubectl port-forward [파드 이름] [호스트 포트]:[컨테이너 포트]: 디버깅을 위해 API 접속을 위해 사용
'Kubernetes' 카테고리의 다른 글
| [Kubernetes] Deployment (0) | 2024.12.16 |
|---|---|
| [Kubernetes] ReplicaSet (0) | 2024.12.12 |
| [Kubernetes] Pod 기초 - 1 (0) | 2024.11.27 |
| [Kubernetes] Cluster 학습 (0) | 2024.11.19 |
| [K8S] 쿠버네티스 기본 개념 (1) - 파드(Pod) (0) | 2023.03.18 |
