시골쥐의 공부생활

Docker-compose 배경 설명

일반적으로 prometheus나 Grafana를 설치한다고 하면, docker full로 이미지를 땡겨와서 설치하는 게 주된 방법이다.

하지만, container가 다수 개가 될 경우 관리가 어려워진다.

그래서, Docker-compose를 통해 하나의 docker-compose.yml로 여러 개의 컨테이너를 동시에 생성/관리/삭제할 수 있다.

나는 Docker-compose를 통해 Prometheus + Grafana를 실행할 예정으로, 아래와 같이 Docker.compose.yml를 작성했다.

크게 보면, prometheus와 grafana간 통신 가능하도록 하나의 networks를 구성해서 묶어주었고 (networks: monitor),

컨테이너의 /etc/prometheus/ 파일들을 volumes으로 로컬 /home/monitor/prometheus/ 로 마운트 시켜주었다.

그리고, prometheus.yml를 작성한다. 

최소 동작을 위해 필요한 설정들은 딱히 많지 않다. targets만 적어주면 된다 (=exporter가 설치된 노드 ip)

이제 준비해야할 파일은 끝났다. docker-compose를 실행해보자.

docker-compose up // 컨테이너 및 network 생성 및 실행

[ec2-user@ monitor]$ sudo docker-compose up -d         // d: background에서 실행

Creating network "monitor_monitor" with driver "bridge"

Creating prometheus ... done

Creating grafana    ... done

[ec2-user@ monitor]$ 

[ec2-user@ monitor]$ sudo docker ps          

CONTAINER ID   IMAGE                    COMMAND                  CREATED         STATUS         PORTS                                       NAMES

34c0e6778103   grafana/grafana:latest   "/run.sh"                3 minutes ago   Up 3 minutes   0.0.0.0:3000->3000/tcp, :::3000->3000/tcp   grafana

85878fe66a18   prom/prometheus:latest   "/bin/prometheus --c…"   3 minutes ago   Up 3 minutes   0.0.0.0:9090->9090/tcp, :::9090->9090/tcp   prometheus

포트포워딩으로 웹 접속이 가능한지 확인

$ ssh -i [인증서].pem -p [local port] ec2-user@[ec2 public IP] -L 9090:[Prometheus가 떠 있는 ec2]:9090

$ ssh -i [인증서].pem -p [local port] ec2-user@[ec2 public IP]  -L 3000:[Grafana가 떠 있는 ec2]:3000

1. Prometheus: localhost:9090/

2. Grafana: localhost:3000/

+ 포트 포워딩은 아니지만 curl을 통해 node exporter가 설치된 node 확인.

+ node exporter의 metrics 확인

완료.

여기서 prometheus를 data source로 가져와보자.

URL은 prometheus의 dns name인 prometheus를 가져오고, port를 지정해주면 된다.

(localhost는 안된다. 서로 다른 컨테이너니까.)

그리고 grafana Labs에 있는 dashboard를 하나 import 해보자. URl을 그대로 복붙해도 된다.

https://grafana.com/grafana/dashboards/15172

그렇게 하면 이런 대시보드가 생성되어 prometheus로부터 받는 데이터를 예쁘게 보여준다.

docker-compose로 한 번에 생성시킨 컨테이너들을 중단하는 방법은,

docker-compose down // 컨테이너 및 network 정지 및 삭제

* docker-compose down는 컨테이너만 정지시킨다.

[ec2-user@ip- monitor]$ sudo docker-compose down

Removing grafana    ... done

Removing prometheus ... done

Removing network monitor_monitor

[ec2-user@ip- monitor]$ 

[ec2-user@ip- monitor]$ sudo docker ps

CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES

[ec2-user@ip- monitor]$ 

#docker 명령어 모음

https://www.daleseo.com/dockerfile/     // 다커 명령어 모음

# docker pull // docker-hub로부터 컨테이너 생성을 위한 이미지 가져오기

[ec2-user@ip-xxxx nodejs]$ docker pull python:3.9-slim

3.9-slim: Pulling from library/python

214ca5fb9032: Pull complete 

fa7d81b69b9a: Pull complete 

96a5a0a62ab5: Pull complete 

7d3628511179: Pull complete 

ea3879bc1c47: Pull complete 

Digest: sha256:364ada4cb4f943b603d330cbb3d26f689c8b54de51cb12bad1202de7dba31814

Status: Downloaded newer image for python:3.9-slim

docker.io/library/python:3.9-slim

// docker pull을 하면 하나의 파일이 다운되지 않고 여러 파일이 다운로드 된다.

docker는 레이어(layer)라는 것으로 이미지가 여러 개의 레이어가 되어있는데, 이게 다운로드 되는 것이다.

받아진 이미지를 분석해보고 싶다면 "docker inspect python:3.9-slim" 를 입력하면이 이미지 구성을 볼 수 있다.

[ec2-user@ip-xxxx nodejs]$ docker images

REPOSITORY   TAG        IMAGE ID       CREATED      SIZE

python       3.9-slim   29cc46b21611   5 days ago   125MB

[ec2-user@ip-xxxx nodejs]$ docker run -it --name=jane_python python:3.9-slim /bin/bash

root@c0b5a0c315fb:/# ls

bin  boot  dev etc  home  lib lib64  media  mnt  opt proc  root  run  sbin  srv  sys  tmp  usr  var

#docker_image삭제  // 삭제가 안될 때가 있음. 그럴 땐 container 확인

[ec2-user@ip-xxxx nodejs]$ docker rmi $(docker images -q). 

