티스토리 뷰
<출처>
https://kubernetes.io/docs/tutorials/k8s101/
K8S 101에서는 kubectl, 파드, 볼륨 그리고 여러개의 파드들을 다룬다.
Objectives
- kubectl의 정의
- 파드 다루기
- 볼륨의 생성과 마운트
- 파드 내 여러 개의 컨테이너 생성하기
Before you begin
K8S 클러스터가 필요하며, 클러스터와 커뮤니케이션할 수 있도록 구성되어진 kubctl 커맨드-라인 툴도 필요하다. 아직 클러스터를 보유하지 않고 있다면, Minikube 를 이용하여 생성할 수 있으며, 또는 다음 두 개의 (웹 기반 대화형 가상 터미널 환경의) K8S 실습 도구를 이용할 수 있다.
버전 확인을 위해 kubectl version 을 수행한다..
수행 할 kubectl 용례 확인을 위해서는, 로컬에 예시 디렉토리가 있어야 하며, release 또는 여기에 있는 최신 .yaml 파일이 존재한다.
Kubectl CLI
K8S와 상호작용하는 가장 쉬운 방법은 kubectl 커맨드-라인 인터페이스를 이용하는 것이다.
용법, 명령어 그리고 파라미터에 대한 추가 정보는 Overview of kubectl을 참조한다.
kubectl 설치와 구성에 대한 추가 정보는 Install and Set Up kubectl을 참조한다.
Pods
K8S에서, 하나 또는 그 이상의 컨테이너 그룹을 파드라 부른다. 파드 내 컨테이너는 함께 배포되며 하나의 그룹으로서 구동, 중지, 그리고 복제된다.
보다 자세한 정보는, Pods를 참조한다.
Pod Definition
가장 단순한 형태의 파드 정의는 하나의 컨테이너에 대한 디플로이먼트를 설명해준다. 예를들어 nginx 웹서버 파드는 다음과 같이 정의될 수 있다.
pods/simple-pod.yaml
1 2 3 4 5 6 7 8 9 10 | apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - name: nginx image: nginx:1.7.9 ports: - containerPort: 80 | cs |
파드 정의는 의도한 상태 에 대한 선언이다. 의도한 상태란 K8S 모델에서 매우 중요한 개념이다. 많은 것들이 시스템에 대한 의도한 상태를 나타내고 K8S는 현재 상태가 의도한 상태와 일치되도록 보장해준다. 예를들어, 파드를 생성하여 파드 내 컨테이너들이 동작하도록 선언 할 때, 프로그램 실패로 컨테이너가 동작되지 못하는 경우, K8S는 파드가 의도한 상태에 이를 수 있도록 계속해서 파드를 (재)생성하게 된다. 이 프로세스는 파드가 삭제될 때까지 계속된다.
더 자세한 정보는 Kubernetes Design Documents and Proposals. 을 참조한다.
Pod Management
nginx 서버(simple-pod.yaml)를 포함하고 있는 파드를 생선한다.
1 2 | [root@docker-registry k8s]# kubectl create -f https://k8s.io/examples/pods/simple-pod.yaml pod/nginx created | cs |
모든 파드를 리스트 해본다.
1 2 3 | [root@docker-registry k8s]# kubectl get pods NAME READY STATUS RESTARTS AGE nginx 1/1 Running 0 16s | cs |
대부분의 제공사업자들이 제공하는 있는 네트워크 환경에서, 파드 IP는 외부에서 접근 불가하다. 파드가 동작하는지 테스트 해보는 가장 쉬운 방법은 busybox 파드 하나를 생성하여 외부에서 거기에 exec 명령을 수행해 보는 것이다. 보다 자세한 정보는 Get a Shell to a Running Container을 참조한다.
(먼저 다음 실습 과정에 필요한 nginx 파드의 IP 정보를 확인해 둔다.)
1 2 3 | [root@docker-registry ~]# kubectl get pods -o wide NAME READY STATUS RESTARTS AGE IP NODE nginx 1/1 Running 0 8m 10.48.15.3 gke-source-nat-test-clus-default-pool-f29ccdba-gn51 | cs |
파드의 IP로 접근이 가능하면, 80포트에 대한 wget을 이용하여 http 엔드포인트로 접근할 수 있다.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 | [root@docker-registry k8s]# kubectl run busybox --image=busybox --restart=Never --tty -i --generator=run-pod/v1 --env "POD_IP=$(kubectl get pod nginx -o go-template='{{.status.podIP}}')" If you don't see a command prompt, try pressing enter. / # wget -qO- 10.48.15.3 <!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> <style> body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; } </style> </head> <body> <h1>Welcome to nginx!</h1> <p>If you see this page, the nginx web server is successfully installed and working. Further configuration is required.</p> <p>For online documentation and support please refer to <a href="http://nginx.org/">nginx.org</a>.<br/> Commercial support is available at <a href="http://nginx.com/">nginx.com</a>.</p> <p><em>Thank you for using nginx.</em></p> </body> </html> / # exit [root@docker-registry k8s]# kubectl delete pod busybox pod "busybox" deleted | cs |
nginx 파드를 삭제하려면
1 2 | [root@docker-registry k8s]# kubectl delete pod nginx pod "nginx" deleted | cs |
Volumes
간단한 정적 웹서버를 위해서는 훌륭했지만, 지속성있는(persistent) 스토리지는 어떻게 해야 하나?
컨테이너 파일시스템은 컨테이너가 존재하는 동안만 유효하다. 그래서 재할당, 리뷰팅 그리고 크래쉬에 대해서도 앱의 상태를 보존시켜야 할 필요가 생긴다면, 지속성있는 스토리지 구성이 필요하다.
이번 예제에서 볼륨이라는 이름의 Redis를 생성해 볼 수 있다. 하나의 볼륨은 그 볼륨을 마운트한 경로를 정의하여 마운트한다.
1. 볼륨을 정의한다.
1 | volumes: - name: redis-storage emptyDir: {} | cs |
2. 컨테이너 정의 내에 볼륨 마운트를 정의한다.
1 2 3 4 5 | volumeMounts: # name must match the volume name defined in volumes - name: redis-storage # mount path within the container mountPath: /data/redis | cs |
다음은 지속성 있는 스토리지 볼륨을 갖는 Redis 파드 정의의 예시이다. (redis.yaml):
pods/storage/redis.yaml
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | 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: {} | cs |
위 내용에서
- "volumeMountsname"은 특정 "volumesname"을 언급한다.
- "volumeMounts mountPath"는 컨테이너 내 마운트한 볼륨의 경로를 나타낸다.
Volume Types
EmptyDir: 노드 상에서 파드가 동작하고 있는 동안만 존재하는 새로운 디렉토리를 생성한다. 그러나 컨테이너 실패와 재구동을 통해 지속 시킬 수 있다.
HostPath: 노드의 파일시스템 상에 존재하는 디렉토리를 마운트 한다. 예를들어 (/var/logs).
더 자세한 정보는, Volumes을 참조한다.
Multiple Containers
주의: 아래 예시가 구문상으로 맞지만, 아직 몇몇 이미지(e.g. kubernetes/git-monitor)가 존재하지 않는다. 이를 (정상) 동작하는 예제가 되도록 조치하고 있다.
종종 함께 동작하는 서로 다른 두 개의 컨테이너를 원할 경우가 있다. 이번에는 하나의 웹 서버, 그리고 git 레파지토리에 새로운 업데이트 여부를 확인하는 일을 수행하는 보조에 대한 예시가 된다.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | apiVersion: v1 kind: Pod metadata: name: www spec: containers: - name: nginx image: nginx volumeMounts: - mountPath: /srv/www name: www-data readOnly: true - name: git-monitor image: kubernetes/git-monitor env: - name: GIT_REPO value: http://github.com/some/repo.git volumeMounts: - mountPath: /data name: www-data volumes: - name: www-data emptyDir: {} | cs |
이번에도 하나의 볼륨이 추가되었음을 주의한다. 이번 경우에는, 볼륨이 두 개의 컨테이너 안에 마운트 되었다. 웹 서버의 경우에는 디렉토리 에 쓰기가 불필요하므로 "readOnly" 로 표기되었다.
끝으로, git-monitor 컨테이너에 환경변수도 소개했다. 이는 우리가 트래킹하고자 하는 특정 git 레파지토리 정보를 갖는 컨테이너를 파라미터화 하도록 허용해준다.
What's next
Kubernetes 201 로 이어가거나 완성된 애플리케이션을 보려면 guestbook example 을 참조한다.
'Kubernetes' 카테고리의 다른 글
| 26 GCP와 Ansible을 활용한 쿠버네티스 클러스터 한방에 구성하기 1편 (0) | 2019.03.28 |
|---|---|
| 25 Kubernetes 201 (2) | 2018.09.27 |
| 23 Services - Using Source IP (0) | 2018.09.27 |
| 22 Clusters - AppAmor (0) | 2018.09.27 |
| 21 CI/CD Pipeline - Set Up CI/CD for a Distributed Crossword Puzzle App on Kubernetes (Part 4) (0) | 2018.09.11 |