시골쥐의 공부생활

이전에 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     |
+--------------------------------------+---------+-------------+----------------+

완료!

* 해당 포스팅은 아래 출처의 자료를 거의 그대로 가져온 것이다. 

LVM(Logical Volume Management)
: 디스크나 대용량 스토리지 장치를 유연하고 확장 가능하게 다룰 수 있는 기술.
이를 커널에 구현한 기능을 LVM(Logical Volume Manager) 이라고 한다.

기존에 저장 장치를 사용했던 방식은, 
물리 디스크를 파티션이라는 단위로 나눈 후 OS에 마운트하여 사용했는데
마운트를 하려면 파티션을 특정 디렉토리와 일치시켜 주어야 했다.

만약 특정 파티션(/home 이라 가정)에 마운트된 파티션의 용량이 일정 수준 이상 찼을 경우
 번거로운 작업(추가 디스크 장착, 기존 언마운트, 추가 마운트 등) 또한 요구되었다.

기존 방식이 파일시스템을 블록 장치에 직접 접근해서 읽고쓰기를 했다면,
LVM은, LVM이 만든 가상의 블록 장치에 파일시스템이 읽고 쓰기를 하게된다.

LVM 은 파티션대신 볼륨이라는 단위로 저장 장치를 다룰 수 있으며,
물리 디스크를 볼륨 그룹으로 묶고 이것을 논리 볼륨으로 분할하여 관리한다. 
스토리지의 확장이나 변경시 서비스 변경을 할 수 있으며 
특정 영역의 사용량이 많아져서 저장 공간이 부족할 경우 유연하게 대응 가능하다.
아래의 그림은 LVM의 구성 예시이다.

/home 영역이 거의 찼을 경우 LVM이 적용되어 있으면 다음과 같이 처리할 수 있다.
- 추가 디스크를 장착 (host-partition-add lvm_phys_vol)
- 추가된 디스크에 파티션을 만들어서 물리 볼륨(PV) 생성 (Add partition to PV list of LVG: host-pv-add)
- 물리 볼륨을 볼륨 그룹(VG)에 추가. 여기서는 vg_data 볼륨 그룹으로 추가.
- /home 이 사용하는 논리 볼륨인 lv_home의 볼륨 사이즈를 증가

위와 같이  기존 데이터의 삭제나 이동 없이 서비스 구동 상태에서 볼륨을 변경할 수 있다.

LVM의 주요 용어 5가지를 알아보자.

1. PV(Physical Volume)
2. PE(Physical Extent)
3. VG(Volume Group)
4. LV(Logical Volume)
5. LE(Logical Extent)

1. PV(Physical Volume)
LVM에서 블록 장치(블록 단위로 접근하는 스토리지. ex) HDD)를 사용하려면 우선 PV로 초기화를 해야한다.
즉, 블록 장치 전체 또는 그 블록 장치를 이루고 있는 파티션들을 LVM에서 사용할 수 있게 변환하는 것이다. 

예를 들어 /dev/sda1, /dev/sda2 등의 블록 스토리지를 LVM으로 쓰기위해 PV로 초기화한다.

PV는 일정한 크기의 PE(Physical Extent)들로 구성된다.

2. PE(Physical Extent)
PV를 구성하는 일정한 크기의 블록으로 LVM2에서의 기본크기는 4MB. 

LVM은 LVM1과 LVM2이 있는데 여기서는 다루지 않고 간단히 LVM2가 기능이 개선된 버전이라고 이해하면 된다.

PE는 곧 설명할 LV(Logical Volume)의 LE(Logical Extent)들과 1:1로 대응된다.
그렇기에 항상 PE와 LE의 크기는 동일하다.

3. VG(Volume Group)
PV들의 집합으로 LV를 할당할 수 있는 공간이다. 즉, PV들로 초기화된 장치들은 VG로 통합되게 된다.
사용자는 VG안에서 원하는대로 공간을 쪼개서 LV로 만들 수 있다. 위에서 만든 PV들을 하나의 VG1로 그룹지었다.

4. LV(Logical Volume)
사용자가 최종적으로 다루게 되는 논리적인 스토리지이다.
생성된 LV는 파일 시스템 및 애플리케이션(Database 등)으로 사용된다.
위에서도 언급했듯이, LV를 구성하는 LE들은 PV의 PE들과 맵핑하며 존재하게 된다.
LE와 PE가 맵핑되면서 총 3가지 유형의 LV가 생성된다. 

- 선형(Linear) LV
- 스트라이프(Striped)된 LV

- 미러(Mirrored)된 LV