Error response from daemon: conflict: unable to delete 29cc46b21611 (must be forced) - image is being used by stopped container 7fabb7cdfd7a

#docker_container_조회

[ec2-user@ip-xxxx nodejs]$ docker container ls -a

CONTAINER ID   IMAGE             COMMAND     CREATED         STATUS                     PORTS     NAMES

7fabb7cdfd7a   python:3.9-slim   "python3"   4 minutes ago   Exited (0) 4 minutes ago             jane-test

#docker_container_삭제

[ec2-user@ip-xxxx nodejs]$ docker container rm 7fabb7cdfd7a 

7fabb7cdfd7a

[ec2-user@ip-xxxx nodejs]$ docker rmi 29cc46b21611

Untagged: python:3.9-slim

Untagged: python@sha256:364ada4cb4f943b603d330cbb3d26f689c8b54de51cb12bad1202de7dba31814

Deleted: sha256:29cc46b21611795a55a23f40290d9af983162d3d0a2cf4a11ab109a6c3183e06

#Dockerfile

[ec2-user@ip-xxxx nodejs]$ cat Dockerfile

FROM python:3.9-slim

WORKDIR /usr/src/app     // python 안에 있는 directory 

COPY . .

CMD ["test.py"]

[ec2-user@ip-xxxx nodejs]$ docker images

REPOSITORY   TAG       IMAGE ID   CREATED   SIZE

#docker_build

[ec2-user@ip-xxxx nodejs]$ docker build --tag jane-test .

Sending build context to Docker daemon  3.072kB

Step 1/4 : FROM python:3.9-slim

3.9-slim: Pulling from library/python

[root@ip-192-168-23-47 jane-test]# 

[ec2-user@ip-xxxx nodejs]$ docker images

REPOSITORY    TAG        IMAGE ID       CREATED         SIZE

jane-test   latest     7639b54570bf   2 seconds ago   125MB

python        3.9-slim   29cc46b21611   5 days ago      125MB

#docker_run

[ec2-user@ip-xxxx nodejs]$ docker run -it --name jane-test jane-test:latest

Hello World!

#docker_mount // Bind mounts를 이용해 호스트 파일 or 디렉토리를 컨테이너에 붙여 사용하기

[ec2-user@ip-xxxx nodejs]$ docker run -itd --name jane-test --mount type=bind,source="$(pwd)"/mount,target=/app ubuntu:18.04

Status: Downloaded newer image for ubuntu:18.04

d5c20934eb0f6a72286c24c5a092876bdd5064b84e5434031e29dc68a6657460

[ec2-user@ip-xxxx nodejs]$ docker ps

CONTAINER ID   IMAGE          COMMAND   CREATED         STATUS         PORTS     NAMES

d5c20934eb0f   ubuntu:18.04   "bash"    7 seconds ago   Up 6 seconds             jane-test

# 내부 디렉토리에 있는 게 컨테이너(위에서 target으로 삼은 경로)에도 동일하게 보임

[ec2-user@ip-xxxx nodejs]$ pwd

/home/ec2-user/jane-test/nodejs/mount

[ec2-user@ip-xxxx nodejs]$ ls

test.txt

[ec2-user@ip-xxxx nodejs]$ sudo docker exec -it jane-test ls /app

test.txt

Note) python 버전별 차이 (3.9-slim, buster …)

https://medium.com/swlh/alpine-slim-stretch-buster-jessie-bullseye-bookworm-what-are-the-differences-in-docker-62171ed4531d

몇 달전 Prometheus를 설치했었다.

그런데 오랜만에 사용하려고 보니, ImagePullBackOff가 떠있는 것이다.

한 pod를 describe로 조회해보니 image가 없다고 한다.

그래서 image를 다른 registry에서 가져오고, deployment에서 image에 맞는 tag값까지 수정해줬다.

(관련 포스팅은  https://countrymouse.tistory.com/entry/docker  )

그런데, 맨 밑 pod(prometheus-jane-prometheus-kube-promet-prometheus)는 deployment가 아닌 statefulset이였다.

그래서 이 또한 수정을 했는데,

노답. 수정하자마자 기존 image tag로 값이 원복되는 것이다.

그래서 pod가 안 산다.

해결책

결국 해결책은, cr(custom resource)에서 직접 tag값을 수정하는 것이었다.

1. statfulset owner 확인: Prometheus, dso-prometheus-kube-promet-prometheus

2. cr 수정 : 이미지 tag 변경
# kubectl edit Prometheus  -n jane-infra-monitoring

업무 중에 Prometheus 구동을 위한 이미지가 삭제되어 다시 불러오는 과정이 있었다.

정리해두면 유용할 것 같아 아래와 같이 정리했다 :)

1. 이미지 불러오기: docker pull (from harbor)
# docker pull harbor.jane.net/dependency/quay.io/prometheus/prometheus:v2.22.1


2. 이미지 저장(다운받은 image를 tar파일로 추출): docker save 
# docker save -o [파일명].tar [image id] // image id는 docker image list로 조회 (ex. 7cc97b58fb0e)

controller-0:~# docker image list | grep v2.22.1
harbor.jane.net/dependency/quay.io/prometheus/prometheus                                         v2.22.1                7cc97b58fb0e        17 months ago       168MB


3. 이미지 넣기: docker load 
# docker load -i [파일명.tar]


4. 넣은 image를 내부 registry로 변경(기존 prometheus의 cr에 image주소가 내부 registry라서 진행): docker tag 
# docker tag harbor.jane.net/dependency/quay.io/prometheus/prometheus:v2.22.1 registry.infra.jane.cluster.local:19092/quay.io/prometheus/prometheus:v2.22.1


