[2024.11.03]
8. 파드 리소스 할당 및 제한
1) Pod Resource Request 및 Limits
- https://kubernetes.io/docs/tasks/configure-pod-container/assign-cpu-resource
- https://kubernetes.io/docs/tasks/configure-pod-container/assign-memory-resource
- https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod
Configure Quality of Service for Pods
This page shows how to configure Pods so that they will be assigned particular Quality of Service (QoS) classes. Kubernetes uses QoS classes to make decisions about evicting Pods when Node resources are exceeded. When Kubernetes creates a Pod it assigns on
kubernetes.io
2) Container Resource 설정 예제
3) 컨테이너 리소스 할당 구성(컨테이너에 cpu/mem 할당 - request 사용)
apiVersion: v1
kind: Pod
metadata:
name: nginx-resources-pod
spec:
containers:
- name: nginx-container
image: nginx:1.14
ports:
- containerPort: 80
protocol: TCP
resources:
requests:
cpu: 1
memory: 500Mi
request를 이용하여 컨테이너에 자원을 할당하기 위한
nginx-resource-requests-pod.yml 파일을 생성한다
nginx-resource-requests-pod.yml 파일을 이용하여
nginx-resources-pod 파드를 생성하고,
컨테이너 자원이 할당되었는지 확인한다
describe로 확인 시 request에
cpu는 코어 1개, 메모리는 500MB로 잡힌 것을 확인할 수 있다
확인이 끝났다면 nginx-resources-pod 파드를 삭제한다
4) 컨테이너 리소스 할당 구성(컨테이너에 cpu/mem 할당 - limits 사용)
apiVersion: v1
kind: Pod
metadata:
name: nnginx-resources-pod
spec:
containers:
- name: nginx-container
image: nginx:1.14
ports:
- containerPort: 80
protocol: TCP
resources:
limits:
cpu: 1
memory: 500Mi
이번에는 limits를 이용하여 컨테이너에
자원을 할당하기 위한 nginx-resource-limits-pod.yml 파일을 생성한다
nginx-resouce-limits-pod.yml 파일을 이용하여
nginx-resources-pod 파드를 생성하고,
컨테이너 자원이 할당되었는지 확인한다
describe로 확인 시 cpu 코어 1개, 메모리는 500MB로 설정되어 있다
limits만 설정하고 requests를 설정하지 않으면,
requests 값은 limits 값과 동일한 값이 할당된다
값을 확인했다면 nginx-resources-pod 파드를 삭제한다
5) 컨테이너 리소스 할당 구성(컨테이너에 cpu/mem 할당 - request/limits 사용)
apiVersion: v1
kind: Pod
metadata:
name: nginx-resources-pod
spec:
containers:
- name: nginx-container
image: nginx:1.14
ports:
- containerPort: 80
protocol: TCP
resources:
limits:
cpu: 1
memory: 1Gi
requests:
cpu: 200m
memory: 250Mi
request를 이용하여 컨테이너에 자원을 할당하기 위한
nginx-resource-request-limits-pod.yml 파일을 생성한다
nginx-resource-request-limits-pod.yml 파일을 이용하여
nginx-resources-pod 파드를 생성하고,
컨테이너 자원이 할당되었는지 확인한다
이번에는 describe로 확인 시 limits 부분에는
cpu 코어 1개와 메모리 1GB가 설정되어 있으며,
requests에는 cpu 200m와 메모리 250MB가 설정되어 있다
*200m은 0.2개의 CPU 코어, 즉 CPU의 20%를 의미한다
m은 milli의 약자로 1000m = 1 CPU가 된다
nginx-resource-requests-limits-pod.yml 파일을 이용하여
nginx-resources-pod 파드를 생성하기 위해 기존의
nginx-resources-pod를 삭제하고,
컨테이너 자원이 할당되었는지 확인하고 다음 과정을 진행한다
nginx의 이미지를 1.14가 아닌 nginx로 수정하고 다시 생성한다
그런 다음 /bin/bash 셸에서 업데이트 및 스트레스를 설치한다
stress 도구를 이용해 CPU와 메모리에 인위적으로 부하를 주는 방식으로,
첫 번째 명령의 경우 800MB 크기의 메모리를 할당 후 5초 동안 유지하고,
두 번째 명령의 경우에도 2GB 크기의 메모리를 할당하고 5초 동안 유지하도록 실행했다
파드 정상적으로 작동 중인 것을 확인한다
메모리와 CPU의 부하를 준 상태이기 때문에
메모리 부하가 클러스터 노드에 어떤 영향을 미치는지
확인하기 위해 노드 상태를 살펴본다
현재 부하를 줬지만 파드와 노드에는 아무 영향이 없는 것을 확인했다
다음으로는 위 명령어를 실행하여
지속적으로 CPU를 사용하게 하여 CPU에 부하를 준다
htop으로 확인 시 메모리가 최대치로 동작 중인 것을 확인할 수 있다
테스트를 마무리하고 nginx-resources-pod 파드를 삭제한다
6) 컨테이너 리소스 할당 구성(requests에 대한 over cpu 설정)
먼저 node1, node2, node3에서 CPU 정보를 확인한다
apiVersion: v1
kind: Pod
metadata:
name: nginx-resources-pod
spec:
containers:
- name: nginx-container
image: nginx:1.14
ports:
- containerPort: 80
protocol: TCP
resources:
requests:
cpu: 6
memory: 250Mi
request를 이용하여 컨테이너에 자원을 할당하기 위해
nginx-reource-requests-overcpu-pod.yml 파일을 생성한다
nginx-reource-requests-overcpu-pod.yml 파일을 이용하여
nginx-resources-pod 파드를 생성하고 컨테이너 자원이
할당되었는지 확인한다
현재 파드가 Pending 상태인 이유는 resources.requests.cpu: 6 설정에 따라
CPU 6개의 리소스를 요청하고 있기 때문이다
쿠버네티스에서는 requests 필드에 설정된 리소스를
pod가 실행되기 전에 예약해야 되는데,
클러스터의 노드에 요청된 리소스를 제공할 만큼의 여유가 없다면,
해당 pod는 Pending 상태로 남게 된다
위의 설명과 같이 현재 request 부분을 살펴보게 되면,
6개의 cpu 리소스가 할당되어 있고 메모리는 250MB로 설정되어 있다
확인 후 nginx-resources-pod 파드를 삭제한다
7) 컨테이너 리소스 할당 구성(requests에 대한 over memory 설정)
이번에는 node1, node2, node3에서 Memory 정보를 확인한다
reqeust를 이용하여 컨테이너에 자원을 할당하기 위한
nginx-resource-requests-overmem-pod.yml 파일을 생성한다
이번에도 확인 시 Pending 상태로 확인된다
이 경우 역시 CPU 6개의 리소스를 요청하고 있어,
클러스터의 노드에서 6Gi(GB)의 메모리를
제공할 수 없기 때문일 가능성이 크다
kubectl decribe의 request 부분은 설정 파일에서 정의한
리소스 요청 값을 그대로 반영하게 된다
이 값은 실제로 할당된 리소스의 양이 아닌,
pod가 실행되기 위해 필요한 최소한의 리소스 요구량이다
아래를 살펴보게 되면 3 Insufficient memory라는 문구가 나타난다
이 메시지는 클러스터 내의 4개 노드 중 3개 노드에서 pod를 실행할 만큼
충분한 메모리가 부족하다는 뜻이다
이로 인해 쿠버네티스 스케줄러가 해당 pod를 실행할
적절한 노드를 찾을 수 없어 Pending 상태에 있게 되는 것이다
확인 후 nginx-resources-pod 파드를 삭제한다
9. 파드 환경 변수 구성
1) 파드 환경 변수
컨테이너에서 사용할 수 있는 환경 변수를 정의할 수 있다
2) 파드 환경 변수 설정
apiVersion: v1
kind: Pod
metadata:
name: nginx-env-pod
spec:
containers:
- name: nginx-container
image: nginx:1.14
ports:
- containerPort: 80
protocol: TCP
env:
- name: MYWEB
value: "/usr/share/nginx/html/"
nginx 파드를 생성할 nginx-env-pod.yml 파일을 생성한다
nginx-env-pod.yml 파일을 이용하여
nginx-env-pod 파드를 생성하고 확인한다
describe 명령어로 nginx-env-pod의 환경 변수 내용을 확인한다
현재 MYWEB: /usr/share/nginx/html/로 설정되어 있다
실제 컨테이너에서 확인하려면 env 명령어를 사용하여 확인한다
nginx-env-pod 파드에 구동된 컨테이너에서
MYWEB 환경 변수가 설정되었는지 확인한다
현재 4번째 줄에 MYWEB=/usr/share/nginx/html/을 확인할 수 있다
다음 실습을 위해 nginx-env-pod 파드를 삭제한다
10. 파드 예제
먼저 예제의 디렉터리를 생성하고 해당 디렉터리로 이동한다
그런 다음 예문에 나와 있는 것과 같이 myweb-pod.yml이라는 이름으로
YAML 파일을 생성하고, 아래 내용을 작성 후 저장한다
내용을 설명하게 되면,
metadata의 경우 pod 이름과 namespace를 설정한다
containers는 컨테이너 이름, 이미지, 포트, 환경 변수를 설정하고,
resources는 CPU와 메모리 리소스 요청(request)과 제한(limitss)을 설정한다
product로 namespcae를 생성하고,
작성한 yaml 파일로 pod까지 생성한다
다음으로 pod가 올바르게 생성되었는지 확인하는 절차를 거친다
describe 명령어를 통해 보다 자세히 확인한다
마지막의 Environment를 보게 되면 DB: mydb로 설정되어 있으며,
cpu는 200m, memory는 500Mi로 지정한 대로 설정되어 있는 것을 볼 수 있다
예제 실습이 마무리되었기 때문에 삭제한다
07. Kubernetes 컨트롤러
1. 컨트롤러(Controller)
컨트롤러는 클러스터 및 파드를 생성하고 제어 및 관리하는 일을 담당한다
| 일반적으로 상태를 유지하지 않아도 되는 파드를 관리하는 경우(Stateless) |
| 레플리케이션 컨트롤러(Replication Controller) 쿠버네티스 프로젝트 초기부터 존재하던 컨트롤러이다 실행할 파드의 갯수를 지정할 수 있고 지정한 갯수만큼 파드를 생성하고 유지되도록 관리한다 레플리카셋(ReplicaSet) 레플리케이션 컨트롤러와 비슷하지만 집합 기반의 셀렉터(Selector)를 지원한다 집합 기반의 셀렉터는 in, notin, exists와 같은 연산을 제공하며 조건에 따라 필요한 레이블을 선택할 수 있다 디플로이먼트(Deployment) 상태가 없는 앱을 배포할 때 사용하는 가장 기본적인 컨트롤러이다 디플로이먼트는 레플리카셋를 관리하면서 앱 배포에 관련된 작업이 가능하다 파드의 배포뿐만이 아닌 배포 방식, 버전 롤링 업데이트 및 롤백 기능을 제공한다 |
| 클러스터 전체에 배포가 필요한 파드 |
| 데몬셋(Daemon Set) 데몬셋은 클러스터 전체 노드에 특정 파드를 실행할 때 사용한다 예를 들면, 노드마다 존재하는 로그 수집기나 시스템 리소스를 받아 볼 수 있는 Exporter 같은 것들이 있다 데몬셋이 대상으로 하고 있던 노드가 클러스터에 제거되는 경우, 다른 노드로 이동하여 파드를 실행시키지 않고 제거된다 |
| 상태 관리가 필요한 파드 |
| 스테이트풀셋(StatefulSet) 레플리케이션 컨트롤러, 레플리카셋, 디플로이먼트가 stateless한 파드를 관리하는 용도였다면, 스테이트 풀셋은 상태가 있는 파드를 관리하는 컨트롤러이다 상태가 있다는 의미는 컨테이너가 종료되더라도 컨테이너에서 필요로 하는 데이터가 남게(Stateful 상태) 되어 파드를 재시작하더라도 데이터를 보존할 수 있다는 것이다 |
| 배치성 작업을 진행하는 파드 |
| 잡(Job) 배치성 작업을 진행하기 위해 사용하는 컨트롤러이다 즉, 실행된 후 종료해야 하는 성격의 작업을 실행시킬 때 사용하는 컨트롤러이다 잡의 종류로는 단일잡, 완료된 잡 갯수가 있는 병렬 잡, 워크 큐가 있는 병렬 잡이 있다 크론잡(CronJob) 크론잡은 잡을 시간 기준으로 관리하도록 진행한다 지정한 시간에 한 번만 잡을 실행하거나 지정한 시간 동안 주기적으로 잡을 반복할 수 있다 |
2. 레플리케이션 컨트롤러(Replication Controller)
- https://kubernetes.io/ko/docs/concepts/workloads/controllers/replicationcontroller
레플리케이션 컨트롤러
참고:ReplicaSet을 구성하는 Deployment가 현재 권장하는 레플리케이션 설정 방법이다. 레플리케이션컨트롤러 는 언제든지 지정된 수의 파드 레플리카가 실행 중임을 보장한다. 다시 말하면, 레플리
kubernetes.io
1) 레플리케이션 컨트롤러 yaml 파일 내용
레플리카스(replicas)을 확인하여 파드 갯수를 보장하며,
셀렉터(selector)의 레이블 확인하여 파드를 생성한다
또한, 레플리카스로 지정된 파드의 갯수가 부족할 경우,
템플릿(template)을 확인하여 파드를 추가한다
2) 레플리케이션 컨트롤러 구성
apiVersion: v1
kind: ReplicationController
metadata:
name: nginx-rc
spec:
replicas: 3
selector:
app: webui
template:
metadata:
name: nginx-pod
labels:
app: webui
spec:
containers:
- name: nginx-container
image: nginx:1.14
레플리케이션 컨트롤러를 이용하여 파드를 생성할
nginx-rc.yml 파일을 생성한다
nginx-rc.yml 파일을 이용하여
레플리케이션 컨트롤러로 관리되는 파드를 생성하고,
레플리케이션 컨트롤러 정보를 확인한다
describe로 확인해 봤을 때
nginx-rc 레플리케이션 컨트롤러가 성공적으로 작동하여
3개의 복제본을 생성했으며, 각 파드가 정상적으로
실행 중인 것을 확인할 수 있다
파드 생성 확인을 진행했을 때 문제가 없으며,
정상적으로 Running 상태인 것을 확인할 수 있다
3) 레플리케이션 컨트롤러 동작 확인
기존의 파일을 복사하여 테스트용 redis.yml 파일을 생성한다
위의 예문과 같이 vi 편집기로 삭제할 것들을 수정한다
테스트용 파일을 만들었다면 파드의 레벨까지 확인한다
생성하지 않았기 때문에 현재는 nginx만 확인된다
redis.yml 파일을 이용하여
동일한 app=webui 라벨을 가진 파드를 생성한다
다시 라벨을 확인해 보지만,
app=webui 라벨에 replicas가 3으로 설정되어 있기 때문에
파드가 더 실행되지 않고 종료된
위 명령어는 레플리케이션 컨트롤러 리소스의 정보를 조회하는 명령어
* ReplicationController는 Kubernetes에서 애플리케이션을 복제하고,
지정된 수의 Pod을 항상 실행 상태로 유지하기 위해 사용되는 객체
동작 중이므로 # kubectl edit rc nginx-rc
위 명령을 이용하여 nginx-rc 파일을 편집한다
위 명령어를 이용하여 17번 라인을 3에서 4로 변경한다
replicas가 4개로 변경되었기 때문에
템플릿을 이용하여 파드를 추가로 실행한다
최근에 생성된 파드를 삭제하고 파드 1개가 다시 생성되어
파드 4개로 유지되는지 확인해 본다
위 화면과 같이 삭제 후 다시 확인했을 때 4개인 것을 볼 수 다
이번에는 kubectl scale rc 명령을 이용하여
replicas를 2개로 변경하고 파드를 확인한다
nginx-rc라는 레플리케이션 컨트롤러의 복제본 수를
2개로 변경하는 명령이기 때문에 라벨 확인 시 2개로 확인된다
*복제본 수를 변경한다고 해서 라벨이 변경되지는 않음
파드의 라벨은 복제본 수와 관계없이 파드 템플릿에서 설정한 값대로 유지됨
4) 레플리케이션 컨트롤러 이용한 컨테이너 이미지 업그레이드 구성
nginx-rc 파일을 편집하여 컨테이너 이미지 버전을
상위 버전으로 업데이트하고 파드를 확인한다
상위 버전을 업데이트하고 describe로 확인하게 되면,
파드 하나가 새로 생성되거나 지우거나 할 때 15로 변경된다
레플리케이션 컨트롤러는 app=webui의 replicas 갯수만 관리한다
그렇기 때문에 replicas 갯수가 충족된 상태에서는 nginx:1.15 버전으로
업데이트가 되지 않는다
레플리케이션 컨트롤러에 의해서 관리되는 파드 1개를 삭제한다
현재 기존파드를 삭제하고 새로운 파드를 1개 생성하면,
nginx:1.15 버전 파드로 생성되는 걸 확인할 수 있다
새로 생성된 nginx-rc-zh669의 describe를 확인해도
Containers의 Image 부분에서 nginx:1.15로 표시된다
파드 전체를 삭제하고 파드 2개가 다시 생성됨과 동시에
nginx:1.15 버전의 파드로 생성되는지 확인하는 과정을 진행했다
모든 실습을 진행했다면 nginx-rc 레플리케이션 컨트롤러를 삭제한다
nginx-rc 컨트롤러를 삭제하면 파드도 같이 삭제된다
3. 레플리카셋(ReplicaSet)
- https://kubernetes.io/ko/docs/concepts/workloads/controllers/replicaset
레플리카셋
레플리카셋의 목적은 레플리카 파드 집합의 실행을 항상 안정적으로 유지하는 것이다. 이처럼 레플리카셋은 보통 명시된 동일 파드 개수에 대한 가용성을 보증하는데 사용한다. 레플리카셋의
kubernetes.io
레플리케이션 컨트롤러에 조건부 셀렉터가 추가된 컨트롤러이다
조건부 셀렉터에는 in, notin, exists 연산자를 제공하며,
연산자를 이용하여 레이블 안에서 검색을 상세하게 할 수 있다
1) 레플리카셋 컨트롤러 yaml 파일 내용
2) 레플리카셋 컨트롤러 구성
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: nginx-rs
spec:
replicas: 3
selector:
matchLabels:
app: webui
template:
metadata:
name: nginx-pod
labels:
app: webui
spec:
containers:
- name: nginx-container
image: nginx:1.14 
레플리카셋 컨트롤러를 이용하여 파드를 생성한 nginx-rs.yml 파일을 생성한다
nginx-rs.yml 파일을 이용하여 파드를 생성한다
*kubectl get rs -> kubectl get replicasets
설정 파일에서 nginx-rs라는 이름의 replicasets이
3개의 pod 복제본을 실행하도록 설정되어 있고,
각 pod에는 app=webui라는 라벨이 지정되도록 설정했기 때문에
현재 describe로 확인하게 되면 그런 설정 값이 적용되어 있다
nginx-rs 파드 생성과 라벨 설정이 되어 있는지 확인한다
파드 1개를 삭제하고 새로 생성되는지 확인하기 위해
99f9w의 파드를삭제하고 다시 그 자리를 확인해 보면,
69st2라는 새로운 파드가 생성된 것을 볼 수 있다
kubectl scale rs 명령을 통해
replicasets을 2개로 변경하고 파드를 확인하면,
위에서 3개였던 파드가 현재는 2개로 나타나게 된다
이번에는 scale 명령을 이용하여 replicasets을 4개로 변경한다
그럼 2개로 나오던 파드가 이번에는 4개로 나타나는 것을 볼 수 있다
파드는 유지하고 replicasets만 삭제할 경우에는
--cascade=orphan 옵션을 이용하면 된다
레플리케이션 컨트롤러 ~/kube/07/rc/ 디렉터리에
nginx-rc.yml 파일을 이용하여 파드를 생성한다
현재 nginx-rc.yml에는 replicas 갯수가 3으로 지정되어 있기 때문에
파드가 4개에서 3개로 조정되는 것을 확인할 수 있다
3) 레플리카셋 컨트롤러 이용한 컨테이너 이미지 업그레이드 구성
nginx-rc 파일을 편집하여 컨테이너 이미지 버전을
상위 버저으로 업데이트하고 파드를 확인다
레플리카셋 컨트롤러는 app=webui의 replicas 갯수만 관리한다
그렇기 때문에 replicas 갯수가 충족된 상태에서는
nginx:1.15 버전으로 업데이트가 되지 않는다
레플리케이션 컨트롤러에 의해서 관리되는 파드 1개를 삭제한다
기존 파드를 삭제하고 새로운 파드를
1개 생성하면 nginx:1.15 버전 파드로 생성된다
파드 전체를 삭제하고 파드가 다시 생성되면서
nginx:1.15 버전의 파드로 생성되는지 확인한다
먼저 삭제 후 파드가 생성되었는지부터 확인한다
새로 생성된 파드의 버전을 확인하게 되면
이전 버전이 아닌 nginx:1.15 버전으로 업데이트된 것을 확인할 수 있다
실습을 종료했다면 다음 실습을 위해 삭제한다
nginx-rs 레플리카셋 컨트롤러를 삭제한다
nginx-rs 컨트롤러를 삭제하면 파드도 같이 삭제된다
4. 디플로이먼트(Deployment)
- https://kubernetes.io/ko/docs/concepts/workloads/controllers/deployment
디플로이먼트
디플로이먼트(Deployment) 는 파드와 레플리카셋(ReplicaSet)에 대한 선언적 업데이트를 제공한다. 디플로이먼트에서 의도하는 상태 를 설명하고, 디플로이먼트 컨트롤러(Controller)는 현재 상태에서 의
kubernetes.io
1) Rolling Update & RollBack
- https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/update/update-intro
롤링 업데이트 수행하기
<!DOCTYPE html> 목표 kubectl을 이용하여 롤링 업데이트 수행하기 애플리케이션 업데이트하기 사용자들은 애플리케이션이 항상 가용한 상태일 것이라 여기고 개발자들은 하루에 여러번씩 새로운 버
kubernetes.io
2) 디플로이먼트 컨트롤러 yaml 파일 내용
3) 디플로이먼트 컨트롤러 구성
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deploy
spec:
replicas: 3
selector:
matchLabels:
app: webui
template:
metadata:
name: nginx-pod
labels:
app: webui
spec:
containers:
- name: nginx-container
image: nginx:1.14
디플로이먼트 컨트롤러를 이용하여
파드를 생성할 nginx-deploy.yml 파일을 생성한다
nginx-deploy.yml 파일을 이용하여 파드를 실행한다
파드는 결국 리플리카셋에 의해 생성, 관리가 된다고 보면 된다
nginx-deploy 파드 생성을 확인하고 잘 작동되는지 확인한다
3개의 파드 중 하나를 삭제하고 다시 생성되는지 확인한다
2dgwb를 삭제하고 txlnf가 새로 생긴 것을 볼 수 있다
리플리카셋을 삭제하고 디플로이먼트에 의해서
다시 리플리카셋과 파드 3개가 생성되는지 확인한다
현재 nginx-deploy의 리클리카셋을 삭제해도 파드는 그대로인 화면을 확인할 수 있다
다음 실습을 위해 디플로이먼트 컨트롤러를 삭제한다
4) kubectl 명령을 이용한 디플로이먼트 롤링 업데이트 및 롤백 구성
Rolling Update
# kubectl set image deployment <deploy_name> <container_name>=<new_version>
Rolling stop/start/status
$ kubectl rollout pause deploy nginx-deploy
$ kubectl rollout resume deploy nginx-deploy
$ kubectl rollout status deploy nginx-deploy
Roll Back
# kubectl rollout history deployment <deploy_name>
# kubectl rollout undo deploy <deploy_name>
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deploy
spec:
replicas: 3
selector:
matchLabels:
app: webui
template:
metadata:
labels:
app: webui
spec:
containers:
- name: nginx-container
image: nginx:1.14
상위 디렉터리로 이동 후
디플로이먼트 컨트롤러를 이용하여
파드를 생성할 deploy-test1.yml 파일을 생성한다
deploy-test.yml 파일을 이용하여 파드를 생성한다
kubectl 명령어 수행 시 --record 옵션을 사용해야 된다
사용하지 않는다면 나중에 롤백을 할 수 없기 때문에
--record 옵션을 반드시 사용해야 된다
*REVISION -> 기록
파드 컨테이너 이미지 버전이 nginx:1.14인 것을 확인한다
그런 다음 컨테이너이미지를 nginx:1.15 버전으로 업그레이드하기 위해
롤링 업데이트를 실행하고 다시 확인하게 되면
위와 같이 nginx:1.14 버전이었던 이미지가 nginx:1.15 버전이 되었다
이번에는 컨테이너 이미지를 nginx:1.16 버전으로
업데이트하기 위해서 롤링 업데이트를 진행한다
다시 확인 시 이번에는 nginx:1.16 버전을 확인할 수 있다
nginx-deploy 배포의 현재 롤아웃 상태를 확인하고,
마지막으로는 nginx-deploy 배포의 롤아웃 이력을 확인한다
이번에는 컨테이너 이미지를 nginx:1.17 버전으로
업그레이하기 위해 롤링 업데이트를 진행한다
현재 롤아웃 상태를 확인하고 sucessfully가 나오면
컨테이너 이미지로 버전을 확인한다
nginx:1.17 버전인 것을 확인하고,
마지막으로는 nginx-deploy 배포의 롤아웃 이력을 확인한다
롤링 업데이트 parameter 내용은 위와 같다
컨테이너 이미지를 nginx:1.18 버전으로
업그레이드하기 위해 롤링 업데이트를 진행한다
# kubectl describe pod | grep Image
위 명령을 여러 번 실시하여
업데이트 및 이전 버전 삭제 내용을 확인한다
nginx:1.17 버전이 삭제되면서 마지막에는 nginx:1.18 버전만 남았다다
컨테이너 이미지를 바로 이전 버전인 nginx:1.17
롤백을 실시하고 확인한다
REVISION을 지정하여 롤백(컨테이너 이미지 nginx:1.15)을 실시하고 확인하면,
현재 컨테이너 이미지가 nginx:1.15 버전으로 나타나는 것을 확인할 수 다
이번에는 REVISION을 지정하여
컨테이너 이미지 nginx:1.14 버전으로 롤백을 진행하고 확인한다
방금까지 nginx:1.15였던 버전이 삭제됨과 동시에
nginx:1.14의 버전으로 롤백 중인 것을 실시간을 확인 가능하다
모든 확인이 끝났다면 디플로이먼트 컨트롤러를 삭제한다
4) yaml 파일 이용한 디플로이먼트 롤링 업데이트 및 롤백 구성
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deploy
annotations:
iamgeVersion: nginx 1.14 # --record
spec:
replicas: 3
selector:
matchLabels:
app: webui
template:
metadata:
labels:
app: webui
spec:
containers:
- name: web
image: nginx:1.14
디플로이먼트 컨트롤러를 이용하여 파드를 생성할
deploy-test2.yml 파일을 생성한다
*들여쓰기 시 [TAB] 사용하면 안 되고, 스페이스로 입력해야 오류가 생기지 않는다
deploy-test2.yml 파일을이용하여 파드를 생성한다
파드를 생성과 작동 유무를 확인하고,
컨테이너 이미지 버전이 nginx:1.14인 것을 확인한다
deploy-test2.yml을 버전을 nginx:1.15로 변경고
수정된 deploy-test2.yml 파일을 이용하여 파드를 재생성한다
현재 위 화면에서도 알 수 있듯이 create를 하지만 에러가 나타난다
이미 동일한 이름의 리소스가 존재하면 에러가 발생하게 된다
create 명령은 새로운 리소스를 생성할 때 사용하는 명령이기 때문에,
동일한 이름을 가진 리소스가 있으면 충돌로 인해 에러가 나는 것이다
kubectl apply를 사용하면 기존 리소스가 있는 경우 업데이트를 수행하므로,
이미 리소스가 존재할 때 유용하게 사용할 수 있다
파드의 작동 유무를 확인하고,
컨테이너 이미지의 버전도 nginx:1.15인 것을 확인한다
마지막으로 롤아웃 이력까지 확인하고 마무리한다
모두 확인했다면 다음 실습을 위해
디플로이먼트 컨트롤러를 삭제한다
5. 데몬셋(DaemonSet)
- https://kubernetes.io/ko/docs/concepts/workloads/controllers/daemonset
데몬셋
데몬셋 은 모든(또는 일부) 노드가 파드의 사본을 실행하도록 한다. 노드가 클러스터에 추가되면 파드도 추가된다. 노드가 클러스터에서 제거되면 해당 파드는 가비지(garbage)로 수집된다. 데몬
kubernetes.io
[참고] kubernetes yaml generator
- https://syshunt.com/kubernetes-yaml-generator
Kubernetes YAML Generator - Online K8s YAML UI tool
Kubernetes YAML Generator is an online UI tool that can generate k8s objects YAML based on user input selection Eg. Deployment and pod YAML.
syshunt.com
1) 데몬셋 컨트롤러 yaml 파일 내용
2) 데몬셋 구성
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: nginx-ds
spec:
selector:
matchLabels:
app: webui
template:
metadata:
name: nginx-pod
labels:
app: webui
spec:
containers:
- name: nginx-container
image: nginx:1.14
데몬셋 컨트롤러를 이용하여
파드를 생성할 nginx-ds.yml 파일을 생성한다
nginx-ds.yml 파일을 이용하여 파드를 생성하고 확인한다
현재 DaemonSet 설정을 통해 모든 녿에 nginx 컨테이너가
하나씩 배치되어 실행 중이며, 각 pod는 app=webui 라벨을
가지고 DaemonSet의 제어를 받게 된다
데몬셋과 각 파드의 상태를 확인한다
정상적으로 실행되고 있는 것까지 확인한
파드만 확인하게 되면 각각의 노드에 파드가 생성되어 있어야 된다
파드 1개를 삭제하고 다시생성되는지 확인한다
7pwht를 삭제 후 r7rnm이 새로 생성된 것을 확인했다
3) 데몬셋을 이용한 롤링 업데이트 및 로백 구성
파드 컨테이너 이미지 버저을 확인하게 되면,
nginx:1.14 버전인 것을 확인할 수 있다
컨테이너 이미지를 nginx:1.15 버전으로 업그레이드하기 위해
nginx:1.15로 버전을 수정하고,
롤링 업데이트를 실행하고 확인한다
현재 이미지 버전은 nginx:1.15인 것을 볼 수 있다
롤백을 실시하고 nginx:1.14 버전으로 돌아가는 것까지 확인다
다음 실습을 위해 데몬셋 컨트롤러를 삭제한다
6. 스테이트풀셋(StatefulSet)
- https://kubernetes.io/ko/docs/concepts/workloads/controllers/statefulset
스테이트풀셋
스테이트풀셋은 애플리케이션의 스테이트풀을 관리하는데 사용하는 워크로드 API 오브젝트이다. 파드 집합의 디플로이먼트와 스케일링을 관리하며, 파드들의 순서 및 고유성을 보장한다 . 디플
kubernetes.io
1) 스테이트풀셋 컨트롟러 yaml 파일 내용
2) 스테이트풀셋 컨트롟러 구성
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: nginx-sts
spec:
replicas: 3
selector:
matchLabels:
app: webui
template:
metadata:
name: nginx-pod
labels:
app: webui
spec:
containers:
- name: nginx-container
image: nginx:1.14 
스테이트풀셋 컨트롤러를 이용하여
파드를 생성할 nginx-sts.yml 파일을 생성한다
nginx-sts.yml 파일을 이용하여 파드를 생성하고, describe로 확인한다
이 설정을 통해 nginx 파드를 StatefulSet으로 배포하고 있으며,
고유한 ID와 순차적인 업데이트 방식을 활용하여
클러스터에서 안정적으로 실행되고 있다
Replicas: 3 desired | 3 total
- desired는 원하는 복제본 수(3개)를 나타내고,
total은 실제로 생성된 복제본 수(3개)를 나타낸다
Pods Status: 3 Running / 0 Waiting / 0 Successed / 0 Faild
- StatefulSet이 관리하는 모든 Pod가 정상적으로 실행 중이며,
대기 중이거나 실패한 Pod는 없다는 걸 뜻한다
현재 파드가 정상적으로 생겼고,
문제 없이 실행되고 있는 상태인 것까지 확인한다
다음으로 nginx-sts-2 파드를 삭제하고,
동일한 이름으로 파드가 새로 생성되는지 확인한다
sts-2를 삭제했지만 다시 확인 시 sts-2가 생성되었다
replicas 갯수를 4개로 증가시킨 이후
새로 생성되는 파드 이름을 확인한다
2번까지였던 파드가 3번까지 생긴 것을 볼 수 있다
replicas 갯수를 2개로 감소시킨 이후
남아 있는 파드 이름과 삭제된 파드 이름을 확인한다
4개일 때는 3까지 나타났지만 현재는 0과 1로 두 개의 파드만 남아 있다
두 개의 파드 버전을 확인 시 nginx:1.14이다
컨테이너 이미지를 nginx:1.15 버전으로 업그레이드하기 위해
롤링 업데이트를 실행하고 확인하면 nginx:1.15로 변경되어 있다
그 상태에서 다시 롤백을 진행하게 되면,
nginx:1.15 버전에서 14번으로 변경되는 것을 확인할 수 다
다음 실습을 위해 스테이트풀셋 컨트롤러를 삭제한다
7. Job
- https://kubernetes.io/ko/docs/concepts/workloads/controllers/job
잡
잡에서 하나 이상의 파드를 생성하고 지정된 수의 파드가 성공적으로 종료될 때까지 계속해서 파드의 실행을 재시도한다. 파드가 성공적으로 완료되면, 성공적으로 완료된 잡을 추적한다. 지정
kubernetes.io
at <-- 절대적인 스케줄러
cron <-- 주기적인 스케줄러
1) Job 컨트롤러 구성
apiVersion: batch/v1
kind: Job
metadata:
name: job-test
spec:
template:
spec:
containers:
- name: centos-container
image: centos:7
command: ["bash"]
args:
- "-c"
- "echo 'Hello Docker'; sleep 60; ls -l /tmp ; echo 'Bye Docker'"
restartPolicy: Never
Job이 적용된 파드를 생성하기 위한 nginx-rs.yml 파일을 생성한다
job-test.yml 파일을 이용하여 파드를 생성하고,
파드가 정상적으로 실행되고 있는지 여부를 확인한다
decribe로 상세하게 확인하면 Pods Statuses에서 1개가 활성화 중이고,
커맨드 부분에서 설정한 파일의 내용이 할당되어 있다
마지막으로 아래의 메시지를 확인하면 job-test로 파드가 만들어진 것을 확인할 수 있다
만든 직후 확인하면 ContainerCreating으로 나타나지만,
시간이 조금 지나서 확인하게 될 시 Running으로 나온다
쿠버네티스에서 job은 일정한 작업을 수행하고,
그 작업이 성공적으로 완료되면 pod를 종료시키는 일회성 작업에 주로 사용된다
그렇기 때문에 job의 Completions: 1 설정에 의해,
작업이 1회 성공적으로 완료되면 job이 종료된다
job의 pod가 수행할 모든 명령어를 완료하면
쿠버네티스는 job을 Succeeded로 표시하고,
pod 상태는 Completed로 변경된다
로그를 통해 설정된 명령어가 잘 실행되었는지 확인한다
확인 후 다음 실습을 위해 job 컨트롤러를 삭제한다
8. CronJob
- https://kubernetes.io/ko/docs/concepts/workloads/controllers/cron-jobs
크론잡
기능 상태: Kubernetes v1.21 [stable] 크론잡은 반복 일정에 따라 잡을 만든다. 하나의 크론잡 오브젝트는 크론탭 (크론 테이블) 파일의 한 줄과 같다. 크론잡은 잡을 크론 형식으로 쓰여진 주어진 일정
kubernetes.io
1) Cron 시간 및 요일 지정 방법
2) CrondJob yaml 파일 내용
| Job 파드 구성 | CronJob 파드 구성 |
| apiVersion: batch/v1 kind: Job metadata: name: job-test spec: template: spec: containers: - name: centos-container image: centos:7 command: ["bash"] args: - "-c" - "echo 'Hello World'; sleep 5" restartPolicy: Never |
apiVersion: batch/v1 kind: CronJob metadata: name: cronjob-test spec: schedule: "0 8 1 * *" jobTemplate: spec: template: spec: containers: - name: hello image: busybox args: - /bin/sh - -c - date; echo Hello Docker restartPolicy: Never |
3) CronJob 컨트롤러 구성
apiVersion: batch/v1
kind: CronJob
metadata:
name: cronjob-test
spec:
schedule: "* * * * *"
startingDeadlineSeconds: 500
concurrencyPolicy: Forbid
jobTemplate:
spec:
template:
spec:
containers:
- name: hello
image: busybox
args:
- /bin/sh
- -c
- echo Hello Docker; sleep 10; ls -l /tmp ; echo Bye Docker
restartPolicy: Never 
CronJob이 적용된 파드를 생성하기 위한
cronjob-test.yml 파일을 생성한다
cronjob-test.yml 파일을 이용하여 파드를 생성하고 확인한다
job은 10초 동안 실행되고 1분에 한 번씩 계속 반복적으로 실행될 것이다
cronjob-test-28739674-ckgvd Pod가
ContainerCreating, Running, Completed 상태로 변화하는 것을 볼 수 있다
이는 CronJob에 의해 주기적으로 생성되는 Job과
그에 따른 Pod들의 생애 주기를 나타낸다
각 Job은 일정 시간이 지나면 종료되고, 새로운 Job이 생성된다
예를 들어, cronjob-test-28739675-8zbrs가 75초 후에 종료되는 것을 볼 수 있다
describe를 통해 스케줄을 확인해 보면,
CronJob이 1분마다 실행된다는 것을 알 수 있다 (* * * * *는 매 분을 의미)
successfulJobsHistoryLimit 기본 값이 3으로 설정되어 있기 때문에
최근에 생성된 파드 3개만 유지하고 나머지 오래된 파드는 삭제한다
1분마다 cronjob이 실행되기 때문에
3~4분 뒤에 파드를 확인하면 새로운 파드 3개로 유지되고 있다
describe로 확인해도 3개의 파드로 유지되고 있는 걸 볼 수 있다
다음 실습을 위해 Cronjob 컨트롤러를 삭제한다
9. 컨트롤러 예제
다음과 같이 실습 디렉토리를 생성하고 이동한 이후, 예제를 풀어보세요.
# mkdir -p ~/kube/example && cd ~/kube/example
1) 다음 조건에 맞게 ReplicationController를 사용하는 'lab_rc.yml' 파일을 생성하고 동작시킨다.
lab_rc.yml 파일을 생성하여 ReplicationController(lab-rc)가
httpd:2.2 이미지를 가진 Pod 2개를 관리하도록 설정하고,
생성 후 kubectl scale 명령어를 통해 Pod 수를 3개로 확장한다
실습 완료 후 kubectl delete rc lab-rc로 삭제한다
2) 다음 조건에 맞게 ReplicasSet을 사용하는 'lab_rs.yml' 파일을 생성하고 동작시킨다.
lab_rs.yml 파일을 생성하여 ReplicaSet(lab-rs)이
httpd:2.2 이미지를 가진 Pod 2개를 관리하도록 설정하고,
생성 후 kubectl scale 명령어를 통해 Pod 수를 1개로 축소한다
실습 완료 후 kubectl delete rs lab-rs로 삭제한다
3) 다음 조건에 맞게 Deployment을 사용하는 'lab_deploy.yml' 파일을 생성하고 동작시킨다.
lab_deploy.yml 파일을 작성하여 httpd:2.2 이미지의
Deployment(lab-deploy)를 레이블과 주석과 함께 생성하고,
kubectl set image 명령어로 httpd:2.4로 롤링 업데이트한다
데이트 후 kubectl rollout history로 히스토리를 확인하고,
kubectl rollout undo를 통해 httpd:2.2 버전으로 롤백을 시도한다
실습이 끝나면 kubectl delete deployment lab-deploy로 Deployment를 삭제한다
08. Kubernetes 서비스
1. 서비스(Service)
- https://kubernetes.io/ko/docs/concepts/services-networking/service
서비스
외부와 접하는 단일 엔드포인트 뒤에 있는 클러스터에서 실행되는 애플리케이션을 노출시키며, 이는 워크로드가 여러 백엔드로 나뉘어 있는 경우에도 가능하다.
kubernetes.io
1) 파드 네트워크 대역
현재 실습 시스템의 CNI는 calico를 사용 중이다
그렇기 때문에 /etc/cni/net.d 디렉토리에 calico 설정 파일들을
확인하면 파드 네트워크 대역을 확인할 수 있다
CIDR은 파드에 할당되는 IP 범위다
2) 서비스 네트워크 대역
kubespray 통해 설치를 했기 때문에 k8s_cluster.yml 파일의 내용을 확인하면
파드 네트워크 대역 뿐만 아니라 서비스 네트워크 대역도 확인할 수 있다
3) 쿠버네티스 기본 서비스 이름 및 IP 주소 확인
4) 서비스 유형
서비스
외부와 접하는 단일 엔드포인트 뒤에 있는 클러스터에서 실행되는 애플리케이션을 노출시키며, 이는 워크로드가 여러 백엔드로 나뉘어 있는 경우에도 가능하다.
kubernetes.io
| 유형 | 내용 |
| ClusterIP | 기본 값이며, 파드 그룹의 단일 진입점(가상 IP 주소)을 수행한다 |
| ClusterIP | ClusterIP가 생성된 이후 모든 노드에 외부에서 접속 가능한 포트를 제공한다 |
| LoadBalancer | 로드 밸런서를 이용하여 각각의 파드로 로드 밸런싱하여 접근한다 |
| ExternalName | 클러스터 안에서 외부에 접속할 때, 사용할 도메인을 제공한다 |
| Headless | 단일 진입점(가상 IP 주소)이 필요 없는 환경에서 사용하는 서비스이다 |
2. ClusterIP
동일한 Label을 갖고 있는 파드 그룹에 대해서 단일 짂입점(가상 IP 주소)를 제공한다
만약, 서비스 유형을 설정하지 않으면 기본값으로 동작하며 IP 주소도
'10.233.0.0~10.233.63.255' 범위 내에서 자동으로 할당된다
1) ClusterIP 서비스 IP 자동 할당 구성
apiVersion: v1
kind: Service
metadata:
name: nginx-clusterip
spec:
selector:
app: webui
ports:
- protocol: TCP
port: 80
targetPort: 80
서비스를 생성하기 위한 cluster-test.yml 파일을 제작한다
clusterup-test.yml 파일을 이용하여 서비스를 생성하고,
서비스가 생성된 것을 확인 후 자동으로 할당된 ClusterIP 주소를 확인한다
master, node1 ~ node3에서 kube-ipvs0 장치에
clusterip-service의 ClusterIP 주소가 추가되었는지 확인한다
다음 실습을 위해 clusterip-service 서비스를 삭제한다
2) ClusterIP 서비스 고정 IP 구성
고정 ClusterIP를 설정하면 항상 동일한 ClusterIP 가상 IP 주소를
이용하여 각각의 파드로 접근할 수 있다
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deploy
spec:
replicas: 3
selector:
matchLabels:
app: webui
template:
metadata:
name: nginx-pod
labels:
app: webui
spec:
containers:
- name: nginx-container
image: nginx:1.14
디플로이먼트 컨트롤러를 이용하여 파드를 생성할
nginx-deploy.yml 파일을 생성한다
nginx-deploy.yml 파일을 이용하여 파드를 생성하고,
nginx-deploy 파드가 정상적으로 실행되는지 확인한다
apiVersion: v1
kind: Service
metadata:
name: nginx-clusterip
spec:
type: ClusterIP
clusterIP: 10.233.10.10
selector:
app: webui
ports:
- protocol: TCP
port: 80
targetPort: 80
이번에는 서비스를 생성하기 위한 nginx-clusterip.yml 파일을 제작한다
nginx-clusterip.yml 파일을 이용하여 서비스를 생성하고,
서비스가 잘 실행되고 있는지 고정으로 설정한 ClusterIP 주소를 확인한다
describe로 확인 시에도 셀렉터는 app=webui로 설정되어 있고,
IP와 포트 모두 알맞게 설정되어 있다
마지막으로 엔드 포인트 역시 서비스가 연결된 파드의 IP 주소와 포트를 나타내고 있다
현재 서비스와 파드의 상태 및 네트워크 정보를 확인할 수 있다
각각의 컨테이너의 웹 페이지를 구분할 수 있도록 다음과 같이 index.html 파일을 생성한다
다음으로는 master에서 curl을 이용하여
ClusterIP 10.233.10.10으로 HTTP 접속 테스트를 여러 번 실시한다
kubectl 명령어를 이용하여 파드 갯수를 5개로 증가시키고,
각 서비스와 파드, 엔드 포인트의 상태를 확인한다
새로 추가된 파드의 컨테이너 웹 페이지를 구분할 수 있도록
다음과 같이 index.html 파일을 생성한다
이번에도 역시 master에서 curl을 통해
ClusterIP 10.233.10.10으로 HTTP 접속 테스트를 여러 번 실행한다
예문과 같이 차례대로 변경되는 것을 확인할 수 있다
이번에는 파드 갯수를 3개로 변경하고 정보를 확인했을 때
엔드 포인트에는 변경 사항이 없는 것을 확인할 수 있다
nginx-deploy의 복제본 수를 3으로 늘렸지만,
이미 3개의 파드가 실행 중이었으므로 엔드 포인트에는 변화가 없다
이번에도 파드 갯수를 3개로 변경하였기 때문에
파드 갯수에 맞게 차례대로 변경되는 것을 확인할 수 있다
모두 확인했다면 다음 실습을 위해 nginx-clusterip 서비스를 삭제한다
3. NodePort
모든 노드를 대상으로 외부에서 접속이 가능한 포트를 예약하는 기능을 제공한다
1) NodePort 기본포트
노드포트는 '30000~32767'을 사용하고 있으며, ClusterIP가 설정된 이후 예약된다
ClusterIP 주소를 이용하지 않고 "노드 IP 주소:노드포트 번호" 형식으로 접근이 가능하다
2) NodePort 서비스 구성
apiVersion: v1
kind: Service
metadata:
name: nginx-nodeport
spec:
type: NodePort
clusterIP: 10.233.10.10
selector:
app: webui
ports:
- protocol: TCP
port: 80
targetPort: 80
nodePort: 30200
서비스를 생성하기 위한 nginx-nodeport.yml 파일을 생성한다
nginx-nodeport.yml 파일을 이용하여 서비스를 생성하고,
고정으로 설정한 ClusterIP 주소와 포트 번호를 확인한다
master에서 nmap을 실행하여 node1 ~ node3에 30200 포트가 열려 있는지 확인한다
master에서 각각의 node IP 주소:30200으로 curl을 통해 접속 테스트를 여러 번 실행한다
위의 예문과 같이 반복해서 실행되는 것을 확인할 수 있다
이번에는 ClusterIP 10.233.10.10으로 접속 테스트를 여러 번 진행한다
이 경우 역시 예문과 같이 차례대로 실행된다
마지막으로 서비스를 이용하지 않고
각각의 파드 IP 주소를 통해 접속 테스트를 진행한다
이번에는 각자에 해당하는 번호로 반복 실행 되는 것을 확인할 수 있다
실습을 마무리했다면 nginx-nodeport 서비스를 삭제하면서 마무리한다
강의 소감
이번 강의에서는 큰 틀로 보면
쿠버네티스 컨트롤러와 서비스에 대해 배우게 되었다
각각의 컨트롤러 설정 후 파드를 실행하는 것과,
서비스를 통해 설정한 값으로 웹 페이지 접속 테스트 등을 진행했다
하루에 여덟 시간이라는 긴 강의 시간에서
반복적인 예문과 연습을 통해서 쿠버네티스를 알아 가고 있다
출처 - 코리아it아카데미 김정우 강사님 제공
*중간에 나오는 교재의 단편적인 면이 아닌
MobaXterm으로 실행하여 캡처한 것은 모두 본인이 직접 실행해 보고
캡처하여 블로그에 작성하는 것입니다
'멀티 클라우드 인프라(DKR & K8S)' 카테고리의 다른 글
| 도커 & 쿠버네티스 5 (0) | 2024.11.02 |
|---|---|
| 도커 & 쿠버네티스 4 (0) | 2024.10.28 |
| 도커 & 쿠버네티스 3 (0) | 2024.10.28 |
| 도커 & 쿠버네티스 2 (2) | 2024.10.20 |
| 도커 & 쿠버네티스 1 (1) | 2024.10.20 |