- 선형(Linear) LV
하나의 LV로 PV를 모으는 방법. 
예를들어 두개의 60GB 디스크(PV를 의미)를 가지고 120GB의 LV를 만드는 방식.
LV만을 사용하는 사용자의 입장에서는 120GB의 단일 장치만 있게 되는 셈.
(물론 LV를 여러개로 나누는 것도 가능)

- 스트라이프(Striped)된 LV
LV에 데이터를 기록하게되면, 파일 시스템은 PV에 데이터를 기록하게되는데(PE와 LE의 매핑대로), 

스트라이프된 LV을 생성해서 데이터가 PV에 기록되는 방식을 바꿀수 있다.
대량의 순차적 읽기/쓰기 작업의 경우에 효율을 높일 수 있는 방법.
Round-Robin 방식으로 미리 지정된 PV들에 데이터를 분산 기록해서 성능을 높였고, 읽고/쓰기를 병렬로 실행할 수 있음
아래 그림은 LV에 데이터를 기록할 때, 각각의 PV에 번갈아가며 기록하는 Striped LV를 잘 보여준다.
번갈아가는 기준은 데이터의 크기인데 이를 스트라이프 크기라고하며 Extent의 크기(PE/LE크기)를 초과할수 없다.

- 미러(Mirrored)된 LV
이름 그대로 블록 장치에 저장된 데이터의 복사본을 다른 블록 장치에 저장하는 방식.
데이터가 하나의 PV에 저장될때, 이를 미러하고있는 PV에 동일한 데이터가 저장됨
이를 통해 장치에 장애가 발생하게 될경우 데이터를 보호할 수 있게된다.
하나의 장치에 장애가 발생하게 되면, 선형(Linear)으로 저장되어 있기에 다른 장치에서 쉽게 접근이 가능해지고, 

어떤 부분이 미러를 통해 동기화되었는지에 대한 로그를 디스크에 저장하게 된다.

5. LE(Logical Extent)
LV를 구성하는 일정한 크기의 블록으로 기본크기는 PE와 마찬가지로 4MB.
아래 그림은 위에서 만든 VG1에서 사용자가 원하는 크기대로 분할해서 LV1과 LV2를 만든 모습. 
꼭 VG의 모든 공간을 다 써야되는건 아니고, 각각의 LV들은 동일한 크기의 LE로 구성이되며 PE들과 1:1로 맵핑된다.

출처: https://tech.cloud.nongshim.co.kr/2018/11/23/lvmlogical-volume-manager-1-%EA%B0%9C%EB%85%90/

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

이를 위해 많은 분들이 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 강의

RBAC에서 Role은 어떻게 만들까?

오른쪽 yaml파일과 같이 Role에 대한 yaml파일을 만들고, kubectl create로 role을 생성해주면 된다.

rules에는 여러개의 key가 들어가서 여러 조건을 줄 수 있고, apiGroups은 coregroup일 경우 비워둔다.

role YAML을 다 작성하고 나서는? user - role간 link를 해준다.

즉, user를 role object와 linkg해주는 Role-binding이라는 yaml을 만든다.

(위 그림에서는 devuser-developer-binding.yaml)

subjects는 user에 대한 details를 작성하는 곳이고, roleRef는 생성된 role에 대한 정보를 작성하는 곳이다.

그리고 kubectl create -f devuser-developer-binding.yaml을 통해 binding object도 실행해준다.

role과 rolebinding간 namespace를 동일하게 맞추는 것 잊지말자.

role, rolebinding을 조회하는 명령어.

내 권한이 특정 resource에 접근 가능한지 확인하는 방법이다.

#kubectl auth can-i [ ]

resourcename에 대한 권한도 rules 아래에 줄 수 있다.

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

Authorization이 왜 필요할까?

클러스터는 다양한 clients들이 함께 사용하는데, 각자의 권한에 따라 기능을 제한하기 위함이다.

Authorization Mechanisms은 크게 4가지가 있는데, 하나씩 알아보자.

- Node Authorizer: named/pods system node내에서 발생하는 요청들은 Node Authrrizer에 의해 처리된다.

권한들은 kubelet에 의해 요구되기 때문에, cluster 내에서 일어난다.

external access to API

유저마다 권한이 다른데, 이걸 하나씩 직접 policy 파일에 등록/수정해야한다.

사람이 많아질수록 관리가 어려워지는데, 이를 위해 RBAC가 나왔다.

RBAC(Role Base Access Control):

유저마다 각각 policy를 만들지 않고, Developer, Security와 같은 Role을 만들어서 유저들을 해당 role에 associate한다.

이렇게 하면, role에서 수정된 내용들이 각 user에도 모두 적용되어 관리가 쉬워진다.