5. tag가 변경된 image를 서버로 넣기: docker push 
# docker push registry.infra.jane.cluster.local:19092/quay.io/prometheus/prometheus:v2.28.1
The push refers to repository [registry.infra.jane.cluster.local:19092/dependency/kube-state-metrics/kube-state-metrics]
a7b3323785fe: Pushed
07363fa84210: Pushed
v2.2.0: digest: sha256:8008b06ed82e8517add62ae9a7893518244890de6efa6517adf45a6dd54eae2d size: 739


6. curl로 push 여부 확인
controller-0:~# curl -u jane:jane_pwd  https://registry.infra.jane.cluster.local:19092/v2/dependency/kube-state-metrics/kube-state-metrics/tags/list  -k
{"name":"dependency/kube-state-metrics/kube-state-metrics","tags":["v2.2.0"]}

강의가 거의 끝나고, Troubleshooting 섹션이 시작됐다.

크게 아래와 같이 4개의 Failure를 다루는데 하나씩 정리해보겠다.

- Application Failure

- Worker Node Failure

- Control Plain Failure

- Networking

1. Application Failure

먼저, 문제가 발생했을 경우엔 오른쪽과 같이 architecture를 알아야 한다.

어떤 pod와 어떤 service로 구성되어 있는지 말이다. 

그래서 FrontEnd부터 (그림에서는 WEB-Service) 천천히 내려가보는 것이다.

그래서 왼쪽과 같이 curl http://web-service.ip:node-port를 를 통해 해당 service가 문제없는지 확인해볼 수 있고,

이후엔 describe를 통해 web-service의 상태 및 config값을 조회할 수 있다.

여기서는 web pod와 연결되기 위해 Selector가 초록으로 마킹되어 있는데, 이게 pod와 맞는지 확인하는 것도 잊지 말아야한다.

서비스에 이상이 없다면, 이제 pod로 넘어간다.

kubectl get pod를 통해 pod상태를 조회하고, describe로 상세 상태를 보고, logs를 통해서도 문제를 확인할 수 있다.

여기서 -f, --previous 옵션을 붙이면 이전 pod의 상태에 대해서도 확인할 수 있다.

#kubectl logs [pod] -f --previous

여기서도 문제가 없다면, 이제 DB-Service / DB로 내려간다.

이론 설명 후 Practice 강의가 있었는데 대부분은 Selector, DB ID/PW(Root pw까지도), NodePort, Target Endpoint port error(Target Port), ep(endpoint) 문제이다.

ep는 여기서 처음 들어봤는데 # kubectl get po -n [namespace] ep를 통해 조회할 수 있고,

service가 selector를 통해 쳐다보고 있는 Endpoint(pod)를 보여준다. 

2. Control Plain Failure

1) Node, pods상태, kube-system에 속한 controlplain pods상태를 확인한다.

  # kubectl get nodes 

  # kubectl get pods

  # kubectl get pods -n kube-system

만약 Controlplain 컴포넌트들이 service 형태라면, service를 위와 같이 조회할 수 있다.

# service kube-apiserver status

# service kube-controller-manager status

# service kube-scheduler status

service logs를 통해서도 문제를 확인 가능하다.

kube-apiserver의 경우 journalctl를 사용한다.

# kubectl log kube-apiserver-master -n kube-system

# sudo journalctl -u kube-apiserver

Practice test에서는 아래와 같은 내용을 다룬다.

1) pod 한 개가 pending 상태. 근데 pod엔 문제가 없어보임.

 -> scheduler issue일 수 있음.

# kubectl get po -n kube-system

  // 를 통해 scheduler가 Crashloopbackoff 상태인 것을 확인.

그래서, scheduler를 describe하여 조회한 결과, 'failed to start container "kube-scheduler": Error response from daemon: OCI runtime create failed: container_linux.go:345: starting containre process caused "Exec: \"kube-schedulerrrr\": executable file not found in $PATH: unknown" error가 존재하였음.

=> kube-scheduler-master yaml파일에 가서 수정한다. 

# cat /etc/systemd/system/kubelet.service.d/10-kubeadm.conf   

   // kubectl config.yaml 경로 조회 가능 (/var/lib/kubelet/config.yaml)

# grep -i staticPodPath /var/lib/kubelet/config.yaml

  : staticPodPath: /etc/kubernetes/manifest // default path

# cd /etc/kubernets/manifests/

# vi kube/scheduler.yaml

 여기서 spec: containers:의 command에 'kube-schedulerrrr'가 있다. 이걸 정상 값(kube-scheduler)으로 수정해준다.

2) deployment를 통해 pod를 2개로 scale 

 # kubectl scale deployment app --replicas=2 // 그런데 scale이 되지 않음! 그래서 tshoot 진행.

 # kubelet get pods -n kube-system // replica를 담당하는 kubec-controller-manager이 역시나 Crashloopbackoff 상태.

 # kubectl -n kube-system describe kube-controller-manager 조회 // 문제 없음

 # kubectl -n kube-system logs kube-controller-manager-master 

  // 'stat /etc/kubernetes/controller-manager-xxxx.conf: no such file or directory' 출력

# cd /etc/kubernetes 가보니 controller-manager 파일이 있음. (-xxxx.conf 가 아님)

 # vi /etc/kubernetes/manifests/kube-controller-manager.yaml 파일 조회

  // spec: containers: command에 있는 kueconfig=/etc/kuberenets/controller-manager-xxxx.conf 파일 수정

이후 deployment 및 controller가 정상 동작되고 replica도 정상 동작하는 것을 확인했다.

