1 - 컨테이너 및 파드 메모리 리소스 할당
이 페이지는 메모리 요청량 과 메모리 상한 을 컨테이너에 어떻게 지정하는지 보여준다. 컨테이너는 요청량 만큼의 메모리 확보가 보장되나 상한보다 더 많은 메모리는 사용할 수 없다.
시작하기 전에
쿠버네티스 클러스터가 필요하고, kubectl 커맨드-라인 툴이 클러스터와 통신할 수 있도록 설정되어 있어야 한다. 이 튜토리얼은 컨트롤 플레인 호스트가 아닌 노드가 적어도 2개 포함된 클러스터에서 실행하는 것을 추천한다. 만약, 아직 클러스터를 가지고 있지 않다면, minikube를 사용해서 생성하거나 다음의 쿠버네티스 플레이그라운드 중 하나를 사용할 수 있다.
버전 확인을 위해서, 다음 커맨드를 실행kubectl version
.클러스터의 각 노드에 최소 300 MiB 메모리가 있어야 한다.
이 페이지의 몇 가지 단계를 수행하기 위해서는 클러스터 내 metrics-server 서비스 실행이 필요하다. 이미 실행 중인 metrics-server가 있다면 다음 단계를 건너뛸 수 있다.
Minikube를 사용 중이라면, 다음 명령어를 실행해 metric-server를 활성화할 수 있다.
minikube addons enable metrics-server
metric-server가 실행 중인지 확인하거나 다른 제공자의 리소스 메트릭 API (metrics.k8s.io
)를 확인하기 위해
다음의 명령어를 실행한다.
kubectl get apiservices
리소스 메트릭 API를 사용할 수 있다면 출력에
metrics.k8s.io
에 대한 참조가 포함되어 있다.
NAME
v1beta1.metrics.k8s.io
네임스페이스 생성
이 예제에서 생성할 자원과 클러스터 내 나머지를 분리하기 위해 네임스페이스를 생성한다.
kubectl create namespace mem-example
메모리 요청량 및 상한을 지정
컨테이너에 메모리 요청량을 지정하기 위해서는 컨테이너의 리소스 매니페스트에
resources:requests
필드를 포함한다. 리소스 상한을 지정하기 위해서는
resources:limits
필드를 포함한다.
이 예제에서 하나의 컨테이너를 가진 파드를 생성한다. 생성된 컨테이너는 100 MiB 메모리 요청량과 200 MiB 메모리 상한을 갖는다. 이 것이 파드 구성 파일이다.
apiVersion: v1
kind: Pod
metadata:
name: memory-demo
namespace: mem-example
spec:
containers:
- name: memory-demo-ctr
image: polinux/stress
resources:
limits:
memory: "200Mi"
requests:
memory: "100Mi"
command: ["stress"]
args: ["--vm", "1", "--vm-bytes", "150M", "--vm-hang", "1"]
구성 파일 내 args
섹션은 컨테이너가 시작될 때 아규먼트를 제공한다.
"--vm-bytes", "150M"
아규먼트는 컨테이너가 150 MiB 할당을 시도 하도록 한다.
파드 생성:
kubectl apply -f https://k8s.io/examples/pods/resource/memory-request-limit.yaml --namespace=mem-example
파드 컨테이너가 실행 중인지 확인:
kubectl get pod memory-demo --namespace=mem-example
파드에 대한 자세한 정보 보기:
kubectl get pod memory-demo --output=yaml --namespace=mem-example
출력은 파드 내 하나의 컨테이너에 100MiB 메모리 요청량과 200 MiB 메모리 상한이 있는 것을 보여준다.
...
resources:
limits:
memory: 200Mi
requests:
memory: 100Mi
...
kubectl top
을 실행하여 파드 메트릭 가져오기:
kubectl top pod memory-demo --namespace=mem-example
출력은 파드가 약 150 MiB 해당하는 약 162,900,000 바이트 메모리를 사용하는 것을 보여준다. 이는 파드의 100 MiB 요청 보다 많으나 파드의 200 MiB 상한보다는 적다.
NAME CPU(cores) MEMORY(bytes)
memory-demo <something> 162856960
파드 삭제:
kubectl delete pod memory-demo --namespace=mem-example
컨테이너의 메모리 상한을 초과
노드 내 메모리가 충분하다면 컨테이너는 지정한 요청량보다 많은 메모리를 사용 할 수 있다. 그러나 컨테이너는 지정한 메모리 상한보다 많은 메모리를 사용할 수 없다. 만약 컨테이너가 지정한 메모리 상한보다 많은 메모리를 할당하면 해당 컨테이너는 종료 대상 후보가 된다. 만약 컨테이너가 지속적으로 지정된 상한보다 많은 메모리를 사용한다면, 해당 컨테이너는 종료된다. 만약 종료된 컨테이너가 재실행 가능하다면 다른 런타임 실패와 마찬가지로 kubelet에 의해 재실행된다.
이 예제에서는 상한보다 많은 메모리를 할당하려는 파드를 생성한다. 이 것은 50 MiB 메모리 요청량과 100 MiB 메모리 상한을 갖는 하나의 컨테이너를 갖는 파드의 구성 파일이다.
apiVersion: v1
kind: Pod
metadata:
name: memory-demo-2
namespace: mem-example
spec:
containers:
- name: memory-demo-2-ctr
image: polinux/stress
resources:
requests:
memory: "50Mi"
limits:
memory: "100Mi"
command: ["stress"]
args: ["--vm", "1", "--vm-bytes", "250M", "--vm-hang", "1"]
구성 파일의 args
섹션에서 컨테이너가
100 MiB 상한을 훨씬 초과하는 250 MiB의 메모리를 할당하려는 것을 볼 수 있다.
파드 생성:
kubectl apply -f https://k8s.io/examples/pods/resource/memory-request-limit-2.yaml --namespace=mem-example
파드에 대한 자세한 정보 보기:
kubectl get pod memory-demo-2 --namespace=mem-example
이 시점에 컨테이너가 실행되거나 종료되었을 수 있다. 컨테이너가 종료될 때까지 이전의 명령을 반복한다.
NAME READY STATUS RESTARTS AGE
memory-demo-2 0/1 OOMKilled 1 24s
컨테이너 상태의 상세 상태 보기:
kubectl get pod memory-demo-2 --output=yaml --namespace=mem-example
컨테이너가 메모리 부족 (OOM) 으로 종료되었음이 출력된다.
lastState:
terminated:
containerID: docker://65183c1877aaec2e8427bc95609cc52677a454b56fcb24340dbd22917c23b10f
exitCode: 137
finishedAt: 2017-06-20T20:52:19Z
reason: OOMKilled
startedAt: null
이 예제에서 컨테이너는 재실행 가능하여 kubelet에 의해 재실행된다. 컨테이너가 종료되었다 재실행되는 것을 보기 위해 다음 명령을 몇 번 반복한다.
kubectl get pod memory-demo-2 --namespace=mem-example
출력은 컨테이너의 종료, 재실행, 재종료, 재실행 등을 보여준다.
kubectl get pod memory-demo-2 --namespace=mem-example
NAME READY STATUS RESTARTS AGE
memory-demo-2 0/1 OOMKilled 1 37s
kubectl get pod memory-demo-2 --namespace=mem-example
NAME READY STATUS RESTARTS AGE
memory-demo-2 1/1 Running 2 40s
파드 내역에 대한 상세 정보 보기:
kubectl describe pod memory-demo-2 --namespace=mem-example
컨테이너가 반복적으로 시작하고 실패 하는 출력을 보여준다.
... Normal Created Created container with id 66a3a20aa7980e61be4922780bf9d24d1a1d8b7395c09861225b0eba1b1f8511
... Warning BackOff Back-off restarting failed container
클러스터 노드에 대한 자세한 정보 보기:
kubectl describe nodes
출력에는 컨테이너가 메모리 부족으로 종료된 기록이 포함된다.
Warning OOMKilling Memory cgroup out of memory: Kill process 4481 (stress) score 1994 or sacrifice child
파드 삭제:
kubectl delete pod memory-demo-2 --namespace=mem-example
노드에 비해 너무 큰 메모리 요청량의 지정
메모리 요청량과 상한은 컨테이너와 관련있지만, 파드가 가지는 메모리 요청량과 상한으로 이해하면 유용하다. 파드의 메모리 요청량은 파드 내 모든 컨테이너의 메모리 요청량의 합이다. 마찬가지로 파드의 메모리 상한은 파드 내 모든 컨테이너의 메모리 상한의 합이다.
파드는 요청량을 기반하여 스케줄링된다. 노드에 파드의 메모리 요청량을 충족하기에 충분한 메모리가 있는 경우에만 파드가 노드에서 스케줄링된다.
이 예제에서는 메모리 요청량이 너무 커 클러스터 내 모든 노드의 용량을 초과하는 파드를 생성한다. 다음은 클러스터 내 모든 노드의 용량을 초과할 수 있는 1000 GiB 메모리 요청을 포함하는 컨테이너를 갖는 파드의 구성 파일이다.
apiVersion: v1
kind: Pod
metadata:
name: memory-demo-3
namespace: mem-example
spec:
containers:
- name: memory-demo-3-ctr
image: polinux/stress
resources:
limits:
memory: "1000Gi"
requests:
memory: "1000Gi"
command: ["stress"]
args: ["--vm", "1", "--vm-bytes", "150M", "--vm-hang", "1"]
파드 생성:
kubectl apply -f https://k8s.io/examples/pods/resource/memory-request-limit-3.yaml --namespace=mem-example
파드 상태 보기:
kubectl get pod memory-demo-3 --namespace=mem-example
파드 상태가 PENDING 상태임이 출력된다. 즉 파드는 어떤 노드에서도 실행되도록 스케줄 되지 않고 PENDING가 계속 지속된다.
kubectl get pod memory-demo-3 --namespace=mem-example
NAME READY STATUS RESTARTS AGE
memory-demo-3 0/1 Pending 0 25s
이벤트를 포함한 파드 상세 정보 보기:
kubectl describe pod memory-demo-3 --namespace=mem-example
출력은 노드 내 메모리가 부족하여 파드가 스케줄링될 수 없음을 보여준다.
Events:
... Reason Message
------ -------
... FailedScheduling No nodes are available that match all of the following predicates:: Insufficient memory (3).
메모리 단위
메모리 리소스는 byte 단위로 측정된다. 다음 접미사 중 하나로 정수 또는 고정 소수점으로 메모리를 표시할 수 있다. E, P, T, G, M, K, Ei, Pi, Ti, Gi, Mi, Ki. 예를 들어 다음은 거의 유사한 값을 나타낸다.
128974848, 129e6, 129M , 123Mi
파드 삭제:
kubectl delete pod memory-demo-3 --namespace=mem-example
메모리 상한을 지정하지 않으면
컨테이너에 메모리 상한을 지정하지 않으면 다음 중 하나가 적용된다.
컨테이너가 사용할 수 있는 메모리 상한은 없다. 컨테이너가 실행 중인 노드에서 사용 가능한 모든 메모리를 사용하여 OOM Killer가 실행될 수 있다. 또한 메모리 부족으로 인한 종료 시 메모리 상한이 없는 컨테이너가 종료될 가능성이 크다.
기본 메모리 상한을 갖는 네임스페이스 내에서 실행중인 컨테이너는 자동으로 기본 메모리 상한이 할당된다. 클러스터 관리자들은 LimitRange를 사용해 메모리 상한의 기본 값을 지정 가능하다.
메모리 요청량과 상한 동기부여
클러스터에서 실행되는 컨테이너에 메모리 요청량과 상한을 구성하여 클러스터 내 노드들의 메모리 리소스를 효율적으로 사용할 수 있게 할 수 있다. 파드의 메모리 요청량을 적게 유지하여 파드가 높은 확률로 스케줄링 될 수 있도록 한다. 메모리 상한이 메모리 요청량보다 크면 다음 두 가지가 수행된다.
- 가용한 메모리가 있는 경우 파드가 이를 사용할 수 있는 버스트(burst) 활동을 할 수 있다.
- 파드가 버스트 중 사용 가능한 메모리 양이 적절히 제한된다.
정리
네임스페이스를 지운다. 이 작업을 통해 네임스페이스 내 생성했던 모든 파드들은 삭제된다.
kubectl delete namespace mem-example
다음 내용
앱 개발자들을 위한
클러스터 관리자들을 위한
2 - 윈도우 파드 및 컨테이너에서 RunAsUserName 구성
Kubernetes v1.18 [stable]
이 페이지에서는 윈도우 노드에서 실행될 파드 및 컨테이너에 runAsUserName
설정을 사용하는 방법을 소개한다. 이는 리눅스 관련 runAsUser
설정과 거의 동일하여, 컨테이너의 기본값과 다른 username으로 애플리케이션을 실행할 수 있다.
시작하기 전에
쿠버네티스 클러스터가 있어야 하며 클러스터와 통신하도록 kubectl 명령줄 도구를 구성해야 한다. 클러스터에는 윈도우 워커 노드가 있어야 하고, 해당 노드에서 윈도우 워크로드를 실행하는 컨테이너의 파드가 스케쥴 된다.
파드의 username 설정
파드의 컨테이너 프로세스를 실행할 username을 지정하려면 파드 명세에 securityContext
필드 (PodSecurityContext) 를 포함시키고, 그 안에 runAsUserName
필드를 포함하는 windowsOptions
(WindowsSecurityContextOptions) 필드를 추가한다.
파드에 지정하는 윈도우 보안 컨텍스트 옵션은 파드의 모든 컨테이너 및 초기화 컨테이너에 적용된다.
다음은 runAsUserName
필드가 설정된 윈도우 파드의 구성 파일이다.
apiVersion: v1
kind: Pod
metadata:
name: run-as-username-pod-demo
spec:
securityContext:
windowsOptions:
runAsUserName: "ContainerUser"
containers:
- name: run-as-username-demo
image: mcr.microsoft.com/windows/servercore:ltsc2019
command: ["ping", "-t", "localhost"]
nodeSelector:
kubernetes.io/os: windows
파드를 생성한다.
kubectl apply -f https://k8s.io/examples/windows/run-as-username-pod.yaml
파드의 컨테이너가 실행 중인지 확인한다.
kubectl get pod run-as-username-pod-demo
실행 중인 컨테이너의 셸에 접근한다.
kubectl exec -it run-as-username-pod-demo -- powershell
셸이 올바른 username인 사용자로 실행 중인지 확인한다.
echo $env:USERNAME
결과는 다음과 같다.
ContainerUser
컨테이너의 username 설정
컨테이너의 프로세스를 실행할 username을 지정하려면, 컨테이너 매니페스트에 securityContext
필드 (SecurityContext) 를 포함시키고 그 안에 runAsUserName
필드를 포함하는 windowsOptions
(WindowsSecurityContextOptions) 필드를 추가한다.
컨테이너에 지정하는 윈도우 보안 컨텍스트 옵션은 해당 개별 컨테이너에만 적용되며 파드 수준에서 지정한 설정을 재정의한다.
다음은 한 개의 컨테이너에 runAsUserName
필드가 파드 수준 및 컨테이너 수준에서 설정되는 파드의 구성 파일이다.
apiVersion: v1
kind: Pod
metadata:
name: run-as-username-container-demo
spec:
securityContext:
windowsOptions:
runAsUserName: "ContainerUser"
containers:
- name: run-as-username-demo
image: mcr.microsoft.com/windows/servercore:ltsc2019
command: ["ping", "-t", "localhost"]
securityContext:
windowsOptions:
runAsUserName: "ContainerAdministrator"
nodeSelector:
kubernetes.io/os: windows
파드를 생성한다.
kubectl apply -f https://k8s.io/examples/windows/run-as-username-container.yaml
파드의 컨테이너가 실행 중인지 확인한다.
kubectl get pod run-as-username-container-demo
실행 중인 컨테이너의 셸에 접근한다.
kubectl exec -it run-as-username-container-demo -- powershell
셸이 사용자에게 올바른 username(컨테이너 수준에서 설정된 사용자)을 실행 중인지 확인한다.
echo $env:USERNAME
결과는 다음과 같다.
ContainerAdministrator
윈도우 username 제약사항
이 기능을 사용하려면 runAsUserName
필드에 설정된 값이 유효한 username이어야 한다. 형식은 DOMAIN\USER
여야하고, 여기서 DOMAIN\
은 선택 사항이다. 윈도우 username은 대소문자를 구분하지 않는다. 또한 DOMAIN
및 USER
와 관련된 몇 가지 제약사항이 있다.
runAsUserName
필드는 비워 둘 수 없으며 제어 문자를 포함할 수 없다. (ASCII 값:0x00-0x1F
,0x7F
)DOMAIN
은 NetBios 이름 또는 DNS 이름이어야 하며 각각 고유한 제한이 있다.- NetBios 이름: 최대 15 자,
.
(마침표)으로 시작할 수 없으며 다음 문자를 포함할 수 없다.\ / : * ? " < > |
- DNS 이름: 최대 255 자로 영숫자, 마침표(
.
), 대시(-
)로만 구성되며, 마침표 또는 대시로 시작하거나 끝날 수 없다.
- NetBios 이름: 최대 15 자,
USER
는 최대 20자이며, 오직 마침표나 공백들로는 구성할 수 없고, 다음 문자는 포함할 수 없다." / \ [ ] : ; | = , + * ? < > @
.
runAsUserName
필드에 허용되는 값의 예 : ContainerAdministrator
,ContainerUser
, NT AUTHORITY\NETWORK SERVICE
, NT AUTHORITY\LOCAL SERVICE
.
이러한 제약사항에 대한 자세한 내용은 여기 와 여기를 확인한다.
다음 내용
3 - 파드에 대한 서비스 품질(QoS) 구성
이 페이지는 특정 서비스 품질(QoS) 클래스를 할당하기 위해 어떻게 파드를 구성해야 하는지 보여준다. 쿠버네티스는 QoS 클래스를 사용하여 파드 스케줄링과 축출을 결정한다.
시작하기 전에
쿠버네티스 클러스터가 필요하고, kubectl 커맨드-라인 툴이 클러스터와 통신할 수 있도록 설정되어 있어야 한다. 이 튜토리얼은 컨트롤 플레인 호스트가 아닌 노드가 적어도 2개 포함된 클러스터에서 실행하는 것을 추천한다. 만약, 아직 클러스터를 가지고 있지 않다면, minikube를 사용해서 생성하거나 다음의 쿠버네티스 플레이그라운드 중 하나를 사용할 수 있다.
버전 확인을 위해서, 다음 커맨드를 실행kubectl version
.QoS 클래스
쿠버네티스가 파드를 생성할 때, 파드에 다음의 QoS 클래스 중 하나를 할당한다.
- Guaranteed
- Burstable
- BestEffort
네임스페이스 생성
이 연습에서 생성한 리소스가 클러스터의 나머지와 격리되도록 네임스페이스를 생성한다.
kubectl create namespace qos-example
Guaranteed QoS 클래스가 할당되는 파드 생성
파드에 Guaranteed QoS 클래스 할당을 위한 전제 조건은 다음과 같다.
- 파드 내 모든 컨테이너는 메모리 상한과 메모리 요청량을 가지고 있어야 한다.
- 파드 내 모든 컨테이너의 메모리 상한이 메모리 요청량과 일치해야 한다.
- 파드 내 모든 컨테이너는 CPU 상한과 CPU 요청량을 가지고 있어야 한다.
- 파드 내 모든 컨테이너의 CPU 상한이 CPU 요청량과 일치해야 한다.
이러한 제약은 초기화 컨테이너와 앱 컨테이너 모두에 동일하게 적용된다.
다음은 하나의 컨테이너를 갖는 파드의 구성 파일이다. 해당 컨테이너는 메모리 상한과 메모리 요청량을 갖고 있고, 200MiB로 동일하다. 해당 컨테이너는 CPU 상한과 CPU 요청량을 가지며, 700 milliCPU로 동일하다.
apiVersion: v1
kind: Pod
metadata:
name: qos-demo
namespace: qos-example
spec:
containers:
- name: qos-demo-ctr
image: nginx
resources:
limits:
memory: "200Mi"
cpu: "700m"
requests:
memory: "200Mi"
cpu: "700m"
파드를 생성한다.
kubectl apply -f https://k8s.io/examples/pods/qos/qos-pod.yaml --namespace=qos-example
파드의 상세 정보를 본다.
kubectl get pod qos-demo --namespace=qos-example --output=yaml
출력 결과는 쿠버네티스가 파드에 Guaranteed QoS 클래스를 부여했음을 보여준다. 또한 파드의 컨테이너가 메모리 요청량과 일치하는 메모리 상한을 가지며, CPU 요청량과 일치하는 CPU 상한을 갖고 있음을 확인할 수 있다.
spec:
containers:
...
resources:
limits:
cpu: 700m
memory: 200Mi
requests:
cpu: 700m
memory: 200Mi
...
status:
qosClass: Guaranteed
참고: 컨테이너가 자신의 메모리 상한을 지정하지만, 메모리 요청량을 지정하지 않는 경우, 쿠버네티스는 상한과 일치하는 메모리 요청량을 자동으로 할당한다. 이와 유사하게, 만약 컨테이너가 자신의 CPU 상한을 지정하지만, CPU 요청량을 지정하지 않은 경우, 쿠버네티스는 상한과 일치하는 CPU 요청량을 자동으로 할당한다.
파드를 삭제한다.
kubectl delete pod qos-demo --namespace=qos-example
Burstable QoS 클래스가 할당되는 파드 생성
다음의 경우 파드에 Burstable QoS 클래스가 부여된다.
- 파드가 Guaranteed QoS 클래스 기준을 만족하지 않는다.
- 파드 내에서 최소한 하나의 컨테이너가 메모리 또는 CPU 요청량을 가진다.
컨테이너가 하나인 파드의 구성 파일은 다음과 같다. 컨테이너는 200MiB의 메모리 상한과 100MiB의 메모리 요청량을 가진다.
apiVersion: v1
kind: Pod
metadata:
name: qos-demo-2
namespace: qos-example
spec:
containers:
- name: qos-demo-2-ctr
image: nginx
resources:
limits:
memory: "200Mi"
requests:
memory: "100Mi"
파드를 생성한다.
kubectl apply -f https://k8s.io/examples/pods/qos/qos-pod-2.yaml --namespace=qos-example
파드의 상세 정보를 본다.
kubectl get pod qos-demo-2 --namespace=qos-example --output=yaml
출력 결과는 쿠버네티스가 파드에 Burstable QoS 클래스를 부여했음을 보여준다.
spec:
containers:
- image: nginx
imagePullPolicy: Always
name: qos-demo-2-ctr
resources:
limits:
memory: 200Mi
requests:
memory: 100Mi
...
status:
qosClass: Burstable
파드를 삭제한다.
kubectl delete pod qos-demo-2 --namespace=qos-example
BestEffort QoS 클래스가 할당되는 파드 생성
파드에 QoS 클래스 BestEffort를 제공하려면, 파드의 컨테이너에 메모리 또는 CPU의 상한이나 요청량이 없어야 한다.
컨테이너가 하나인 파드의 구성 파일이다. 해당 컨테이너는 메모리 또는 CPU의 상한이나 요청량을 갖지 않는다.
apiVersion: v1
kind: Pod
metadata:
name: qos-demo-3
namespace: qos-example
spec:
containers:
- name: qos-demo-3-ctr
image: nginx
파드를 생성한다.
kubectl apply -f https://k8s.io/examples/pods/qos/qos-pod-3.yaml --namespace=qos-example
파드의 상세 정보를 본다.
kubectl get pod qos-demo-3 --namespace=qos-example --output=yaml
출력 결과는 쿠버네티스가 파드에 BestEffort QoS 클래스를 부여했음을 보여준다.
spec:
containers:
...
resources: {}
...
status:
qosClass: BestEffort
파드를 삭제한다.
kubectl delete pod qos-demo-3 --namespace=qos-example
컨테이너가 두 개인 파드 생성
컨테이너가 두 개인 파드의 구성 파일이다. 한 컨테이너는 200MiB의 메모리 요청량을 지정한다. 다른 컨테이너는 어떤 요청량이나 상한을 지정하지 않는다.
apiVersion: v1
kind: Pod
metadata:
name: qos-demo-4
namespace: qos-example
spec:
containers:
- name: qos-demo-4-ctr-1
image: nginx
resources:
requests:
memory: "200Mi"
- name: qos-demo-4-ctr-2
image: redis
참고로 이 파드는 Burstable QoS 클래스의 기준을 충족한다. 즉, Guaranteed QoS 클래스에 대한 기준을 충족하지 않으며, 해당 컨테이너 중 하나가 메모리 요청량을 갖는다.
파드를 생성한다.
kubectl apply -f https://k8s.io/examples/pods/qos/qos-pod-4.yaml --namespace=qos-example
파드의 상세 정보를 본다.
kubectl get pod qos-demo-4 --namespace=qos-example --output=yaml
출력 결과는 쿠버네티스가 파드에 Burstable QoS 클래스를 부여했음을 보여준다.
spec:
containers:
...
name: qos-demo-4-ctr-1
resources:
requests:
memory: 200Mi
...
name: qos-demo-4-ctr-2
resources: {}
...
status:
qosClass: Burstable
파드를 삭제한다.
kubectl delete pod qos-demo-4 --namespace=qos-example
정리
네임스페이스를 삭제한다.
kubectl delete namespace qos-example
다음 내용
앱 개발자를 위한 문서
클러스터 관리자를 위한 문서
4 - 스토리지의 볼륨을 사용하는 파드 구성
이 페이지는 스토리지의 볼륨을 사용하는 파드를 구성하는 방법을 설명한다.
컨테이너 파일 시스템은 컨테이너가 살아있는 동안만 존재한다. 따라서 컨테이너가 종료되고 재시작할 때, 파일 시스템 변경사항이 손실된다. 컨테이너와 독립적이며 보다 일관된 스토리지를 위해 사용자는 볼륨을 사용할 수 있다. 이것은 레디스(Redis)와 같은 키-값 저장소나 데이터베이스와 같은 스테이트풀 애플리케이션에 매우 중요하다.
시작하기 전에
쿠버네티스 클러스터가 필요하고, kubectl 커맨드-라인 툴이 클러스터와 통신할 수 있도록 설정되어 있어야 한다. 이 튜토리얼은 컨트롤 플레인 호스트가 아닌 노드가 적어도 2개 포함된 클러스터에서 실행하는 것을 추천한다. 만약, 아직 클러스터를 가지고 있지 않다면, minikube를 사용해서 생성하거나 다음의 쿠버네티스 플레이그라운드 중 하나를 사용할 수 있다.
버전 확인을 위해서, 다음 커맨드를 실행kubectl version
.파드에 볼륨 구성
이 연습에서는 하나의 컨테이너를 실행하는 파드를 생성한다. 이 파드는 컨테이너가 종료되고, 재시작 하더라도 파드의 수명동안 지속되는 emptyDir 유형의 볼륨이 있다. 파드의 구성 파일은 다음과 같다.
apiVersion: v1
kind: Pod
metadata:
name: redis
spec:
containers:
- name: redis
image: redis
volumeMounts:
- name: redis-storage
mountPath: /data/redis
volumes:
- name: redis-storage
emptyDir: {}
파드 생성
kubectl apply -f https://k8s.io/examples/pods/storage/redis.yaml
파드의 컨테이너가 Running 중인지 확인하고, 파드의 변경사항을 지켜본다.
kubectl get pod redis --watch
출력은 이와 유사하다.
NAME READY STATUS RESTARTS AGE redis 1/1 Running 0 13s
다른 터미널에서 실행 중인 컨테이너의 셸을 획득한다.
kubectl exec -it redis -- /bin/bash
셸에서
/data/redis
로 이동하고, 파일을 생성한다.root@redis:/data# cd /data/redis/ root@redis:/data/redis# echo Hello > test-file
셸에서 실행 중인 프로세스 목록을 확인한다.
root@redis:/data/redis# apt-get update root@redis:/data/redis# apt-get install procps root@redis:/data/redis# ps aux
출력은 이와 유사하다.
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND redis 1 0.1 0.1 33308 3828 ? Ssl 00:46 0:00 redis-server *:6379 root 12 0.0 0.0 20228 3020 ? Ss 00:47 0:00 /bin/bash root 15 0.0 0.0 17500 2072 ? R+ 00:48 0:00 ps aux
셸에서 Redis 프로세스를 강제종료(kill)한다.
root@redis:/data/redis# kill <pid>
여기서
<pid>
는 Redis 프로세스 ID(PID) 이다.원래 터미널에서, Redis 파드의 변경을 지켜본다. 결국, 다음과 유사한 것을 보게 될 것이다.
NAME READY STATUS RESTARTS AGE redis 1/1 Running 0 13s redis 0/1 Completed 0 6m redis 1/1 Running 1 6m
이때, 컨테이너는 종료되고 재시작된다. 이는
Redis 파드의
restartPolicy는
Always
이기 때문이다.
재시작된 컨테이너의 셸을 획득한다.
kubectl exec -it redis -- /bin/bash
셸에서
/data/redis
로 이동하고,test-file
이 여전히 존재하는지 확인한다.root@redis:/data/redis# cd /data/redis/ root@redis:/data/redis# ls test-file
이 연습을 위해 생성한 파드를 삭제한다.
kubectl delete pod redis
다음 내용
5 - 스토리지로 퍼시스턴트볼륨(PersistentVolume)을 사용하도록 파드 설정하기
이 페이지는 스토리지에 대해 퍼시스턴트볼륨클레임(PersistentVolumeClaim)을 사용하도록 파드를 설정하는 방법을 보여준다. 과정의 요약은 다음과 같다.
클러스터 관리자로서, 물리적 스토리지와 연결되는 퍼시스턴트볼륨을 생성한다. 볼륨을 특정 파드와 연결하지 않는다.
그 다음 개발자 / 클러스터 사용자의 역할로서, 적합한 퍼시스턴트볼륨에 자동으로 바인딩되는 퍼시스턴트볼륨클레임을 생성한다.
스토리지에 대해 위의 퍼시스턴트볼륨클레임을 사용하는 파드를 생성한다.
시작하기 전에
사용자는 노드가 단 하나만 있는 쿠버네티스 클러스터가 필요하고, kubectl 커맨드라인 툴이 사용자의 클러스터와 통신할 수 있도록 설정되어 있어야 한다. 만약 사용자가 아직 단일 노드 클러스터를 가지고 있지 않다면, Minikube를 사용하여 클러스터 하나를 생성할 수 있다.
퍼시스턴트 볼륨의 관련 자료에 익숙해지도록 한다.
사용자 노드에 index.html 파일 생성하기
사용자 클러스터의 단일 노드에 연결되는 셸을 연다. 셸을 여는 방법은
클러스터 설정에 따라 달라진다. 예를 들어 Minikube를 사용하는 경우,
minikube ssh
명령어를 입력하여 노드로 연결되는 셸을 열 수 있다.
해당 노드의 셸에서 /mnt/data
디렉터리를 생성한다.
# 사용자 노드에서 슈퍼유저로 명령을 수행하기 위하여
# "sudo"를 사용한다고 가정한다
sudo mkdir /mnt/data
/mnt/data
디렉터리에서 index.html
파일을 생성한다.
# 이번에도 사용자 노드에서 슈퍼유저로 명령을 수행하기 위하여
# "sudo"를 사용한다고 가정한다
sudo sh -c "echo 'Hello from Kubernetes storage' > /mnt/data/index.html"
참고: 사용자 노드에서sudo
이외의 슈퍼유저 접근 툴을 사용하는 경우,sudo
를 해당 툴의 이름으로 바꾸면, 동일하게 작업을 수행할 수 있다.
index.html
파일이 존재하는지 테스트한다.
cat /mnt/data/index.html
결과는 다음과 같다.
Hello from Kubernetes storage
이제 사용자 노드에서 셸을 종료해도 된다.
퍼시스턴트볼륨 생성하기
이 예제에서, 사용자는 hostPath 퍼시스턴트볼륨을 생성한다. 쿠버네티스는 단일 노드에서의 개발과 테스트를 위해 hostPath를 지원한다. hostPath 퍼시스턴트볼륨은 네트워크로 연결된 스토리지를 모방하기 위해, 노드의 파일이나 디렉터리를 사용한다.
운영 클러스터에서, 사용자가 hostPath를 사용하지는 않는다. 대신, 클러스터 관리자는 Google Compute Engine 영구 디스크, NFS 공유 또는 Amazone Elastic Block Store 볼륨과 같은 네트워크 자원을 프로비저닝한다. 클러스터 관리자는 스토리지클래스(StorageClasses)를 사용하여 동적 프로비저닝을 설정할 수도 있다.
hostPath 퍼시스턴트볼륨의 설정 파일은 아래와 같다.
apiVersion: v1
kind: PersistentVolume
metadata:
name: task-pv-volume
labels:
type: local
spec:
storageClassName: manual
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
hostPath:
path: "/mnt/data"
설정 파일에 클러스터 노드의 /mnt/data
에 볼륨이 있다고
지정한다. 또한 설정에서 볼륨 크기를 10 기가바이트로 지정하고 단일 노드가
읽기-쓰기 모드로 볼륨을 마운트할 수 있는 ReadWriteOnce
접근 모드를
지정한다. 여기서는
퍼시스턴트볼륨클레임의 스토리지클래스 이름을
manual
로 정의하며, 퍼시스턴트볼륨클레임의 요청을
이 퍼시스턴트볼륨에 바인딩하는데 사용한다.
퍼시스턴트볼륨을 생성한다.
kubectl apply -f https://k8s.io/examples/pods/storage/pv-volume.yaml
퍼시스턴트볼륨에 대한 정보를 조회한다.
kubectl get pv task-pv-volume
결과는 퍼시스턴트볼륨의 STATUS
가 Available
임을 보여준다. 이는
아직 퍼시스턴트볼륨클레임이 바인딩되지 않았다는 것을 의미한다.
NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM STORAGECLASS REASON AGE
task-pv-volume 10Gi RWO Retain Available manual 4s
퍼시스턴트볼륨클레임 생성하기
다음 단계는 퍼시스턴트볼륨클레임을 생성하는 단계이다. 파드는 퍼시스턴트볼륨클레임을 사용하여 물리적인 스토리지를 요청한다. 이 예제에서, 사용자는 적어도 하나 이상의 노드에 대해 읽기-쓰기 접근을 지원하며 최소 3 기가바이트의 볼륨을 요청하는 퍼시스턴트볼륨클레임을 생성한다.
퍼시스턴트볼륨클레임에 대한 설정 파일은 다음과 같다.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: task-pv-claim
spec:
storageClassName: manual
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 3Gi
퍼시스턴트볼륨클레임을 생성한다.
kubectl apply -f https://k8s.io/examples/pods/storage/pv-claim.yaml
사용자가 퍼시스턴트볼륨클레임을 생성한 후에, 쿠버네티스 컨트롤 플레인은 클레임의 요구사항을 만족하는 퍼시스턴트볼륨을 찾는다. 컨트롤 플레인이 동일한 스토리지클래스를 갖는 적절한 퍼시스턴트볼륨을 찾으면, 볼륨에 클레임을 바인딩한다.
퍼시스턴트볼륨을 다시 확인한다.
kubectl get pv task-pv-volume
이제 결과는 STATUS
가 Bound
임을 보여준다.
NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM STORAGECLASS REASON AGE
task-pv-volume 10Gi RWO Retain Bound default/task-pv-claim manual 2m
퍼시스턴트볼륨클레임을 확인한다.
kubectl get pvc task-pv-claim
결과는 퍼시스턴트볼륨클레임이 사용자의 퍼시스턴트볼륨인 task-pv-volume
에
바인딩되어 있음을 보여준다.
NAME STATUS VOLUME CAPACITY ACCESSMODES STORAGECLASS AGE
task-pv-claim Bound task-pv-volume 10Gi RWO manual 30s
파드 생성하기
다음 단계는 볼륨으로 퍼시스턴트볼륨클레임을 사용하는 파드를 만드는 단계이다.
파드에 대한 설정 파일은 다음과 같다.
apiVersion: v1
kind: Pod
metadata:
name: task-pv-pod
spec:
volumes:
- name: task-pv-storage
persistentVolumeClaim:
claimName: task-pv-claim
containers:
- name: task-pv-container
image: nginx
ports:
- containerPort: 80
name: "http-server"
volumeMounts:
- mountPath: "/usr/share/nginx/html"
name: task-pv-storage
파드의 설정 파일은 퍼시스턴트볼륨클레임을 지정하지만, 퍼시스턴트볼륨을 지정하지는 않는다는 것을 유념하자. 파드의 관점에서 볼때, 클레임은 볼륨이다.
파드를 생성한다.
kubectl apply -f https://k8s.io/examples/pods/storage/pv-pod.yaml
파드의 컨테이너가 실행 중임을 확인한다.
kubectl get pod task-pv-pod
사용자 파드에서 구동되고 있는 컨테이너에 셸로 접근한다.
kubectl exec -it task-pv-pod -- /bin/bash
사용자의 셸에서, nginx가 hostPath 볼륨으로부터 index.html
파일을
제공하는지 확인한다.
# 이전 단계에서 "kubectl exec" 명령을 실행한 root 셸 안에서
# 다음의 3개 명령을 실행해야 한다.
apt update
apt install curl
curl http://localhost/
결과는 hostPath 볼륨에 있는 index.html
파일에 사용자가 작성한 텍스트를
보여준다.
Hello from Kubernetes storage
만약 사용자가 위와 같은 메시지를 확인하면, 파드가 퍼시스턴트볼륨클레임의 스토리지를 사용하도록 성공적으로 설정한 것이다.
정리하기
파드, 퍼시스턴트볼륨클레임, 퍼시스턴트볼륨을 삭제한다.
kubectl delete pod task-pv-pod
kubectl delete pvc task-pv-claim
kubectl delete pv task-pv-volume
만약 클러스터의 노드에 대한 셸이 열려져 있지 않은 경우, 이전과 동일한 방식으로 새로운 셸을 연다.
사용자 노드의 셸에서, 생성한 파일과 디렉터리를 제거한다.
# 사용자 노드에서 슈퍼유저로 명령을 수행하기 위하여
# "sudo"를 사용한다고 가정한다
sudo rm /mnt/data/index.html
sudo rmdir /mnt/data
이제 사용자 노드에서 셸을 종료해도 된다.
접근 제어
그룹 ID(GID)로 설정된 스토리지는 동일한 GID를 사용하는 파드에서만 쓰기 작업을 허용한다. GID가 일치하지 않거나 누락되었을 경우 권한 거부 오류가 발생한다. 사용자와의 조정 필요성을 줄이기 위하여 관리자는 퍼시스턴트 볼륨에 GID로 어노테이션을 달 수 있다. 그 뒤에, 퍼시스턴트볼륨을 사용하는 모든 파드에 대하여 GID가 자동으로 추가된다.
다음과 같이 pv.beta.kubernetes.io/gid
어노테이션을 사용한다.
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv1
annotations:
pv.beta.kubernetes.io/gid: "1234"
파드가 GID 어노테이션이 있는 퍼시스턴트볼륨을 사용하면, 어노테이션으로 달린 GID가 파드의 보안 컨텍스트에 지정된 GID와 동일한 방식으로 파드의 모든 컨테이너에 적용된다. 파드의 명세 혹은 퍼시스턴트볼륨의 어노테이션으로부터 생성된 모든 GID는, 각 컨테이너에서 실행되는 첫 번째 프로세스에 적용된다.
참고: 파드가 퍼시스턴트볼륨을 사용할 때, 퍼시스턴트볼륨과 연관된 GID는 파드 리소스 자체에는 존재하지 않는다.
다음 내용
- 퍼시스턴트볼륨에 대해 더 보기.
- 퍼시스턴트 스토리지 디자인 문서에 대해 읽어보기.
Reference
6 - 프라이빗 레지스트리에서 이미지 받아오기
이 페이지는 프라이빗 도커 레지스트리나 리포지터리로부터 이미지를 받아오기 위해 시크릿(Secret)을 사용하는 파드를 생성하는 방법을 보여준다.
시작하기 전에
쿠버네티스 클러스터가 필요하고, kubectl 커맨드-라인 툴이 클러스터와 통신할 수 있도록 설정되어 있어야 한다. 이 튜토리얼은 컨트롤 플레인 호스트가 아닌 노드가 적어도 2개 포함된 클러스터에서 실행하는 것을 추천한다. 만약, 아직 클러스터를 가지고 있지 않다면, minikube를 사용해서 생성하거나 다음의 쿠버네티스 플레이그라운드 중 하나를 사용할 수 있다.
버전 확인을 위해서, 다음 커맨드를 실행kubectl version
.이 실습을 수행하기 위해, 도커 ID와 비밀번호가 필요하다.
도커 로그인
노트북에 프라이빗 이미지를 받아오기 위하여 레지스트리 인증을 필수로 수행해야 한다.
docker login
프롬프트가 나타나면, 도커 사용자 이름(username)과 비밀번호(password)를 입력하자.
로그인 프로세스는 권한 토큰 정보를 가지고 있는 config.json
파일을 생성하거나 업데이트 한다.
config.json
파일을 확인하자.
cat ~/.docker/config.json
하단과 유사한 결과를 확인할 수 있다.
{
"auths": {
"https://index.docker.io/v1/": {
"auth": "c3R...zE2"
}
}
}
참고: 도커 자격 증명 저장소를 사용하는 경우,auth
항목이 아닌, 저장소의 이름을 값으로 사용하는credsStore
항목을 확인할 수 있다.
기존의 도커 자격 증명을 기반으로 시크릿 생성하기
쿠버네티스 클러스터는 프라이빗 이미지를 받아올 때, 컨테이너 레지스트리에 인증하기 위하여
kubernetes.io/dockerconfigjson
타입의 시크릿을 사용한다.
만약 이미 docker login
을 수행하였다면, 이 때 생성된 자격 증명을 쿠버네티스 클러스터로 복사할 수 있다.
kubectl create secret generic regcred \
--from-file=.dockerconfigjson=<path/to/.docker/config.json> \
--type=kubernetes.io/dockerconfigjson
오브젝트에 대한 더 세밀한 제어(새로운 시크릿에 대한 네임스페이스나 레이블을 지정하는 등)가 필요할 경우, 시크릿을 사용자 정의한 후에 저장할 수도 있다. 다음을 확인하자.
- 데이터 항목의 이름을
.dockerconfigjson
으로 설정한다 - 도커 파일을 base64로 인코딩하고 그 문자열을
data[".dockerconfigjson"]
필드에 자르지 않고 한 줄로 이어서 붙여넣는다 type
을kubernetes.io/dockerconfigjson
으로 설정한다
예:
apiVersion: v1
kind: Secret
metadata:
name: myregistrykey
namespace: awesomeapps
data:
.dockerconfigjson: UmVhbGx5IHJlYWxseSByZWVlZWVlZWVlZWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGx5eXl5eXl5eXl5eXl5eXl5eXl5eSBsbGxsbGxsbGxsbGxsbG9vb29vb29vb29vb29vb29vb29vb29vb29vb25ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubmdnZ2dnZ2dnZ2dnZ2dnZ2dnZ2cgYXV0aCBrZXlzCg==
type: kubernetes.io/dockerconfigjson
만약 error: no objects passed to create
메세지가 출력될 경우, base64로 인코딩된 문자열이 유효하지 않음을 의미한다.
또한 Secret "myregistrykey" is invalid: data[.dockerconfigjson]: invalid value ...
메세지가 출력될 경우,
base64로 인코딩된 문자열이 정상적으로 디코딩되었으나, .docker/config.json
파일로 파싱되지 못한 것을 의미한다.
커맨드 라인에서 자격 증명을 통하여 시크릿 생성하기
regcred
라는 이름의 시크릿을 생성하자.
kubectl create secret docker-registry regcred --docker-server=<your-registry-server> --docker-username=<your-name> --docker-password=<your-pword> --docker-email=<your-email>
아래의 각 항목에 대한 설명을 참고한다.
<your-registry-server>
은 프라이빗 도커 저장소의 FQDN 주소이다. 도커허브(DockerHub)는https://index.docker.io/v2/
를 사용한다.<your-name>
은 도커 사용자의 계정이다.<your-pword>
은 도커 사용자의 비밀번호이다.<your-email>
은 도커 사용자의 이메일 주소이다.
이를 통해 regcred
라는 시크릿으로 클러스터 내에서 도커 자격 증명을 생성했다.
참고: 커맨드 라인에서 시크릿을 입력하는 경우, 보호되지 않는 셸 히스토리에 내용이 저장될 수 있으며, 이러한 시크릿들은kubectl
이 구동 중인 동안 사용자의 PC의 다른 사용자들에게 보일 수도 있다.
시크릿 regcred
검증하기
방금 생성한 regcred
시크릿의 내용을 확인하기 위하여, YAML 형식으로 시크릿을 확인하자.
kubectl get secret regcred --output=yaml
결과는 다음과 같다.
apiVersion: v1
kind: Secret
metadata:
...
name: regcred
...
data:
.dockerconfigjson: eyJodHRwczovL2luZGV4L ... J0QUl6RTIifX0=
type: kubernetes.io/dockerconfigjson
.dockerconfigjson
필드의 값은 도커 자격 증명의 base64 인코딩 결과이다.
.dockerconfigjson
필드의 값을 확인하기 위하여, 시크릿 데이터를 읽을 수 있는
형식으로 변경한다.
kubectl get secret regcred --output="jsonpath={.data.\.dockerconfigjson}" | base64 --decode
결과는 다음과 같다.
{"auths":{"your.private.registry.example.com":{"username":"janedoe","password":"xxxxxxxxxxx","email":"jdoe@example.com","auth":"c3R...zE2"}}}
auth
필드의 값을 확인하기 위하여, base64로 인코딩된 데이터를 읽을 수 있는 형식으로 변경한다.
echo "c3R...zE2" | base64 --decode
결과로, 사용자 이름과 비밀번호가 :
로 연결되어 아래와 같이 표현된다.
janedoe:xxxxxxxxxxx
참고로 시크릿 데이터에는 사용자의 로컬에 있는 ~/.docker/config.json
파일과 유사한 인증 토큰이 포함되어 있다.
이를 통해 regcred
라는 시크릿으로 클러스터 내에서 도커 자격 증명을 생성했다.
시크릿을 사용하는 파드 생성하기
다음은 regcred
에 있는 도커 자격 증명에 접근해야 하는 파드의 구성 파일이다.
apiVersion: v1
kind: Pod
metadata:
name: private-reg
spec:
containers:
- name: private-reg-container
image: <your-private-image>
imagePullSecrets:
- name: regcred
아래의 파일을 다운로드받는다.
wget -O my-private-reg-pod.yaml https://k8s.io/examples/pods/private-reg-pod.yaml
my-private-reg-pod.yaml
파일 안에서, <your-private-image>
값을 다음과 같은 프라이빗 저장소 안의 이미지 경로로 변경한다.
your.private.registry.example.com/janedoe/jdoe-private:v1
프라이빗 저장소에서 이미지를 받아오기 위하여, 쿠버네티스에서 자격 증명이 필요하다.
구성 파일의 imagePullSecrets
필드를 통해 쿠버네티스가
regcred
라는 시크릿으로부터 자격 증명을 가져올 수 있다.
시크릿을 사용해서 파드를 생성하고, 파드가 실행되는지 확인하자.
kubectl apply -f my-private-reg-pod.yaml
kubectl get pod private-reg
다음 내용
- 시크릿에 대해 더 배워 보기.
- 프라이빗 레지스트리 사용에 대해 더 배워 보기.
- 서비스 어카운트에 풀 시크릿(pull secret) 추가하기에 대해 더 배워 보기.
- kubectl create secret docker-registry에 대해 읽어보기.
- 시크릿에 대해 읽어보기.
- PodSpec의
imagePullSecrets
필드에 대해 읽어보기.
7 - 노드 어피니티를 사용해 노드에 파드 할당
이 문서는 쿠버네티스 클러스터의 특정 노드에 노드 어피니티를 사용해 쿠버네티스 파드를 할당하는 방법을 설명한다.
시작하기 전에
쿠버네티스 클러스터가 필요하고, kubectl 커맨드-라인 툴이 클러스터와 통신할 수 있도록 설정되어 있어야 한다. 이 튜토리얼은 컨트롤 플레인 호스트가 아닌 노드가 적어도 2개 포함된 클러스터에서 실행하는 것을 추천한다. 만약, 아직 클러스터를 가지고 있지 않다면, minikube를 사용해서 생성하거나 다음의 쿠버네티스 플레이그라운드 중 하나를 사용할 수 있다.
쿠버네티스 서버의 버전은 다음과 같거나 더 높아야 함. 버전: v1.10. 버전 확인을 위해서, 다음 커맨드를 실행kubectl version
.노드에 레이블 추가
클러스터의 노드를 레이블과 함께 나열하자.
kubectl get nodes --show-labels
결과는 아래와 같다.
NAME STATUS ROLES AGE VERSION LABELS worker0 Ready <none> 1d v1.13.0 ...,kubernetes.io/hostname=worker0 worker1 Ready <none> 1d v1.13.0 ...,kubernetes.io/hostname=worker1 worker2 Ready <none> 1d v1.13.0 ...,kubernetes.io/hostname=worker2
노드 한 개를 선택하고, 레이블을 추가하자.
kubectl label nodes <your-node-name> disktype=ssd
<your-node-name>
는 선택한 노드의 이름이다.선택한 노드가
disktype=ssd
레이블을 갖고 있는지 확인하자.kubectl get nodes --show-labels
결과는 아래와 같다.
NAME STATUS ROLES AGE VERSION LABELS worker0 Ready <none> 1d v1.13.0 ...,disktype=ssd,kubernetes.io/hostname=worker0 worker1 Ready <none> 1d v1.13.0 ...,kubernetes.io/hostname=worker1 worker2 Ready <none> 1d v1.13.0 ...,kubernetes.io/hostname=worker2
위의 결과에서,
worker0
노드에disktype=ssd
레이블이 있는 것을 확인할 수 있다.
필수적인 노드 어피니티를 사용해 파드 스케줄하기
이 매니페스트는 disktype: ssd
라는 requiredDuringSchedulingIgnoredDuringExecution
노드 어피니티를 가진 파드를 설명한다.
파드가 disktype=ssd
레이블이 있는 노드에만 스케줄될 것이라는 것을 의미한다.
apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: disktype
operator: In
values:
- ssd
containers:
- name: nginx
image: nginx
imagePullPolicy: IfNotPresent
매니페스트를 적용하여 선택한 노드에 스케줄된 파드를 생성한다.
kubectl apply -f https://k8s.io/examples/pods/pod-nginx-required-affinity.yaml
파드가 선택한 노드에서 실행 중인지 확인하자.
kubectl get pods --output=wide
결과는 아래와 같다.
NAME READY STATUS RESTARTS AGE IP NODE nginx 1/1 Running 0 13s 10.200.0.4 worker0
선호하는 노드 어피니티를 사용해 파드 스케줄하기
이 매니페스트는 disktype: ssd
라는 preferredDuringSchedulingIgnoredDuringExecution
노드 어피니티를 가진 파드를 설명한다.
파드가 disktype=ssd
레이블이 있는 노드를 선호한다는 것을 의미한다.
apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
affinity:
nodeAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 1
preference:
matchExpressions:
- key: disktype
operator: In
values:
- ssd
containers:
- name: nginx
image: nginx
imagePullPolicy: IfNotPresent
매니페스트를 적용하여 선택한 노드에 스케줄된 파드를 생성한다.
kubectl apply -f https://k8s.io/examples/pods/pod-nginx-preferred-affinity.yaml
파드가 선택한 노드에서 실행 중인지 확인하자.
kubectl get pods --output=wide
결과는 아래와 같다.
NAME READY STATUS RESTARTS AGE IP NODE nginx 1/1 Running 0 13s 10.200.0.4 worker0
다음 내용
노드 어피니티에 대해 더 알아보기.
8 - 노드에 파드 할당
이 문서는 쿠버네티스 클러스터의 특정 노드에 쿠버네티스 파드를 할당하는 방법을 설명한다.
시작하기 전에
쿠버네티스 클러스터가 필요하고, kubectl 커맨드-라인 툴이 클러스터와 통신할 수 있도록 설정되어 있어야 한다. 이 튜토리얼은 컨트롤 플레인 호스트가 아닌 노드가 적어도 2개 포함된 클러스터에서 실행하는 것을 추천한다. 만약, 아직 클러스터를 가지고 있지 않다면, minikube를 사용해서 생성하거나 다음의 쿠버네티스 플레이그라운드 중 하나를 사용할 수 있다.
버전 확인을 위해서, 다음 커맨드를 실행kubectl version
.노드에 레이블 추가
클러스터의 노드를 레이블과 함께 나열하자.
kubectl get nodes --show-labels
결과는 아래와 같다.
NAME STATUS ROLES AGE VERSION LABELS worker0 Ready <none> 1d v1.13.0 ...,kubernetes.io/hostname=worker0 worker1 Ready <none> 1d v1.13.0 ...,kubernetes.io/hostname=worker1 worker2 Ready <none> 1d v1.13.0 ...,kubernetes.io/hostname=worker2
노드 한 개를 선택하고, 레이블을 추가하자.
kubectl label nodes <your-node-name> disktype=ssd
<your-node-name>
는 선택한 노드의 이름이다.선택한 노드가
disktype=ssd
레이블을 갖고 있는지 확인하자.kubectl get nodes --show-labels
결과는 아래와 같다.
NAME STATUS ROLES AGE VERSION LABELS worker0 Ready <none> 1d v1.13.0 ...,disktype=ssd,kubernetes.io/hostname=worker0 worker1 Ready <none> 1d v1.13.0 ...,kubernetes.io/hostname=worker1 worker2 Ready <none> 1d v1.13.0 ...,kubernetes.io/hostname=worker2
위의 결과에서,
worker0
노드에disktype=ssd
레이블이 있는 것을 확인할 수 있다.
선택한 노드에 스케줄되도록 파드 생성하기
이 파드 구성 파일은 disktype: ssd
라는 선택하는 노드 셀렉터를 가진 파드를
설명한다.
즉, disktype=ssd
레이블이 있는 노드에 파드가 스케줄될 것이라는
것을 의미한다.
apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
env: test
spec:
containers:
- name: nginx
image: nginx
imagePullPolicy: IfNotPresent
nodeSelector:
disktype: ssd
구성 파일을 사용해서 선택한 노드로 스케줄되도록 파드를 생성하자.
kubectl apply -f https://k8s.io/examples/pods/pod-nginx.yaml
파드가 선택한 노드에서 실행 중인지 확인하자.
kubectl get pods --output=wide
결과는 아래와 같다.
NAME READY STATUS RESTARTS AGE IP NODE nginx 1/1 Running 0 13s 10.200.0.4 worker0
특정 노드에 스케줄되도록 파드 생성하기
nodeName
설정을 통해 특정 노드로 파드를 배포할 수 있다.
apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
nodeName: foo-node # 특정 노드에 파드 스케줄
containers:
- name: nginx
image: nginx
imagePullPolicy: IfNotPresent
설정 파일을 사용해 foo-node
노드에 파드를 스케줄되도록 만들어 보자.
다음 내용
9 - 초기화 컨테이너에 대한 구성
이 페이지는 애플리케이션 실행 전에 파드를 초기화하기 위해 어떻게 초기화 컨테이너를 구성해야 하는지 보여준다.
시작하기 전에
쿠버네티스 클러스터가 필요하고, kubectl 커맨드-라인 툴이 클러스터와 통신할 수 있도록 설정되어 있어야 한다. 이 튜토리얼은 컨트롤 플레인 호스트가 아닌 노드가 적어도 2개 포함된 클러스터에서 실행하는 것을 추천한다. 만약, 아직 클러스터를 가지고 있지 않다면, minikube를 사용해서 생성하거나 다음의 쿠버네티스 플레이그라운드 중 하나를 사용할 수 있다.
버전 확인을 위해서, 다음 커맨드를 실행kubectl version
.초기화 컨테이너를 갖는 파드 생성
이 연습에서 하나의 애플리케이션 컨테이너와 하나의 초기화 컨테이너를 갖는 파드를 생성한다. 초기화 컨테이너는 애플리케이션 시작 전에 실행을 종료한다.
아래는 해당 파드의 구성 파일이다.
apiVersion: v1
kind: Pod
metadata:
name: init-demo
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
volumeMounts:
- name: workdir
mountPath: /usr/share/nginx/html
# 이 컨테이너들은 파드 초기화 중에 실행된다.
initContainers:
- name: install
image: busybox
command:
- wget
- "-O"
- "/work-dir/index.html"
- http://info.cern.ch
volumeMounts:
- name: workdir
mountPath: "/work-dir"
dnsPolicy: Default
volumes:
- name: workdir
emptyDir: {}
이 구성 파일에서, 파드가 가진 볼륨을 초기화 컨테이너와 애플리케이션 컨테이너가 공유하는 것을 볼 수 있다.
초기화 컨테이너는 공유된 볼륨을
/work-dir
에 마운트하고, 애플리케이션 컨테이너는 공유된 볼륨을
/usr/share/nginx/html
에 마운트한다. 초기화 컨테이너는 다음 명령을 실행 후
종료한다.
wget -O /work-dir/index.html http://info.cern.ch
초기화 컨테이너는 nginx 서버의 루트 디렉터리 내 index.html
파일을
저장한다.
파드를 생성한다.
kubectl apply -f https://k8s.io/examples/pods/init-containers.yaml
nginx 컨테이너가 실행 중인지 확인한다.
kubectl get pod init-demo
출력 결과는 nginx 컨테이너가 실행 중임을 보여준다.
NAME READY STATUS RESTARTS AGE
init-demo 1/1 Running 0 1m
init-demo 파드 내 실행 중인 nginx 컨테이너의 셸을 실행한다.
kubectl exec -it init-demo -- /bin/bash
셸에서 GET 요청을 nginx 서버로 전송한다.
root@nginx:~# apt-get update
root@nginx:~# apt-get install curl
root@nginx:~# curl localhost
출력 결과는 nginx가 초기화 컨테이너에 의해 저장된 웹 페이지를 제공하고 있음을 보여준다.
<html><head></head><body><header>
<title>http://info.cern.ch</title>
</header>
<h1>http://info.cern.ch - home of the first website</h1>
...
<li><a href="http://info.cern.ch/hypertext/WWW/TheProject.html">Browse the first website</a></li>
...
다음 내용
- 같은 파드 내 실행 중인 컨테이너들간 통신에 대해 배우기.
- 초기화 컨테이너에 대해 배우기.
- 볼륨에 대해 배우기.
- 초기화 컨테이너 디버깅에 대해 배우기.
10 - 스태틱(static) 파드 생성하기
스태틱 파드 는 API 서버 없이 특정 노드에 있는 kubelet 데몬에 의해 직접 관리된다. 컨트롤 플레인에 의해 관리되는 파드(예를 들어 디플로이먼트(Deployment))와는 달리, kubelet 이 각각의 스태틱 파드를 감시한다. (만약 실패할 경우 다시 구동한다.)
스태틱 파드는 항상 특정 노드에 있는 하나의 Kubelet에 매여 있다.
Kubelet 은 각각의 스태틱 파드에 대하여 쿠버네티스 API 서버에서 미러 파드(mirror pod)를 생성하려고 자동으로 시도한다. 즉, 노드에서 구동되는 파드는 API 서버에 의해서 볼 수 있지만, API 서버에서 제어될 수는 없다. 파드 이름에는 노드 호스트 이름 앞에 하이픈을 붙여 접미사로 추가된다.
참고: 만약 클러스터로 구성된 쿠버네티스를 구동하고 있고, 스태틱 파드를 사용하여 모든 노드에서 파드를 구동하고 있다면, 스태틱 파드를 사용하는 대신 데몬셋(DaemonSet) 을 사용하는 것이 바람직하다.
시작하기 전에
쿠버네티스 클러스터가 필요하고, kubectl 커맨드-라인 툴이 클러스터와 통신할 수 있도록 설정되어 있어야 한다. 이 튜토리얼은 컨트롤 플레인 호스트가 아닌 노드가 적어도 2개 포함된 클러스터에서 실행하는 것을 추천한다. 만약, 아직 클러스터를 가지고 있지 않다면, minikube를 사용해서 생성하거나 다음의 쿠버네티스 플레이그라운드 중 하나를 사용할 수 있다.
버전 확인을 위해서, 다음 커맨드를 실행kubectl version
.이 페이지는 파드를 실행하기 위해 도커(Docker)를 사용하며, 노드에서 Fedora 운영 체제를 구동하고 있다고 가정한다. 다른 배포판이나 쿠버네티스 설치 지침과는 다소 상이할 수 있다.
스태틱 파드 생성하기
파일 시스템이 호스팅하는 구성 파일이나 웹이 호스팅하는 구성 파일을 사용하여 스태틱 파드를 구성할 수 있다.
파일시스템이 호스팅 하는 스태틱 파드 매니페스트
매니페스트는 특정 디렉터리에 있는 JSON 이나 YAML 형식의 표준 파드 정의이다.
kubelet 구성 파일의 staticPodPath: <the directory>
필드를 사용하자.
명시한 디렉터리를 정기적으로 스캔하여, 디렉터리 안의 YAML/JSON 파일이 생성되거나 삭제되었을 때 스태틱 파드를 생성하거나 삭제한다.
Kubelet 이 특정 디렉터리를 스캔할 때 점(.)으로 시작하는 단어를 무시한다는 점을 유의하자.
예를 들어, 다음은 스태틱 파드로 간단한 웹 서버를 구동하는 방법을 보여준다.
스태틱 파드를 실행할 노드를 선택한다. 이 예제에서는
my-model
이다.ssh my-node1
/etc/kubelet.d
와 같은 디렉터리를 선택하고 웹 서버 파드의 정의를 해당 위치에, 예를 들어/etc/kubelet.d/static-web.yaml
에 배치한다.# kubelet 이 동작하고 있는 노드에서 이 명령을 수행한다. mkdir /etc/kubelet.d/ cat <<EOF >/etc/kubelet.d/static-web.yaml apiVersion: v1 kind: Pod metadata: name: static-web labels: role: myrole spec: containers: - name: web image: nginx ports: - name: web containerPort: 80 protocol: TCP EOF
노드에서 kubelet 실행 시에
--pod-manifest-path=/etc/kubelet.d/
와 같이 인자를 제공하여 해당 디렉터리를 사용하도록 구성한다. Fedora 의 경우 이 줄을 포함하기 위하여/etc/kubernetes/kubelet
파일을 다음과 같이 수정한다.KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --pod-manifest-path=/etc/kubelet.d/"
혹은 kubelet 구성 파일에
staticPodPath: <the directory>
필드를 추가한다.kubelet을 재시작한다. Fedora의 경우 아래와 같이 수행한다.
# kubelet 이 동작하고 있는 노드에서 이 명령을 수행한다. systemctl restart kubelet
웹이 호스팅 하는 스태틱 파드 매니페스트
Kubelet은 --manifest-url=<URL>
의 인수로 지정된 파일을 주기적으로 다운로드하여
해당 파일을 파드의 정의가 포함된 JSON/YAML 파일로 해석한다.
파일시스템이 호스팅 하는 매니페스트 의 작동 방식과
유사하게 kubelet은 스케줄에 맞춰 매니페스트 파일을 다시 가져온다. 스태틱 파드의 목록에
변경된 부분이 있을 경우, kubelet 은 이를 적용한다.
이 방법을 사용하기 위하여 다음을 수행한다.
kubelet 에게 파일의 URL을 전달하기 위하여 YAML 파일을 생성하고 이를 웹 서버에 저장한다.
apiVersion: v1 kind: Pod metadata: name: static-web labels: role: myrole spec: containers: - name: web image: nginx ports: - name: web containerPort: 80 protocol: TCP
선택한 노드에서
--manifest-url=<manifest-url>
을 실행하여 웹 메니페스트를 사용하도록 kubelet을 구성한다. Fedora 의 경우 이 줄을 포함하기 위하여/etc/kubernetes/kubelet
파일을 수정한다.KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --manifest-url=<manifest-url>"
Kubelet을 재시작한다. Fedora의 경우 아래와 같이 수행한다.
# kubelet 이 동작하고 있는 노드에서 이 명령을 수행한다. systemctl restart kubelet
스태틱 파드 행동 관찰하기
Kubelet 을 시작하면, 정의된 모든 스태틱 파드가 자동으로 시작된다. 스태틱 파드를 정의하고, kubelet을 재시작했으므로, 새로운 스태틱 파드가 이미 실행 중이어야 한다.
(노드에서) 구동되고 있는 (스태틱 파드를 포함한) 컨테이너들을 볼 수 있다.
# kubelet 이 동작하고 있는 노드에서 이 명령을 수행한다.
docker ps
결과는 다음과 유사하다.
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
f6d05272b57e nginx:latest "nginx" 8 minutes ago Up 8 minutes k8s_web.6f802af4_static-web-fk-node1_default_67e24ed9466ba55986d120c867395f3c_378e5f3c
API 서버에서 미러 파드를 볼 수 있다.
kubectl get pods
NAME READY STATUS RESTARTS AGE
static-web-my-node1 1/1 Running 0 2m
참고: Kubelet에 API 서버에서 미러 파드를 생성할 수 있는 권한이 있는지 미리 확인해야 한다. 그렇지 않을 경우 API 서버에 의해서 생성 요청이 거부된다. 파드시큐리티폴리시(PodSecurityPolicy) 에 대해 보기.
스태틱 파드에 있는 레이블 은 미러 파드로 전파된다. 셀렉터 등을 통하여 이러한 레이블을 사용할 수 있다.
만약 API 서버로부터 미러 파드를 지우기 위하여 kubectl
을 사용하려 해도,
kubelet 은 스태틱 파드를 지우지 않는다.
kubectl delete pod static-web-my-node1
pod "static-web-my-node1" deleted
파드가 여전히 구동 중인 것을 볼 수 있다.
kubectl get pods
NAME READY STATUS RESTARTS AGE
static-web-my-node1 1/1 Running 0 12s
kubelet 이 구동 중인 노드로 돌아가서 도커 컨테이너를 수동으로 중지할 수 있다. 일정 시간이 지나면, kubelet이 파드를 자동으로 인식하고 다시 시작하는 것을 볼 수 있다.
# kubelet 이 동작하고 있는 노드에서 이 명령을 수행한다.
docker stop f6d05272b57e # 예제를 수행하는 사용자의 컨테이너 ID로 변경한다.
sleep 20
docker ps
CONTAINER ID IMAGE COMMAND CREATED ...
5b920cbaf8b1 nginx:latest "nginx -g 'daemon of 2 seconds ago ...
스태틱 파드의 동적 추가 및 제거
실행 중인 kubelet 은 주기적으로, 설정된 디렉터리(예제에서는 /etc/kubelet.d
)에서 변경 사항을 스캔하고, 이 디렉터리에 새로운 파일이 생성되거나 삭제될 경우, 파드를 생성/삭제 한다.
# 예제를 수행하는 사용자가 파일시스템이 호스팅하는 스태틱 파드 설정을 사용한다고 가정한다.
# kubelet 이 동작하고 있는 노드에서 이 명령을 수행한다.
#
mv /etc/kubelet.d/static-web.yaml /tmp
sleep 20
docker ps
# 구동 중인 nginx 컨테이너가 없는 것을 확인한다.
mv /tmp/static-web.yaml /etc/kubelet.d/
sleep 20
docker ps
CONTAINER ID IMAGE COMMAND CREATED ...
e7a62e3427f1 nginx:latest "nginx -g 'daemon of 27 seconds ago