opensource를 쓰고 싶다면, open Policy Agent를 쓰면 된다.

open policy agent는 3rd party tool로 admission control & authorization을 도와준다.

남은 메커니즘으로 2가지가 더 있는데, AlwaysAllow와 Always Deny로 조건없이 항상 허용/거절하는 것이다.

그럼 이런 메카니즘들을 어디에 설정할까?

kube-apiserver에 설정된다. 만약 아무 값도 설정하지 않는다면, AlwaysAllow가 default 값이 된다.

그럼, 여러 개의 모드가 작성되어 있으면?

작성된 순서에 따라 체크를 하고, 각 모드에서 관련된 것이 없다면 다음 모드로 체크한다.

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

이전 강의들에서 계속 kubeapi server와 통신했다.

version을 보기 위해서는 왼쪽과 같이 조회할 수 있고, pod의 lists들을 얻기 위해서는 오른쪽과 같이 조회할 수도 있다.

여기서 말하는 /version, /api 들이 API Group이다.

실제로 api group들은 위와 같이 다양한데, 클러스터 functionality와 관련있는 /api, /apis에 대해 알아본다.

/api는 core server이고  /apis는 named server인데 아래에서 하나씩 알아보자.

core group인 /api는 all core functionality가 존재하는 곳으로 namespace, pods, nodes들이 정의되어 있다.

named group인 /apis는 더 정교한 정보들이 저장되어 있고, new feature들이 available 해진다.

크게 API Groups으로 나누고, 그 아래에서 Resource, Verbs 등으로 한 번 더 나뉜다.

All resources in Kubernetes are grouped into different api groups. At the top level you have core api group and named api group. Under the named api group You have one for each section under this API group.

You have the different resources and each resource has a set of associated actions known as verbs in

the next section on authorization.

실제로 k8s에서 해당 api group들을 조회해본다.

# curl http://localhost:6443 -k   // available한 api group listup

# curl http://localhost:6443/apis -k | grep "name" // 지원되는 all resource grp

그런데, 실제로 api version을 아래와 같이 정확하게 입력하지 않고, 위와 같이 -k로 입력하면 forbidden이 발생한다.

그런데 실제로 어떻게 api verison값들을 저렇게 다 써줄 수 있을까? (복잡한데 말이다.)

그래서 kubectl Proxy를 사용한다.

먼저 kubectl proxy에 접속한 후, curl 명령어를 통해 Kube ApiServer에 접근하면 된다.

단, 여기서 말하는 kubectl Proxy는 != kube Proxy다.

Kube Proxy는 pod/service간 connectivity를 위한 인스턴스 였다면,

kubectl proxy는 kube apiserver에 접근하기 위해 kubectl utility로부터 생성된 HTTP proxy 서비스다.

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

K8s에서 client는 인증서를 사용하기 위해 curl 명령어를 이용하여 쿼리를 한다.

그런데, 명령어가 너무 길어지다보면 실수를 할 수도 있고 매일 이렇게 다 쳐주는 건 귀찮은 일이다.

그래서 kubeConfig File 개념이 나온다.

여기에 작성을 해 두고, 조회나 curl시 kubeConfig 를 이용하여 인증서를 조회할 수 있다.

그리고 kubeConfig 포맷은 크게 3가지 섹션으로 나뉘는데, 아래에서 알아보자.

크게 Clusters, Contexts, Users로 나뉜다.

Cluster는 말 그대로 시료 환경에 대한 것이고, clients 들은 k8s 환경에 접속하는 user들인데

각각 권한이 다르다.

Context는 어떤 Users가 어떤 Clusters에 접근하는지를 묶어주는 부분이다.

실제 KubeConfig file은 $HOME/.kube/config 디렉토리에 있으며,

clusters, contexts, users 섹션으로 나뉜다.

contexts의 cluster에 clusters name을 입력해주고, contexts의 user 부분에 users의 name을 입력해준다.

kubeConfig 파일은 위와 같이 조회할 수 있으며, current-context 수정은 오른쪽과 같이 가능하다.

# kubectl config view

# kubectl config use-context [변경할 내용]

그럼 다른 내용들을 수정/삭제하고 싶다면?

#kubectl config -h 를 통해 알아보면 된다.

Cluster내엔 다양한 namespace도 있을 텐데, kubeconfig에도 해당 namespace를 명시해줄 수 있다.

그리고 certificate-authority도 crt파일의 전체 path를 입력해줘야 하지만, 아예 

'certificate-authority-data'를 여기 파일에 직접 입력하는 방법도 있다. (물론 base64로)

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