3) controller-manager의 re-broken

 # kubectl get pods -n kube-system // kube-controller-manager-matser = Crashloopbackoff

 # kubectl describe po kube-controller-manager-master -n kube-system // 이슈 없어보임

 # kubectl logs kube-controller-manager-matser -n kube-sysetm 

  // 'unable to load client CA file: unable to load client CA file: open /etc/kuberenetes/pki/ca.crt: no such file or directory' 라는 에러 존재

# vi /etc/kubernetes/manifest/kube-controller-manager.yaml 확인 

  // ca.crt를 쓰고 있는 부분 확인. mountpath가 /etc/kubernetes/pki를 가지고 있는 것의 name이 'k8s-certs'임.

이걸로 다시 파일 내 조회. 그리고 그것들의 path 확인. WRONG-PKI-DIRECTORY가 있음.

 # cd /etc/kubernetes/WRONG-PKI-DIRECTORY/ 

  // 직접 해당 디렉토리 내 ca.crt가 있는지 확인. 그런데 파일이 없음.

 # cd /etc/kubernetes/pki/

  // 여기에 key값들 있는 걸 확인

# vi /etc/kubernetes/manifest/kube-controller-manager.yaml 확인 

  // k8s-cert를 쓰고 있는 path를 확인. hostPath가 /etc/kubernetes/WRONG-PKI-DIRECTORY로 설정되어 있음.

     이걸 /etc/kubernetes/pki로 변경

3. Worker Node Failure

Worker node가 문제있을 땐 node 상태 및 kubelet, Certificates (만료 여부 등)를 확인해볼 필요가 있다. 

- Practice에서는 kubelet과 kube-proxy에 대해 다룬다.

1. node 01 Not ready  with kubelet

1) kubelet get nodes를 조회했더니, node01이 Not Ready 상태이다.

2) ssh node01로 들어간다.

3) ps -ef | grep kubelet  // kubelet이 running중이 아니었다.

4) systemctl status kubelet.service // inactive 확인

5) systemctl restart kubelet // active가 되었다.

6) kubelet get nodes // node01이 ready 상태로 변했다.

2. Node 01 Not Ready with kubelet

1) kubelet get node // node01 = not ready

2) kubectl describe node node01 // 별다른 게 없다.

3) ssh node01

4) sytsemctl status kubelet.service -l // activating 상태

5) journalctl -u kubelet // kube-proxy log 조회

  'open /etc/kubernetes/pki/WRONG-CA-FILE.crt: no such file or directory 확인

6) cd /etc/systemd/system/kubelet.service.d/    // kubelet config 조회. 10-kubeadm.conf가 존재

7) cat 10-kubeadm.conf // Environment=KUBELET_CONFIG_ARGS 및 KUBELET_KUBECONFIG_ARGS 존재

 // KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml 조회

8) vi /var/lib/kubelet/config.yaml

9) /pki/WRONG-CA-FILE.crt 존재, 이부분 수정

10) cd /etc/kubernetes/

11) ls 조회 시 pki/ 및 kubelet.conf뿐.

pki/에 들어가보니 ca.crt가 있음. 즉, 경로는 /etc/kubernetes/pki/ca.crt가 되어야 함.

12) vi /var/lib/kubelet/config.yaml에서 /etc/kubernetes/pki/WRONG-CA-FILE.crt -> /etc/kubernetes/pki/ca.crt로 변경

13) systemctl daemon-reload

14) systemctl restart kubelet

15) kubelet은 active상태가 되었고 node는 ready 상태가 되었다.

3.  Node01 Not Ready with kubelet

1) kubelet describe node node01 // 도움되는 정보 없음

2) ssh node01

3) sytsemctl status kubelet // active & running, but error exist

  'dial tcp 172.17.0.22:6553: connect: conenction refused'

4) journalctl -u kubelet // kube-proxy log 조회, 동일한 err 존재

5) kubelet cluster-info // master node에서 master ip 및 port 확인 (172.17.0.22:6443)

6) ssh node01 

7) cd /etc/systemd/system/kubelet.service.d/    // kubelet config 조회. 10-kubeadm.conf가 존재

8) cat 10-kubeadm.conf // kubeconfig=/etc/kubernetes/kubelet.conf 확인

9) vi /etc/kubernetes/kubelet.conf // server section에서 port 변경 ( 6553-> 6443) 

10) system daemon-reload

11) system restart kubelet

12) kubelet은 active 및 error가 존재하지 않으며 node또한 ready 상태가 됨.

출처: Udemy 사이트의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의

이전에 LVM 포스팅을 했었는데, 이를 K8s에서 적용해보자.

* 이전포스팅: https://countrymouse.tistory.com/entry/lvm

해당 과정은 파일시스템 부족으로 인한 현상을 해소하기 위해 진행한다.

1. partition 추가

controller-0:~$ source /etc/platform/openrc
[sysadmin@controller-0 ~(keystone_admin)]$ system host-disk-partition-add -t lvm_phys_vol controller-0 /dev/sda 100
+-------------+-------------------------------------------------------+
| Property    | Value                                                 |
+-------------+-------------------------------------------------------+
| device_path | /dev/disk/by-path/pci-0000:1a:00.0-scsi-0:2:0:0-part8 |
| device_node | /dev/sda8                                             |
| type_guid   | ba5eba11-0000-1111-2222-000000000001                  |
| type_name   | None                                                  |
| start_mib   | None                                                  |
| end_mib     | None                                                  |
| size_mib    | 102400                                                |
| uuid        | 63420173-2fed-44d5-ac8e-3b62a482dbc9                  |
| ihost_uuid  | 885f5f39-849e-4e6b-9033-273a2af54385                  |
| idisk_uuid  | a7161ee5-9e84-4d6e-99b6-b5201683afc3                  |
| ipv_uuid    | None                                                  |
| status      | Creating                                              |
| created_at  | 2021-10-26T10:50:18.074885+00:00                      |
| updated_at  | None                                                  |
+-------------+-------------------------------------------------------+

