Kubenetes는, 프로그램(애플리케이션)을 Container 로 배포, 확장 및 관리할 때 사용하는 시스템
Docker Container 를 배포하고 orchestration 하는 표준 시스템임
Kube 는 여러 머신을 위한 docker-compose 라고 생각할 수 있음
docker-compose 는 하나의 머신 위에 여러 Container 를 띄우고 관리하고
Kube 는 더 나아가 여러 머신 위에 여러 Container 를 띄우고 모두 관리(배포, 모니터링 등)함
Kube 없이 수동으로 Container 를 배포하면, Container 가 떠야 할 서버를 직접 구성 및 관리해야하며
Container 관리, 즉 보안, 구성, Container 간 충돌, Container down 등의 이슈도 직접 처리해야 함
Container down 이 발생 할 때마다 직접 모니터링하고 이슈를 해결하고
수동으로 재배포해줘야 하는 번거로움이 있음 (근데 이건 Kube 써도 마찬가지 아닌가)
Container 로 들어오는 트래픽이 양이 변할 때 Container Scaling 을 수동으로 처리해야 하며
트래픽을 모든 Container 에 고르게 분산시키기 위해 추가 작업을 해야 함
Kube 를 사용하면 자동 배포, Scaling, 로드 밸런싱, Container 관리 등을 손쉽게 할 수 있음
Kube 는 (EC2 처럼 CPU, RAM 이 장착된 Physical/Virtual 머신인) 하나 이상의 Worker Nodes 로 이루어져 있으며
Worker Nodes 는 (실제 Container 와 동일한) 하나 이상의 Pods (=Containers) 와
(Pods 의 네트워크 트래픽 제어를 위한) Proxy/Config 로 이루어져 있음
Prox/Config 는 Pods 가 외부 인터넷에 연결 가능한지 여부와
외부 인터넷에서 (Pods 내부에서 실행되는) Container 로 어떻게 접근할 수 있는지를 제어함
Kube 를 사용하여 Container 및 Pod 를 동적으로 추가/제거하는 경우
Kube 가 사용 가능한 Worker nodes 에 Pods 가 자동으로 배포됨
따라서 서로 다른 여러 Worker Nodes 위에서, 여러 Containers 를 실행하여 워크로드를 고르게 분배 가능함
Worker Nodes 에 Pods 를 새로 띄우거나, (실패하거나 필요하지 않은 경우) Pods 를 교체하거나 종료하는 역할은
Master Node 에 의해 진행됨
Master Node 는 Worker Nodes 처럼 하나의 머신임
Master Node 위에서 실행되는 Control Plane 이 위 작업을 수행하게 됨
Control Plane 은 Master Node 에서 실행되는 다양한 서비스의 다양한 도구 모음이며,
Worker Nodes 를 제어하는 컨트롤 센터같은 거라고 생각하자.
우리가 Kube 를 사용할 때, Worker Nodes, Pods 와 직접 상호작용하지 않음(일반적으로 하지 않음)
Kube 와 Control Plane 이 우리 대신 Worker Nodes, Pods 와 상호작용 함
Master Node 와 Worker Nodes 가 하나의 Cluster 안에 포함되며
Cluster 내 Nodes 들은 하나의 네트워크를 형성하여 서로 통신이 가능함
EC2 위에 띄운 Master Node 는 Cloud Provider(예를 들어 AWS) 의 API 에 다음과 같은 명령을 보내 Cluster 를 구축함
"내가 지금부터 너의 서비스들을 이용하여 Kube 를 실행할 Cluster 를 만들꺼야.
Worker Nodes 만들 EC2 3대를 생성하고, 로드 밸런싱을 위한 로드 밸런서, ... 등을 실행해 줘"
그리고 Master Node 에서 Kube 와 Kube 툴을 실행하고
AWS 로부터 받은 리소스(EC2, 로드 밸런서 등)를 이용하여 Pods 를 띄우는 등의 작업을 진행함
Kube 사용자가 (Cloud Provider 도움 없이) Kube 를 사용하기 위해 해야 할 일들이 있음
Kube 는 infrastructure 에 대해 전혀 신경쓰지 않기 때문에
사용자가 infra 를 미리 구축해주어야 함
Nodes 로 사용될 머신들 (AWS 의 경우 EC2) 을 준비해야하며
준비된 모든 Nodes 에 Kube (API Server, kubelet 등의 Kube services, softwares) 를 설치해야 함
필요하다면, cloud provider 로부터 얻을 수 있는 로드 밸런서 등의 리소스를 미리 준비
사용자가 위와 같은 infra 리소스들(Nodes, 로드 밸런서 등)을 준비해두면
Kube 는 이 리소스들을 알아서 운용함
Worker Node 에 대해 자세히 알아보자.
Worker Node 는 (위에서 설명한 것처럼) 하나의 머신이며
Master Node 에 의해 관리됨
Worker Node 안에서 하나 이상의 Pods 가 있고
이 Pods 또한 Master Node 에 의해 관리됨
(따라서 Worker Node 가 Pod 를 삭제할 수 없음)
Worker Node 에 꼭 설치되어 있어야하는 것들은 다음과 같음
- Docker : Pods 내 Container 실행에 사용됨
- kubelet : Master Node 와 통신할 때 사용됨
- kube-proxy : (Pods 내 Container 에 의해) 해당 node 로 들어오고 나가는 네트워크 트래픽을 처리할 때 사용됨
AWS 를 사용하는 경우, 위에서 언급한 필요한 머신(instance) 및 소프트웨어들을 AWS 가 알아서 설치해준다고 함
Pods 는 하나 이상의 Containers 를 실행하고 있음
일반적으로 pod 하나에 Container 하나 실행
Pods 는 Container 외에 Volumes 같은 리소스도 실행 가능(..!)
이 Volume 은 Container 가 사용 가능한 저장소임
Pods 는 Containers(와 Volumes) 를 묶는 논리적인 단위 같은 거라고 이해하면 편할 듯
kubelet 은 Worker Node 에 존재하며,
다음과 같이 노드 및 파드 운영에 큰 역할을 담당하고 있음
- 파드 관리 : Master Node 로부터 할당된 파드를 Worker Node 에 배치하고 실행
파드 상태 주기적으로 모니터링하고 문제 발생시 다시 시작
- 컨테이너 실행 : 파드에 정의된 Container 를 실행하고 관리
Container 시작/중지 및 리소스 할당
- 리소스 모니터링 및 보고 : Worker Node 의 리소스 사용량 모니터링하여 클러스터 상태 파악
모니터링 정보는 Master 에 보고되고, 클러스터 스케줄링할 때 사용됨
- 상태 모니터링 및 보고 : Worker Node 및 파드 상태를 Master 에 보고함
이를 통해 Master 는 전체 클러스터 상태 파악이 가능
- Worker Node 자동 복구 : Worker Node 가 비정상적으로 종료되면 자동으로 복구 시도
이를 통해 Worker Node 의 가용성을 유지하고 안정성을 보장
Master Node 에 대해 자세히 알아보자.
Master Node 는 (위에서 설명한 것처럼) 하나의 머신이며
Worker Node 를 관리함
Master Node 에 꼭 설치되어 있어야하는 것들은 다음과 같음
- API Server : Worker Node 의 kubelet 과 통신할 때 사용
- Scheduler : Pods 들을 관찰하고, Pod 를 생성할 Worker Node 를 선택하는 일을 담당
(Pod 다운되었거나, 비정상적이거나, 스케일링으로 새로 Pod 를 생성하는 경우)
Scheduler 가 API Server 에게 "Pods 2 대 새로 생성해" 같은 요청 전달하면
API Server 가 그걸 받고 실제 작업을 하나 봄
- Kube-Controller-Manager : Worker Node 전체를 감시하고 제어, Pods 가 의도된 수만큼 떠있는지 확인하는 역할
그래서 API Server, Scheduler 와 긴밀하게 연동된다고 함
- Cloud-Controller-Manager : Cloud-Controller-Manager 는 Cloud Provider 에게 무슨 일을 해야하는지 알려줌
Cloud Provider 에 의해 달라진다고 하는데 구체적으로 뭐가 다른지는 아직 모르겠음
Pods 를 묶는 논리적인 그룹을 Service 라고 함
(위에서 언급된) Poxy 와 연관이 있음
Service 는 특정 Pod 를 외부 세계에 노출하여
특정 IP 혹은 Domain 으로 특정 Pod 에 연결할 수 있도록 하는 용어임...(???)
그럼 Pod 끼리 (Service 에 의해 제공된) IP 로 통신한다는 말이 되나?
Kube 사용자는 kubectl 을 통해 사용자가 원하는 명령을 kube(정확히는 Master Node) 에 대신 전달하도록 할 수 있음
kubectl 는, 새로운 deployment 생성, deployment 삭제, 변경 같은 명령을
kube Cluster 에 보내는 데 사용되는 도구임
minikube 를 통해 local 컴퓨터에 kube 를 설치해서 테스트베드로 사용할 수 있음
minikube 를 통해 kube 가 구체적으로 어떻게 동작하는지 알아보자
kube 는 몇 가지 Objects 들이 제 역할을 함으로써 동작함
여기서 Objects 는 언어의 객체 이런 게 아니라, kube 의 핵심 파트 한 부분 부분을 의미한다고 보면 됨
kube 의 Objects 는 Pods, Services, Deployments, Volume..... 등임
사용자가 명령적 방식 혹은 선언적 방식 두 방식 중 하나를 통해
kube 에 "이러저러한 Objects 를 사용하는 이 코드를 실행시켜줘" 라고 명령함
그럼 kube 는 그 코드를 그대로 실행하고, 사용자가 원하는 것이 실행됨
Pod object 를 알아보자
Pod 는 kube 에 의해 상호 작용하는 가장 작은 유닛. kube 는 pods 와 pods 내 containers 를 관리함
Pods 는 기본적으로 cluster 내부 IP 를 갖고 있음 (사용자가 ip 수정 가능)
Pods 내에 여러 containers 가 있는 경우, 이 containers 은 localhost 를 통해 서로 통신한다고 함
사용자가 코드를 통해 kube 에게 Pods 를 생성하라고 명령을 보내면
kube 는 worker nodes 중 하나를 선택하고 그 위에 pods 를 생성 및 실행함
pods 는 container 처럼 일시적으로 올라가는 것임. pods 가 내려가면 그 동안의 모든 데이터가 손실됨
pods 에 이상이 생기면, kube 가 알아서 pods 를 재실행함
deployment object 를 알아보자
deployment 는 사용자의 desired state 를 담고 있는, 일종의 명령서같은 것
deployment 는 kube 로 작업할 때 만지게 될 주요 object 중 하나임.
왜냐하면 deployment 를 통해 kube 에 다양한 실행 명령을 내릴 수 있기 때문
deployment 를 통해 하나 이상의 pods 를 제어할 수 있고, 내부적으로 컨트롤러 객체를 생성할 수 있음
사용자는 deployment 를 통해 pods 를 띄우거나 함 (사용자가 deployment 없이 pods 를 직접 띄우지는 않는 듯)
deployment 를 일시중지 하거나, 삭제하거나, 롤백할 수 있음
만약 새로 배포한 deployment에 이상이 생겼다면 바로 롤백해서 그 전 deployment 상태로 되돌릴 수 있다는 말임
이런 기능을 시스템적으로 제공함
deployment 는 다이나믹하게 그리고 자동으로 scaling 이 가능함
사용자는 deployment 에 n 개의 pods 를 띄워달라고 설정할 수 있고 그에 맞게 scaling 이 됨
혹은 traffic 이 많아지면 pods 개수를 늘리는 등의 scaling 설정도 가능함
service object 를 알아보자
Service 는 Pods 혹은 Pods 내의 Container 에 접근하기 위해 필요한 object 임
Service 는 Pods 의 ip 를 노출시켜, 다른 Pods 가 ip 가 노출된 Pods 에 접근 가능하도록 만들거나
혹은 외부에서 ip 가 노출된 Pods 에 접근 가능하도록 만듦
각 Pods 는 기본적으로 cluster 내부 IP 를 갖고있는데, 외부에서 이 ip 를 통해 Pods 에 접근이 불가능함
또한 Pods 의 내부 ip 는 Pods 가 교체 될 때마다 변경됨
이런 특징들은 Pods 를 사용할 때 꾸준히 문제가 되는데, Service 가 이를 해결해줄 수 있음
Service 는 Pods 를 그룹화하고 고정된 공유 IP 주소를 제공함
하나의 Service 내에 여러 pods 가 포함되어있고, Service 는 이 pods 에 접근 가능한 하나의 고정된 ip 를 제공하는 것임.
service 가 제공하는 ip 는 다른 Pods 혹은 외부에서 접근 가능함
흠.. service 가 제공하는 ip 가 하나뿐이라면,
내부에 각 pods 는 어떻게 구분해서 접근 가능한거지? port number 로 구분하나..?
kube 에서 객체들을 띄우기 위한 방법을 두 가지 제공함
명령적 접근방식 vs 선언적 접근방식
명령적 접근 방식은 deployment, service 등을 띄우는 명령어를 직접 입력하여 하나씩 띄우는 것
마치 docker run 을 여러번 하여 containers 를 띄우는 것과 같음
선언적 접근 방식은 띄우고 싶은 객체들의 정보를 입력해 둔 config 파일(yaml) 을 만들고 이 yaml 을 이용하여 한 번에 띄우는 것
마치 docker-compose 를 통해 한 번에 여러 container 를 띄우는 것과 같음
예를 들어 다음과 같이 config 파일인 yaml 파일을 만들 수 있음
apiVersion: apps/v1 kind: Deployment metadata: name: first-app spec: selector: matchLabels: app: first-dummy replicas: 3 template: metadata: labels: app: first-dummy spec: containers: - name: first-node image: "first-app" |
config 파일을 이용하려면 아래처럼 kubectl apply 라는 명령어 사용
kubectl apply -f first-app.yaml
kube 는 yaml 에 설정된 것을 유지하기 위해 노력함
예를 들어 pods 가 하나 죽어서 live pods 가 3개에서 2개가 되었다면
yaml 의 상태(pods 의 replicas 는 3)를 맞추기 위해, 하나를 새로 띄워서 3개를 맞춤
사용자가 yaml 을 업데이트하면, kube 는 그 업데이트 된 사항을 확인하고 그대로 환경을 구성함
Deployment 를 생성하는 yaml 파일을 만들어봄.
공식 문서를 계속 참고 및 확인할 것
https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.26/#deployment-v1-apps
apiVersion: 현재 kube 에 맞는 apiVersion 을 찾아서 넣음
선언적 접근 방식을 사용한다면 반드시 넣어야 함
"kubenetes deployment apiversion" 등으로 검색해서 나온 최신 버전 yaml 샘플 등에서 발췌하여 넣으면 됨
예를 들면 아래 스샷과 같이 "apps/v1"
kind: Deployment Kube 에서 생성하고 싶은 Object 를 넣음
예를 들어 Deployment, Service, Job 등
metadata : 생성하는 Object 의 이름 등의 정보를 넣음
예를 들어 kind 에 Deployment 가 추가되었다면, 아래처럼 Deployment 의 이름을 first-app 으로 명명
name: first-app
spec : 생성하는 Object 의 사양(spec) 정보를 넣음
예를 들어 위 kind 에 Deployment 가 추가되었다면, (아래처럼) 구성하고 싶은 Deployment 의 사양을 입력
replicas: 3 pods 의 개수를 지정. default 는 1이며 (처음에 pod 를 띄우고 싶지 않다면) 0으로도 지정 가능
selector: deployment 가 계속 관리해야 할 pod 의 라벨을 넣음. pod 의 라벨은 아래 다시 설명됨
matchLabels:
app: first-dummy
deploy: second-dummy
tier: third-dummy
여기서 pod 의 라벨이 3개 추가되었음. 이 말 뜻은, 3개 라벨이 충족하지 않거나, 다른 라벨을 갖는 pod 는
해당 deployment 에 의해 관리되지 않는다는 말임.
deployment 에 속한 pods 를 deployment 에게 알려준다고 할 수 있음...
template: pod 에서 동작할 Container Image 를 정의하는 부분
위 kind 가 Deployment 이기 때문에, 여기서의 template 은 PodTemplateSpec 이 되며 [문서]
PodTemplateSpec 에는 metadata 와 spec 두 가지를 추가할 수 있음 [문서]
(kind: Pod) 파드Object 만들기 위해 추가.
위 kind 가 Deployment 라면 여기 kind 는 자동으로 Pod 가 되어
여기 kind (kind: Pod) 생략 가능
metadata: pod 는 kube 세계의 새로운 Object 이기 때문에 metadata 를 한 번 더 중첩시켜 넣어줌
labels: deployment 에 의해 관리될 pod 의 라벨 설정. 사용자가 원하는 labels 을 여럿 추가할 수 있음
app: first-dummy
deploy: second-dummy
tier: third-dummy
spec: Pod 의 사양을 정의. 위 Spec 은 Deployment 의 사양이고, 여기 Spec 은 Pod 의 사양
containers: Pod 안에 올라갈 Container 리스트를 정의. 예를 들어 두 가지 Container 를 띄운다면
- name: first-node
image: mydockerhub/first-app
- name: second-node
image: mydockerhub/second-app:4
이렇게 만들어진 yaml 파일 이름이 mykubecluster.yaml 이라고 하자
이 yaml 을 기반으로 kube 에 클러스터를 띄우려면 kubectl apply 명령어 사용
kubectl apply -f=mykubecluster.yaml
deployment 를 실행한 이후에, 아래 명령어들을 이용하여 Objects 가 잘 떴는지 확인
kubectl get deployments
kubectl get pods
위 deployment 를 위한 yaml 외에, service 를 위한 yaml 을 추가해봄
만들어지는 yaml 파일 이름은 사용자가 정하면 됨. 이를테면 myservice.yaml 등
[service v1 core Documentation]
apiVersion: v1 kind: Service metadata: name: backend spec: selector: app: first-dummy deploy: second-dummy tier: third-dummy port: - protocol: 'TCP' port: 80 #외부 (로 노출되는) 포트 targetPort: 8080 #(외부 포트와 연결되는) 내부 포트 - protocol: 'TCP' port: 443 targetPort: 443 type: ClusterIP |
service 의 selector 는 deployment 의 selector 와 마찬가지로,
해당 service 에게 제어되거나, 연결되어야 하는 다른 리소스를 식별하는 데 사용함
deployment 에 의해 생성된 pods 를 service 의 selector 에 추가하여 설정 가능
만약 두 개의 deployments A, B 가 있고
A deployment 는 x:x, y:y 라벨을 갖는 pods 를 갖고
B deployment 는 x:x 라벨만 갖는 pods 를 갖는다고 하자
Service select 에 x:x 만 설정해두면 A deployment 의 pod 와 B deployment 의 pod 모두를 대상으로 설정하여
해당 Service 의 그룹에 포함시켜 Service 에 의해 제어되도록 할 수 있음
참고로 Service 의 selector 는 matchLabels 밖에 없음
이렇게 Service 의 selector 로 pods 그룹을 설정한다고 해도
pods 그룹만 알 뿐이지 구체적으로 어떤 pods 가 (Service 에 의한 port 에) 노출되어야 하는지는 아직 모름
port 를 통해 pods 가 외부에서 오는 어떤 port 를 받을 수 있게 할건지(port: 80)
외부에서 오는 요청이 내부 시스템의 어떤 port 로 연결되게 할 건지(targetPort: 8080) 설정할 수 있음
type 에는 여러 값을 넣을 수 있음
- ClusterIP : default. 내부적으로 노출된 IP. 클러스터 내부에서만 접근 가능하며, 클러스터 내부 pod 들끼리 통신 가능
해당 타입의 Service 에 속한 pod 에 들어오는 요청을 자동으로 모든 pod 로 분산
- NodePort : 기본적으로 실행되는 worker node 의 ip 와 port 에 노출
- LoadBalancer : 외부 세계에서 pod 로 접근을 원하는 경우 사용. 가장 일반적으로 사용됨
외부에서 사용 가능한 IP 주소를 생성하고
실행되는 (pod 가 어떤 노드에 떠 있느냐에 관계없이) 모든 pod 에 들어오는 요청을 자동으로 분산하고
생성된 고정 IP주소는 Pod 가 실행되는 노드와 독립적임
이렇게 만들어진 myservice.yaml 을 kube 에 올릴때는 아래 명령어 사용
kubectl apply -f myservice.yaml
service 를 실행한 이후에, 아래 명령어를 이용하여 service 가 잘 떴는지 확인
kubectl get services
kube 에 올라간 deployments 나 services 의 설정을 업데이트하고 싶다면
yaml 파일을 업데이트하고 다시 실행(kubectl apply -f ...)하면 됨
그러면 업데이트 된 내용이 kube 클러스터에 자동으로 반영됨
kube 에 올라간 리소스(deployments, services...) 를 삭제하고 싶을 때는
delete 명령어에 삭제할 리소스 이름(metadata.name)을 넣어서 사용
kubectl delete deployment first-app
kubectl delete service backend
혹은 아래처럼 yaml 파일 이름 자체를 넣어, yaml 에서 생성한 모든 리소스들 삭제 가능
kubectl delete -f=mykubecluster.yaml
kubectl delete -f=myservice.yaml
kubectl delete -f=mykubecluster.yaml, myservice.yaml
kubectl delete -f=mykubecluster.yaml -f=myservice.yaml
위에 예제에선 두 개의 yaml 을 사용하여 리소스를 띄웠고
두 yaml 의 리소스들이 서로 협력하여 일 하도록 만들었음
어짜피 같이 일 하게 될꺼라면 하나의 yaml 에 넣어도 되지 않을까? 가능함.
두 개의 yaml 내용을 하나의 yaml 에 합치려면 아래와 같이 진행하면 됨
| < myservice.yaml > apiVersion: v1 kind: Service metadata: name: backend .... |
| < mykubecluster.yaml > apiVersion: apps/v1 kind: Deployment metadata: name: first-app .... |
| < total.yaml > apiVersion: v1 kind: Service metadata: name: backend .... --- apiVersion: apps/v1 kind: Deployment metadata: name: first-app .... |
두 yaml 내용 사이에 "---" 를 꼭 넣어줘야 함
"---" 는 yaml 에서 Object 를 구분하는 기호라고 함
위와 같이, 여러 yaml 을 묶을 때는 Service Object 를 위한 yaml 을 먼저 배치하는 게 좋다고 함
리소스는 위에서 아래로 내려오면서 차례대로 생성되어 Service 가 먼저 생성됨
Service 는 이후 생성되는 pods 등의 라벨을 보면서, Service 에 지정된 라벨이 생성되는지 확인함
지정된 라벨의 pods 가 생성되면 동적으로 Service 에 추가됨
위 예제의 deployments 설정 yaml 에서 selector 로 matchLabels 을 사용했는데
matchLabels 말고 matchExpressions 를 사용할 수 있음
https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.26/#labelselector-v1-meta
예를 들어 아래와 같은 matchLabels selector 를 matchExpressions selector 로 바꾼다고 하자
| < matchLabels selector > selector: matchLables: app: second-app tier: backend |
| < matchExpressions selector > selector: matchExpressions: - {key: app, operator: In, values: [first-app, second-app]} |
key 는 Label 의 key 값
values 는 Label 의 value 값
operator 에 In, NotIn, Exists, DoesNotExist 등이 들어갈 수 있음
위에서 사용된 In 은 values 리스트에 포함되어있으면 match 됨
예를 들어 어떤 pod 의 Label 이 app:second-app 이라면, 위 matchExpressions selector 에 의해 match 됨
만약 NotIn 을 선택했다면, app:second-app Label 을 갖는 pods 는 match 에서 제외될 것임
kube 에서 실행된 Container 가 우리 의도에 따라 정상적으로 실행 중인지 검사하는 방법을 직접 정의할 수 있음
예를 들어 위 예제에서 deployment yaml 의 pods spec.containers 를 보자.
| apiVersion: apps/v1 kind: Deployment metadata: name: first-app spec: selector: matchLabels: app: first-dummy replicas: 3 template: metadata: labels: app: first-dummy spec: containers: - name: first-node image: "first-app" livenessProbe: httpGet: path: / port: 8080 periodSeconds: 10 initialDelaySeconds: 5 |
livenessProbe : Container 가 구동된 이후 잘 실행중인지 검사하기 위해 설정하는 값들
httpGet : http 의 get 요청이 pods 에서 실행중인 application 으로 전달되어야 함을 의미
periodSeconds : 작업을 수행 빈도(초단위). 10을 넣으면 10초
initialDelaySeconds : kube 가 처음으로 상태를 확인할 때까지 기다려야 하는 시간(초단위) 5를 넣으면 5초
kube 자체적으로 Container 가 죽으면 다시 띄워주긴 하지만
Container 내부 app 이 이상한 방향으로 동작하거나
kube 가 알아차리지 못하는 방식으로 죽어버리는 상황을 대비하기 위해
사용자가 직접 "/:8080 으로 10초간 ping 을 보내서 제대로 동작하는지 확인해봐" 라고 검사 설정을 해둘 수 있음
'Docker' 카테고리의 다른 글
| [Docker] Udemy Docker & Kubernetes : 실전 가이드 필기 - Kubernetes 네트워킹 (0) | 2024.01.21 |
|---|---|
| [Docker] Udemy Docker & Kubernetes : 실전 가이드 필기 - Kubernetes 데이터 & 볼륨 (0) | 2024.01.15 |
| [Docker] Udemy Docker & Kubernetes : 실전 가이드 필기 - Docker Compose (0) | 2023.11.15 |
| [Docker] Udemy Docker & Kubernetes : 실전 가이드 필기 - Docker (1) | 2023.10.03 |
| [Docker] CentOS 7 Dockerfile (0) | 2022.07.20 |