Page History
POD 는 네트워크와 하드웨어 인프라측면에서 컨테이너들이 밀접한 관계를 유지할 수 있는 추상적 존재이다.
애플리케이션과 밀접하게 존재할 수 있기 때문에 네트워크 순회로부터 발생하는 높은 지연없이 데이터를 처리할 수 있다.
공용데이터는 여러 컨테이너와 공유되는 볼륨에 저장할 수 있으며,
기본적으로 컨테이너와 애플리케이션 스택 요소를 논리적으로 그룹화할 수 있게 해준다.
파드는 쿠버네티스 노드에서 실행중인 여러 파드중 하나일 수있다.
파드는 서비스 엔드포인트에 복제, 스케줄링, 균형을 유지할 수 있는 논리적 컨테이너 그룹을 제공한다.
전반적 아키텍쳐는 모듈화가 되어 있고, 기능 확장을 위해서 플러그인을 설치할 수 있는 구조로 되어 있다.
예를 들어 모니터링 정보를 저장하는 데이타베이스로는 많이 사용되는 Influx 데이타 베이스 또는 Prometheus 와 같은 데이타 베이스를 선택해서 설치할 수 있고
커스텀 인터페이스 개발을 통해서, 알맞은 저장소를 개발하여 연결이 가능하다.
쿠버네티스는 여러 컨테이너들을 하나의 원자단위 Pod라고 부르며, 개념은 고래의 무리를 의미, Docker 의 컨테이너의 고래와도 매칭된다.
Pod는 동일한 실행 환경, 즉 클러스터에서 실행되는 애플리케이션 컨테이너와 볼륨으로 구성된 추상적인 집합체 이다.
이 모든 컨테이너들은 동일한 머신으로 구성되어 있다.
Pod의 각 컨테이너는 각자의 cgroup 을 운영하지만 몇가지 리눅스 네임스페이스를 공유하며, 서로 다른 파드는 각 애플리케이션이 격리되어 있고 각기 다른 IP주소와 호스트네임을 갖는다.
동일한 노드에서 동작하는 서로 다른 pod의 컨테이너는 각기 다른 서버에 존재할 수도 있다.
Pod 목록
클러스터 내 실행중인 파드 목록을 확인 한다.
| Code Block | ||
|---|---|---|
| ||
$ kubectl get pods NAME READY STATUS RESTARTS AGE kubernetes-bootcamp-5c69669756-jbgqh 1/1 Running 0 1m |
Pod 생성 및 삭제
파드의 생성은 명령형고 선언형이 존재하며, 실행중인 파드는 파드자체로 삭제가 불가하며 디폴로이먼트세트를 이용하여 삭제가 가능하다.
| Code Block | ||
|---|---|---|
| ||
# kubectl run kuard --image=gcr.io/kuar-demo/kuard-amd64:1 # kubectl apply -f kuard-pod.yaml # kubectl delete deployments/kuard # kubectl get pods |
Pod 상세
파드 컨테이너에 대한 세부 정보 (IP 주소, 사용 된 포트 및 포드 라이프 사이클과 관련된 이벤트 목록)를 확인 한다.
| Code Block | ||
|---|---|---|
| ||
# kubectl describe pods {{pod name}}
//기본정보
Name: kuard
Namespace: default
Node: <node name>
Start Time: Mon, 16 Jul 2018 10:45:07 +0900
Labels: <none>
Annotations: kubectl.kubernetes.io/last-applied-configuration=...
Status: Running
IP: 10.36.0.0
//컨테이너 정보
Containers:
kuard:
Container ID: docker://47da8387bfb2ac1...
Image: gcr.io/kuar-demo/kuard-amd64:1
Image ID: docker-pullable://gcr.io/kuar-demo/kuard-amd64...
Port: 8080/TCP
Host Port: 0/TCP
State: Running
Started: Mon, 16 Jul 2018 10:47:52 +0900
Ready: True
Restart Count: 0
Environment: <none>
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from default-token-prsng (ro)
Conditions:
Type Status
Initialized True
Ready True
PodScheduled True
Volumes:
default-token-prsng:
Type: Secret (a volume populated by a Secret)
SecretName: default-token-prsng
Optional: false
QoS Class: BestEffort
Node-Selectors: <none>
Tolerations: node.kubernetes.io/not-ready:NoExecute for 300s
node.kubernetes.io/unreachable:NoExecute for 300s
//이벤트정보(스케줄링시기, 이미지시기, 상태검사, 실패여부, 재시작여부)
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
... |
Pod 삭제
파드 삭제시 해당 파드와 컨테이너 그리고 데이터도 같이 삭제된다.
파드 삭제는 기본적으로 약 30초의 종료 유예 시간을 갖는다. 또한 파드의 종료중에는 새로운 요청을 수행하거나 받지 않는다.
| Code Block | ||
|---|---|---|
| ||
# kubectl delete pods/{{pod name}}
# kubectl delete -f {{pod name}}.yaml |
Pod 접속
파드 접속을 실행중인 파드에 다양한 작업을 실행할 수 있다.
대부분 실행중인 웹서비스 디버깅, 로그체크, 장애내역등 확인작업에 용이하다.
포트포워딩
쿠버네티스 API 에서 자체적으로 지원하는 포트포워딩과 명령줄 도구를 사용하여 접속 할 수 있다.
포트워드딩이 실행되는 동안 http://localhost:8080 으로 포트에 접속할 수 있다.
| Code Block | ||
|---|---|---|
| ||
# kubectl port-forward {{pod name}} 8080:8080 |
로그 및 디버깅
실행중인 파드의 컨테이너 디버깅 및 로그를 확인할 수있다.
--previous 옵션을 사용하면 컨테이너의 이전 인스턴스에서 로그를 가져 온다.
는 컨테이너시작과정에서 문제가 발생하고 컨테이너가 계속 재시작하는 경우 유용하게 쓰인다.
| Code Block | ||
|---|---|---|
| ||
# kubectl logs {{pod name}}
# kubectl logs -f {{pod name}} |
컨테이너 내부 접속
| Code Block | ||
|---|---|---|
| ||
# kubectl exec {{pod name}} date
# kubectl exec -it {{pod name}} ash |
컨테이너 파일 복사
원격 컨테이너에서 로컬 머신으로 복사할 경우와 반대로 로컬 머신에서 원격 컨테이너로 복사하는 경우가 있다.
| Code Block | ||
|---|---|---|
| ||
# kubectl cp {{pod name}}:/captures/captrue1.txt ./capture1.txt
# kubectl cp $HOME/config.txt {{pod name}}:/config.txt |
Pod 상태검사 (Process Health Check)
프로세스 상태검사 process health check 설정으로 자동적 실행이 지속된다.
이 상태 검사는 단순히 주요 프로세스 실행 여부를 항상 확인 한다. 또한 실행되지 않는 경우에는 재시작 한다.
상태 검사 종류에는 활성 프로브 와 준비 프로브 두가지가 존재 한다.
활성프로브
활성프로브는 프로세스 시작 및 실행과 정상적인 동작을 확인해 파드의 재시작 여부를 확인한다.
활성프로브는 컨테이너별로 정의되며, 파드의 각 컨테이너는 개별적으로 상태 검사를 실행 한다.
| Code Block | ||
|---|---|---|
| ||
...
spec:
containers:
- image : {{docker registry}}
name: {{name}}
livenessProbe:
httpGet:
path: /healthy
port: 8080
initialDelaySeconds: 5 //모든 컨테이너가 생성되고 5초후에 호출
timeoutSeconds: 1 //1초이내 반듣시 응답
periodSeconds: 10 //쿠버네티스는 프로브를 10초마다 호출
failureThreshold: 3 //프로브가 3번이상 실패하면 컨테이너중지후 재시작
ports:
- containerPort: 8080
name: http
protocol: TCP |
준비프로브
활성프로브는 애플리케이션 정상동작 여부를 검사하며, 활성 검사를 통과하지 못하면 컨테이너는 재시작하게 된다.
준비는 사용자 요청의 처리 준비 여부를 검사한다. 준비프로브를 통과하지 못하면 컨테이너는 서비스 로드밸런서에서 제외된다.
Pod 자원관리
파드는 필요한 최소 자원을 설정하며 이 외에 자원 제한을 통해 파드의 사용가능한 자원을 설정한다.
자원 요청은 애플리케이션을 실행하는데 필요한 최소자원을 지정하며, 자원 제한은 애플리케이션이 사용할수 있는 최대 자원을 지정한다.
다음은 최소필요자원을 0.5 CPU와 128메모리로, 최대 1.0CPU 와 256 메모리로 제한한 매니페스트 설정이다.
| Code Block | ||
|---|---|---|
| ||
...
spec:
containers:
- image: {{docker registry}}
name: {{name}}
resources:
requests:
cpu: "500m"
memory: "128Mi"
limits:
cpu: "1000m"
memory: "256Mi"
...
|
Pod 볼륨
파드가 삭제되거나 재시작될때 컨테이너의 모든 데이터는 소멸된다.
대부분의 애플리케이션에서 영구 레파지토리로 접근하는 요소는 필요한 부분이며, 쿠버네티스는 이런 영구적인 레파지토리를 지원한다.
spec.volumes
파드의 매니페스트에 설정되어 있는 모든 컨테이너가 접근 할 수 있도록 볼륨 설정이 가능하다.
모든 컨테이너가 파드에 정의 되어 있는 볼륨 전체를 마운트 할 필요는 없다.
컨테이너 정의부분 내 volumeMounts
volumeMounts는 특정 컨테이너에 마운트 되는 볼륨과 각 볼륨이 마운트 되는 경로 정의한다.
| Code Block | ||
|---|---|---|
| ||
...
spec:
volumes:
- name: "{{app name}}"
hostPath:
path: "{{path}}"
containers:
- image: gcr.io/kusr-demo/kuard-amd64:1
name: {{name}}
volumeMounts:
- mountPath: "{{path}}"
name: "{{app name}}"
... |
원격디스크를 사용한 영구 데이터
파드의 로드밸런싱 재시작과 관련없이 특정 파드에 종속적인 데이터가 필요한 경우에 쓰인다.
원격 네트워크 스토리지 볼륨을 파드에 마운트하면 가능하다.
네트워크 기반 스토리지를 사용할때 쿠버네티스는 해당 볼륨을 사용하는 pod가 특정 머신으로 스케줄링될때마다 자동으로 적절한 스토리지를 마운트하거나 해제한다.
다음은 기본적인 NFS 서버를 사용하는 방법이다.
| Code Block | ||
|---|---|---|
| ||
...
volumes:
- name: "{{app name}}"
nfs:
server: my.nfs.server.local
path: "/exports"
... |
Pod 매니패스트 (yaml)
| Code Block | ||
|---|---|---|
| ||
apiVersion: v1
kind: Pod
metadate:
name: {{app name}}
spec:
volumes:
- name: "kuard-data"
nfs:
server: my.nfs.server.local
path: "/exports"
containers:
- image: gcr.io/kuar-demo/kuard-amd64:1
name: {{app name}}
ports:
- containerPort: 8080
name: http
protocol: TCP
resources:
requests:
cpu: "500m"
memory: "128Mi"
limits:
cpu: "1000m"
memory: "256Mi"
volumeMounts:
- mountPath: "/data"
name: "kuard-data"
livenessProbe:
httpGet:
path: /healthy
port: 8080
initialDelaySeconds: 5
timeoutSeconds: 1
periodSeconds:10
failureThreshold: 3
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 30
timeoutSeconds: 1
periodSeconds:10
failureThreshold: 3 |