sysadmin@controller-0 ~(keystone_admin)]$ system host-disk-partition-add -t lvm_phys_vol controller-1 /dev/sda 100
+-------------+-------------------------------------------------------+
| Property    | Value                                                 |
+-------------+-------------------------------------------------------+
| device_path | /dev/disk/by-path/pci-0000:1a:00.0-scsi-0:2:0:0-part8 |
| device_node | /dev/sda8                                             |
| type_guid   | ba5eba11-0000-1111-2222-000000000001                  |
| type_name   | None                                                  |
| start_mib   | None                                                  |
| end_mib     | None                                                  |
| size_mib    | 102400                                                |
| uuid        | d6e99a18-0c33-4641-a5d2-2c544487f29a                  |
| ihost_uuid  | 9ea6efdb-87d5-407b-abd6-f6af36f2a8be                  |
| idisk_uuid  | 52d09ff1-1811-4e72-9aa5-b0da4f75f001                  |
| ipv_uuid    | None                                                  |
| status      | Creating                                              |
| created_at  | 2021-10-26T10:53:42.111798+00:00                      |
| updated_at  | None                                                  |
+-------------+-------------------------------------------------------+

2. 추가된 partition의 uuid 확인

[sysadmin@controller-0 ~(keystone_admin)]$ system host-disk-partition-list controller-0
+--------------------------------------+-------------------------------------------------------+-------------+--------------------------------------+---------------------+----------+--------+
| uuid                                 | device_path                                           | device_node | type_guid                            | type_name           | size_gib | status |
+--------------------------------------+-------------------------------------------------------+-------------+--------------------------------------+---------------------+----------+--------+
| 63420173-2fed-44d5-ac8e-3b62a482dbc9 | /dev/disk/by-path/pci-0000:1a:00.0-scsi-0:2:0:0-part8 | /dev/sda8   | ba5eba11-0000-1111-2222-000000000001 | LVM Physical Volume | 100.0    | Ready  |
+--------------------------------------+-------------------------------------------------------+-------------+--------------------------------------+---------------------+----------+--------+
[sysadmin@controller-0 ~(keystone_admin)]$ system host-disk-partition-list controller-1
+--------------------------------------+-------------------------------------------------------+-------------+--------------------------------------+-----------+----------+----------+
| uuid                                 | device_path                                           | device_node | type_guid                            | type_name | size_gib | status   |
+--------------------------------------+-------------------------------------------------------+-------------+--------------------------------------+-----------+----------+----------+
| d6e99a18-0c33-4641-a5d2-2c544487f29a | /dev/disk/by-path/pci-0000:1a:00.0-scsi-0:2:0:0-part8 | /dev/sda8   | ba5eba11-0000-1111-2222-000000000001 | None      | 100.0    | Creating |
+--------------------------------------+-------------------------------------------------------+-------------+--------------------------------------+-----------+----------+----------+

3. 물리 볼륨(PV) 생성 및 볼륨그룹(VG)에 추가

[sysadmin@controller-0 ~(keystone_admin)]$ system host-pv-add controller-0 cgts-vg 63420173-2fed-44d5-ac8e-3b62a482dbc9
+--------------------------+-------------------------------------------------------+
| Property                 | Value                                                 |
+--------------------------+-------------------------------------------------------+
| uuid                     | fc6a243e-7bfc-4ae0-98d6-4677da33e9eb                  |
| pv_state                 | adding                                                |
| pv_type                  | partition                                             |
| disk_or_part_uuid        | 63420173-2fed-44d5-ac8e-3b62a482dbc9                  |
| disk_or_part_device_node | /dev/sda8                                             |
| disk_or_part_device_path | /dev/disk/by-path/pci-0000:1a:00.0-scsi-0:2:0:0-part8 |
| lvm_pv_name              | /dev/sda8                                             |
| lvm_vg_name              | cgts-vg                                               |
| lvm_pv_uuid              | None                                                  |
| lvm_pv_size_gib          | 0.0                                                   |
| lvm_pe_total             | 0                                                     |
| lvm_pe_alloced           | 0                                                     |
| ihost_uuid               | 885f5f39-849e-4e6b-9033-273a2af54385                  |
| created_at               | 2021-10-26T10:54:28.910208+00:00                      |
| updated_at               | None                                                  |
+--------------------------+-------------------------------------------------------+

[sysadmin@controller-0 ~(keystone_admin)]$ system host-pv-add controller-1 cgts-vg d6e99a18-0c33-4641-a5d2-2c544487f29a
+--------------------------+-------------------------------------------------------+
| Property                 | Value                                                 |
+--------------------------+-------------------------------------------------------+
| uuid                     | e8464fe1-a7d6-4957-b055-c57a4c1cce5b                  |
| pv_state                 | adding                                                |
| pv_type                  | partition                                             |
| disk_or_part_uuid        | d6e99a18-0c33-4641-a5d2-2c544487f29a                  |
| disk_or_part_device_node | /dev/sda8                                             |
| disk_or_part_device_path | /dev/disk/by-path/pci-0000:1a:00.0-scsi-0:2:0:0-part8 |
| lvm_pv_name              | /dev/sda8                                             |
| lvm_vg_name              | cgts-vg                                               |
| lvm_pv_uuid              | None                                                  |
| lvm_pv_size_gib          | 0.0                                                   |
| lvm_pe_total             | 0                                                     |
| lvm_pe_alloced           | 0                                                     |
| ihost_uuid               | 9ea6efdb-87d5-407b-abd6-f6af36f2a8be                  |
| created_at               | 2021-10-26T10:56:00.562599+00:00                      |
| updated_at               | None                                                  |
+--------------------------+-------------------------------------------------------+

4. PV 생성여부 확인 

[sysadmin@controller-0 ~(keystone_admin)]$ system host-disk-partition-list controller-0
+--------------------------------------+-------------------------------------------------------+-------------+--------------------------------------+---------------------+----------+--------+
| uuid                                 | device_path                                           | device_node | type_guid                            | type_name           | size_gib | status |
+--------------------------------------+-------------------------------------------------------+-------------+--------------------------------------+---------------------+----------+--------+
| 63420173-2fed-44d5-ac8e-3b62a482dbc9 | /dev/disk/by-path/pci-0000:1a:00.0-scsi-0:2:0:0-part8 | /dev/sda8   | ba5eba11-0000-1111-2222-000000000001 | LVM Physical Volume | 100.0    | Ready  |
+--------------------------------------+-------------------------------------------------------+-------------+--------------------------------------+---------------------+----------+--------+
[sysadmin@controller-0 ~(keystone_admin)]$ system host-disk-partition-list controller-1
+--------------------------------------+-------------------------------------------------------+-------------+--------------------------------------+-----------+----------+----------+
| uuid                                 | device_path                                           | device_node | type_guid                            | type_name | size_gib | status   |
+--------------------------------------+-------------------------------------------------------+-------------+--------------------------------------+-----------+----------+----------+
| d6e99a18-0c33-4641-a5d2-2c544487f29a | /dev/disk/by-path/pci-0000:1a:00.0-scsi-0:2:0:0-part8 | /dev/sda8   | ba5eba11-0000-1111-2222-000000000001 | None      | 100.0    | Creating |
+--------------------------------------+-------------------------------------------------------+-------------+--------------------------------------+-----------+----------+----------+

5. Filesystem size 수정

[sysadmin@controller-0 ~(keystone_admin)]$ system host-fs-modify controller-0 docker=100
+--------------------------------------+---------+-------------+----------------+
| UUID                                 | FS Name | Size in GiB | Logical Volume |
+--------------------------------------+---------+-------------+----------------+
| 6a5114e8-3d69-47cb-8e92-cef7416a2b35 | backup  | 25          | backup-lv      |
| d5295e55-8983-4c39-a309-10ae957e09d9 | docker  | 100         | docker-lv      |
| 137933c6-38b5-40c8-876f-a786b2ca63fd | kubelet | 15          | kubelet-lv     |
| 1dc26b13-fd96-4974-b3b2-68af0d60a842 | scratch | 16          | scratch-lv     |
+--------------------------------------+---------+-------------+----------------+
[sysadmin@controller-0 ~(keystone_admin)]$ system host-fs-modify controller-0 kubelet=100
+--------------------------------------+---------+-------------+----------------+
| UUID                                 | FS Name | Size in GiB | Logical Volume |
+--------------------------------------+---------+-------------+----------------+
| 6a5114e8-3d69-47cb-8e92-cef7416a2b35 | backup  | 25          | backup-lv      |
| d5295e55-8983-4c39-a309-10ae957e09d9 | docker  | 100         | docker-lv      |
| 137933c6-38b5-40c8-876f-a786b2ca63fd | kubelet | 100         | kubelet-lv     |
| 1dc26b13-fd96-4974-b3b2-68af0d60a842 | scratch | 16          | scratch-lv     |
+--------------------------------------+---------+-------------+----------------+

[sysadmin@controller-0 ~(keystone_admin)]$ system host-fs-modify controller-1 docker=100
+--------------------------------------+---------+-------------+----------------+
| UUID                                 | FS Name | Size in GiB | Logical Volume |
+--------------------------------------+---------+-------------+----------------+
| 0e539999-7bf0-4d93-bd6e-ab8e16fbfd96 | backup  | 25          | backup-lv      |
| 1eb15c7d-9fa2-4973-980e-1b410df62346 | docker  | 100         | docker-lv      |
| 0bc4452d-7ef8-4766-b183-cd555cee5920 | kubelet | 10          | kubelet-lv     |
| 6aa1e91d-a4d0-4c58-ab9d-0a8fb0e80f76 | scratch | 16          | scratch-lv     |
+--------------------------------------+---------+-------------+----------------+
[sysadmin@controller-0 ~(keystone_admin)]$ system host-fs-modify controller-1 kubelet=100
+--------------------------------------+---------+-------------+----------------+
| UUID                                 | FS Name | Size in GiB | Logical Volume |
+--------------------------------------+---------+-------------+----------------+
| 0e539999-7bf0-4d93-bd6e-ab8e16fbfd96 | backup  | 25          | backup-lv      |
| 1eb15c7d-9fa2-4973-980e-1b410df62346 | docker  | 100         | docker-lv      |
| 0bc4452d-7ef8-4766-b183-cd555cee5920 | kubelet | 100         | kubelet-lv     |
| 6aa1e91d-a4d0-4c58-ab9d-0a8fb0e80f76 | scratch | 16          | scratch-lv     |
+--------------------------------------+---------+-------------+----------------+

완료!

웹 페이지를 개설했다면, 그리고 외부에서 접근가능하려면 어떻게 해야할까?

이를 위해 많은 분들이 Service와 Ingress를 혼동한다. 그래서 이에 대해 짧게 알아보도록 하자.

NodePort type의 Service를 통해 포트를 정의해줘서 외부로부터 접근이 가능하게 만들 수 있다.

그리고, 포트를 외우기 귀찮으니(원래는 http://my-online-store.com:38080으로로 접근)

proxy server를 이용함으로써 URL을 통해 접근 가능하게 한다.

만약 GCP등의 Cloud platform을 사용한다면 LoadBalancer Type의 service를 사용하면 된다.

그럼 K8s가 알아서 포트, 외부 ip등을 다 할당해준다.

자, 그런데 비즈니스가 잘 되어서 /watch라는 또 다른 app을 만든다고 치자.

그럼 기존 my-online-store.com은 my-online-store.com/wear로 바꾸어야할 것이다.

그럼 동일한 클러스터 내 오른쪽 노란색 표기와 같이 새로운 인스턴스들을 만든다.

그럼, wear app에 접근 또는 video 앱에 각각 접근하기 위해 어떻게 해야할까?

가장 상단에 새로운 service를 만들어서 이 두개 app에 대한 정의를 해야하고, SSL enable도 시켜야 한다.

그런데 이건, app level과 다른 level이다.

그런데, app이 더 늘어날 경우?

계속 파일을 수정해줘야하고 SSL도 처리해야하고, 경로와 포트등을 계속 만들어줘야 한다.

그래서 Ingress라는 개념이 나왔다.

Ingress는 K8s에 built-in된 7계층 LoadBalancer로,

하나의 외부 URL을 이용해서 클러스터 내 다른 서비스로 라우팅을 시켜줄 수 있고, SSL Security또한 실행해줄 수 있다.

하지만, 이 또한 외부에서 클러스터로 접근하기 위해

node port 또는 cloud native LB를 사용해서 외부로 노출시켜줘야 한다.

다만, 이건 단 한번만 하면 된다. 

1. Deploy = Ingress controller

Ingress를 위한 solution으로는 nginx, haproxy, traefik 등을 사용하면 된다.

이렇게 deploy하게되는 솔루션들을 ingress controller라고 부르고,

2. Configure = Ingress resources

설정하는 rule들을 ingress resource라고 부른다.

이건 기존 우리가 생성했던 pod deploy처럼 definition file을 이용해서 생성된다.

그런데, ingress controller는 defualt로 built-in 되어있지 않다. 

그래서 이걸 무조건 deploy 해줘야 하는데, 어떤 걸 deploy 해줘야할까?

위와 같이 많은 종류의 사용 가능한 솔루션이 있다.

이 강의에서는 nginx를 예시로 사용하고 있고, 이건 기존에 사용하던 LB나 nginx 서버와는 다르다.

Ingress controller에서 LB 컴포넌트는 단지 일부일뿐이고, K8s 클러스터를 모니터링 할 수 있는 기능이 포함되어 있다.

Controller는 다른 deployment와 동일한 방식으로 deploy 되는데, definition file을 한번 확인해보자.

nginx program은 /nginx-ingress-controller라는 경로에 저장되어 있는데, 

keep-alive threshold, ssl setting, session timeout 등을 설정하기 위해 별도의 ConfigMap을 만든다.

그래서 configmap에 대한 정의 또한 args에 포함한다.

그리고, pod와 pod의 namespace 또한 env로 포함해줘야하고,

ingress controller에 의해 사용되는 ports 또한 추가한다.

그리고, ingress controller를 외부 세상에 노출하기 위해 service가 필요하다.

그래서 NodePort 타입의 service를 생성하고, label-selector를 이용해서 deployment와 링크시킨다.

그리고, 아까 언급했듯 ingress는 k8s 클러스터를 모니터링하는 추가적인 기능들을 갖고 있다.

그래서 어떤 설정이 변경되었을 때, 그것들을 nginx 서버에 설정할 수 있는데, 이를 위해 service account가 필요하다.

이 service account에는 맞는 퍼미션이 필요한데, 그를 위해 roles과 roles binding이 필요하다.

즉, 정리하자면

ingress를 위해서는 최소한으로 Deployment file, service file, configmap, Auth(ServiceAccount)가 필요하다.

ingress resource는 ingress controller에 적용되는 rules과 configurations들의 세트인데, 

첫 번째 그림과 같이 모든 incomming traffic에 대해 single application으로 route할 수도 있고, 

두 번째 그림과 같이 URL을 기반으로 다른 app들로 라우팅을 분배할 수도 있다. 

그럼 이것들을 어떻게 설정하는지 알아보자.

ingress resource는 위의 오른쪽과 같이 파일을 정의해주는데, pod에게 direct로 가는 게 아니라, service로 보내준다.

그리고, 다른 조건에 따라 traffic을 분리하고 싶을 때 rules을 사용할 수도 있는데,

위와 같이 www.my-online-store.com // www.wear.my-online-store.com/ 등으로 분리할 수 있다.

아래에서 하나씩 설정을 확인해보자.

위와 같이, 각 호스트의 top level로부터 rule을 생성할 수도 있고,

URL을 기반으로 라우팅 패스를 다르게 설정할 수도 있다. 

어떻게 설정할까?

처음엔 Ingress-wear.yaml를 사용했지만,

지금은 두 개의 app으로 나뉘므로, ingress-wear-watch.yaml 파일에서 각각의 path와 service를 정의해줘야 한다. 

이후 yaml파일을 apply로 생성하면, 위와 같이 ingress를 조회해볼 수 있다.

2가지 path가 생긴 것을 확인할 수 있는데, 위의 Default backend는 무엇일까?

유저가 접근을 시도하는 URL이 없을 때(어떤 Rule도 match되지 않을 때) 보여주는 page를 정의하는 것이다.

위의 oops 404 페이지처럼 말이다.

자, 그럼 3번째 설정 타입으로는 domain name 또는 host name을 이용하는 것을 알아보자.

이전 설정에선 host를 정의하지 않았는데, host를 정의하지 않으면

hostname matching 없이 특정 rule에 따라 incoming traffic이 허용된다.

이전에 만든 것과 비교해보면(왼쪽), rule에 hostname이 추가되었을 뿐이다. (오른쪽)

출처: Udemy 사이트의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의

pod/container가 생성된 후, 그 안에 있는 data는 pod/container가 삭제되면 함께 삭제된다.

그래서, 이런 데이터들을 영구적으로 보관하기 위해 Volume이라는 개념이 나온다.

single node라면 위와 같이 pod-definition에 'volumemount', 'volumes'로

node 내에 있는 /data directory에 저장한다고 정의할 수 있다.

그런데, multi-Node가 된다면 이 방법은 점점 더 복잡해질 것이다.

그래서 AWS, cephFS와 같은 Storage를 사용한다.

PV, PVC를 알아보자.

위와같이 POD별로 각 Storage를 설정하면 복잡해지고, 하나가 수정될 때마다 전체를 수정시켜야하는 귀찮음이 있다.

그래서 이를 중앙에서 관리하기 위한 solution으로 PV라는 Volume이 나온다.

PV: storage volumes의 wide pool

A persistent volume is a cluster wide pool of storage volumes configured by an administrator to be used

by users deploying applications on the Cluster.

PVC: User가 pv를 할당받기 위해 생성하는 instance

The users can now select storage from this pool using persistent volume claims.

administrator는 PV를 생성하고, user는 PV를 사용하기 위해 PVC를 생성한다.

PV를 생성해보자. 

간단하다, 위와 같이 Yaml 파일을 작성한다.

그러면 PV와 PVC간 Binding 작업이 이루어지는데, 보통 capa, access mode등이 거의 유사한 것끼리 1:1 binding이 된다.

혹시 특정한 PV, PVC를 쓰고 싶다면 labels/selector를 통해 설정할 수 있다.

만약 pvc에 맞는 pv가 없으면, pvc는 pending 상태가 된다.

pvc를 생성해보자.

pv와 거의 동일하며 storage size를 맞춰주자.

그리고 pvc를 삭제할 수도 있는데, pvc가 삭제되었을 때 PV가 어떻게 될지 설정할 수도 있다.

- Retain (admin이 수동으로 삭제할 때까지 갖고있기), Delete(삭제됨과 동시에 삭제), Recycle(다른데서 사용)

출처: Udemy 사이트의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의

모든 pod끼리는 서로 연결이 되어있다.

그런데, 일부 구간(ex. web Pod - DB Pod)은 direct로 연결되지 않길 바랄 수도 있다. (security 이슈 등으로 인해)

그럴 때, Network Policy 라는 것을 사용한다.

Ingress traffic을 3306, API Pod에게만 받는 것이다.

이때, 예전에 배웠던 Selector, labels 인스턴스가 다시 나온다.

NetworkPolicy라는 yaml파일을 만든 뒤, spec 아래 부분에 오른쪽의 두 블럭을 붙여준다.

예를 들어 이렇게.

spec:

  podselector:

    matchlabels:

      role: db

  policyTypes:

  - Ingress

  Ingress:

  - from:

    - podSelector:

        matchLabels:

          name: api-pod

  ports:

  - protocol: TCP

    port: 3306

그럼 조금 더 조건을 추가해보자.

pod는 api-pod 에서만 들어오도록 하고, namespace는 prod에 있는 것만,

ip는 192.168.5.10/32로부터 오는 것만 허용하도록 하자.

이 경우, '-'를 사용할 경우, 별개의 룰이 되어 &&조건이 아닌 || 조건이 된다.

따라서, api pod이거나, prod namespace 안에 있거나, 192.168.5.10/32로부터 오면 허용한다는 뜻이다.

만약 &&조건을 주고 싶으면, '-'를 없애면 된다.

그리고, egress도 동시에 추가할 수 있다.

egress도 engress와 동일하되, egress는 outgoing 하는 traffic이므로 'to' 옵션을 사용한다.

network policy에 대한 조회는 아래 커멘드로 확인할 수 있다.

# kubectl get netpol [policy name]

# kubectl describe networkpol [policy name]

끝-

출처: Udemy 사이트의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의

이전 강의까지, 우리는 user에 대한 role binding을 알아보았고, namespace도 지정했다.

즉, role binding은 namespace 내에 생성된다.(만약 namespace가 명시되지 않았다면 default namespace 내에 생성)

그런데, Node는 namespace에 종속될 수 있을까?

아니다. 즉, resources들은 namespaced or cluster scope으로 구분된다.

그래서 이번 강의에서는 cluster role / cluster binding에 대해 알아본다.

cluster scope에서는 namespaced에서 정의되어 있지 않은 것들을 정의한다.

그 중에, user에서 권한을 주기위해 사용했던 roles, rolebindings 파일은, 

cluster scope에서 clusterroles, clusterrolebindings 파일이 된다.

cluster role/binding은 기존 namespaced가 특정 namespaced에 속한 resource만 관리된 것과 달리,

여러 cluster내에 걸쳐있는 namespace또한 관리할 수 있다.

출처: Udemy 사이트의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의