원인 파악 도중 특정 노드에 원격접속이 되지 않아 결국 리부팅으로 해결하여 절차만 기록해두었습니다.

아래와 같은 에러가 발생했을때

# oc get co/dns
NAME   VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
dns    4.12.0    True        True          False      49d     DNS "default" reports Progressing=True: "Have 4 available DNS pods, want 5."

DNS Pod 를 확인합니다.

# oc get pod -n openshift-dns
NAME                  READY   STATUS             RESTARTS       AGE
dns-default-d88tp     2/2     Running            0              49d
dns-default-jk4gh     0/2     CrashLoopBackOff   988 (7s ago)   49d
dns-default-lklsh     2/2     Running            0              49d
dns-default-svtxz     2/2     Running            0              49d
dns-default-z2plz     2/2     Running            0              49d
node-resolver-8m85h   1/1     Running            0              49d
node-resolver-h6g59   1/1     Running            0              49d
node-resolver-nchv9   1/1     Running            0              49d
node-resolver-s927r   1/1     Running            0              49d
node-resolver-xwltt   1/1     Running            0              49d

dns-default 이름의 Pod 는 노드의 개수만큼 존재 하는데, master node, worker node 가 모두 5개인데, 4개만 사용 가능하다고 출력되고 있습니다.

문제가 발생한 Pod 는 어느 노드의 Pod 인지 확인합니다.

# oc get pod dns-default-jk4gh -n openshift-dns -o wide

NAME                READY   STATUS             RESTARTS           AGE   IP           NODE                      NOMINATED NODE   READINESS GATES
dns-default-jk4gh   0/2     CrashLoopBackOff   1001 (3m47s ago)   49d   10.131.0.6   worker01.az1.sysdocu.kr   <none>           <none>

worker01 임을 확인하였습니다.

해당 Pod 의 로그를 확인합니다.

# oc logs dns-default-jk4gh -n openshift-dns
Defaulted container "dns" out of: dns, kube-rbac-proxy
open exec fifo /proc/self/fd/5: too many open files in system

좀 더 자세한 문제 확인을 위해 worker01 서버에 접속합니다.

# ssh core@115.68.142.104
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

접근 불가가 확인되었습니다. 참고로 다른 노드로는 원격접속이 원활히 진행되었습니다.

worker01 노드에 원격접근 자체가 불가능하여 해당 서버를 리부팅 하였고, 그 이후 dns-default 가 정상으로 돌아왔습니다.

# oc get pod dns-default-jk4gh -n openshift-dns -o wide
NAME                READY   STATUS    RESTARTS   AGE   IP            NODE                      NOMINATED NODE   READINESS GATES
dns-default-jk4gh   2/2     Running   1007       49d   10.131.0.13   worker01.az1.sysdocu.kr   <none>           <none>

# oc get co/dns
NAME   VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
dns    4.12.0    True        False         False      49d  

콘솔에서 worker01 노드에 로그인이 가능하도록 root 패스워드 설정을 해놓으면 원인을 파악할 수 있던 상황이였는데 core 계정으로 네트워크 로그인만 가능하도록 되어 있어 어쩔수 없이 리부팅하였으며, 이를 계기로 모든 노드에 root 패스워드 설정을 진행하였습니다.

참고로, dns 에러 외에 oc get co 명령으로 보였던 몇가지 항목의 에러가 위 조치로 인해 모두 해결되었습니다.

image-registry                             4.12.0    True        True          False      49d     Progressing: The registry is ready...

ingress                                    4.12.0    True        True          True       49d     The "default" ingress controller reports Degraded=True: DegradedConditions: One or more other status conditions indicate a degraded state: DeploymentReplicasAllAvailable=False (DeploymentReplicasNotAvailable: 1/2 of replicas are available)

monitoring                                 4.12.0    False       True          True       42h     reconciling Prometheus Operator Admission Webhook Deployment failed: updating Deployment object failed: waiting for DeploymentRollout of openshift-monitoring/prometheus-operator-admission-webhook: got 1 unavailable replicas

network                                    4.12.0    True        True          False      49d     DaemonSet "/openshift-network-diagnostics/network-check-target" is not available (awaiting 1 nodes)...

Replicas 또는 ReplicaSet 구성후 운영중인 Pod 가 삭제될때, 가용성을 따져보아 다른 worker node 로 재생성되기도 하는데, 여기에서는 Affinity 기능을 이용해 같은 worker node 로 재생성 되도록 하는 방법을 알아봅니다. Affinity 는 worker node 에 Pod 를 배치할때 사용하는 옵션입니다.

우선 노드 선택이 가능하도록 노드에 라벨을 추가하여, 키와 값을 입력합니다.

현재 아래와 같이 worker node 가 두개 있는데, 이 노드에 키와 값을 입력해주겠습니다.

# oc get nodes
NAME                      STATUS   ROLES                  AGE   VERSION
master01.az1.sysdocu.kr   Ready    control-plane,master   43d   v1.25.4+77bec7a
master02.az1.sysdocu.kr   Ready    control-plane,master   43d   v1.25.4+77bec7a
master03.az1.sysdocu.kr   Ready    control-plane,master   43d   v1.25.4+77bec7a
worker01.az1.sysdocu.kr   Ready    worker                 42d   v1.25.4+77bec7a
worker02.az1.sysdocu.kr   Ready    worker                 42d   v1.25.4+77bec7a

# oc label nodes worker01.az1.sysdocu.kr choice=ALL choicesub=wnode1
node/worker01.az1.sysdocu.kr labeled

- Group 용도로 'choice:ALL' 생성

- 노드 전용으로 'choicesub:wnode1' 생성

# oc label nodes worker02.az1.sysdocu.kr choice=ALL choicesub=wnode2

node/worker02.az1.sysdocu.kr labeled

- Group 용도로 'choice:ALL' 생성

- 노드 전용으로 'choicesub:wnode2' 생성

* 참고

라벨 삭제 방법입니다. 라벨명 (예: choicesub) 뒤에 - 를 꼭 붙여야 삭제됩니다.

# oc label node <노드명> <라벨명>-

설정된 상태를 확인합니다.

# oc get node -L choice,choicesub
NAME                      STATUS   ROLES                  AGE   VERSION           CHOICE   CHOICESUB
master01.az1.sysdocu.kr   Ready    control-plane,master   49d   v1.25.4+77bec7a            
master02.az1.sysdocu.kr   Ready    control-plane,master   49d   v1.25.4+77bec7a            
master03.az1.sysdocu.kr   Ready    control-plane,master   49d   v1.25.4+77bec7a            
worker01.az1.sysdocu.kr   Ready    worker                 49d   v1.25.4+77bec7a   ALL      wnode1
worker02.az1.sysdocu.kr   Ready    worker                 49d   v1.25.4+77bec7a   ALL      wnode2

아래와 같이 Deployment yaml 파일을 작성 합니다.

# vi deployment.yaml

Affinity 는 Node Affinity 와 Pod Affinity 가 있는데, 어느것을 기준으로 하는지에 따라 다릅니다.

- Node Affinity : 생성된 Pod 를 특정 worker node 에서 가동

- Pod Affinity : Replicas 로 생성된 동일한 Pod 를 같은 worker node 에서 가동
- Pod AntiAffinity : Replicas 로 생성된 동일한 Pod 를 다른 worker node 에서 가동

operator 는 Node Affinity 규칙에 사용되는 연산자를 지정하는 필드입니다.

- In : 특정 키 (key) 의 값을 포함하는 경우에 매치. 즉, 값 (values) 이 키에 포함되어 있는 경우 해당 노드에 Pod 를 생성
- Exists : 특정 키 (key) 가 존재하는 경우에 매치. 값 (values) 에 관계없이 키가 존재하면 해당 노드에 Pod 를 생성
- Gt (Greater than) : 특정 키 (key) 의 값이 지정한 값 (values) 보다 큰 경우에 매치. 주로 숫자 값을 비교할 때 사용
- Lt (Less than) : 특정 키 (key) 의 값이 지정한 값 (values) 보다 작은 경우에 매치. 역시 숫자 값을 비교할 때 사용
- NotIn : 특정 키 (key) 의 값을 포함하지 않는 경우에 매치. 값 (values) 이 키에 포함되지 않은 경우 해당 노드에 Pod 를 생성
- DoesNotExist : 특정 키 (key) 가 존재하지 않는 경우에 매치. 값 (values) 에 관계없이 키가 존재하지 않으면 해당 노드에 Pod 를 생성

작성한 yaml 파일을 적용하여 Pod 를 생성합니다.

참고로, Kubernetes 사용자는 아래 oc 명령대신 kuberctl 을 사용하면 됩니다.

# oc apply -f deployment.yaml

Pod 가 어느 worker node 에 생성되었는지 확인합니다.

# oc get pod -o wide
NAME                              READY   STATUS    RESTARTS   AGE   IP            NODE                      NOMINATED NODE   READINESS GATES
app-5f86cc794b-656dg   1/1     Running   0          27s   10.131.0.13   worker01.az1.sysdocu.kr   <none>           <none>

Affinity 옵션값의 노드 라벨을 다른 노드로 변경하고, apply 명령으로 적용하면 곧바로 기존 Pod 는 삭제되고, 지정한 노드에 Pod 가 생성됩니다.

원래 Pod 는 스케쥴링 되는 노드 (worker node) 의 가용성 체크 뒤, Round-Robin 방식으로 분배 생성되지만 Affinity 적용 후에는 지정한 노드로만 생성되는것을 확인 할 수 있습니다.

노드를 변경하고 (wnode1 -> wnode2)

# sed -i 's/wnode1/wnode2/' deployment.yaml

적용합니다.

# oc apply -f deployment.yaml

Pod 상태를 확인해보면 지정한 노드에 Pod 가 생성되어진 것을 볼 수 있습니다.
# oc get pod -o wide
NAME                   READY   STATUS        RESTARTS   AGE    IP             NODE                      NOMINATED NODE   READINESS GATES
app-54f888586f-xbmlj   1/1     Running       0          11s    10.128.3.242   worker02.az1.sysdocu.kr   <none>           <none>
app-5f86cc794b-656dg   1/1    Terminating   0          12m   10.131.0.13   worker01.az1.sysdocu.kr   <none>           <none>

Openshift 또는 Kubernetes 에서 컨테이너 생성시 권한을 제한하여 보안을 강화하는 방법이 있습니다.

Pod 생성시 컨테이너 권한 제한 예제입니다.

위 예제에서 container1 컨테이너의 securityContext 에서 SYS_ADMIN 외 여러개의 권한을 제한하도록 설정하였습니다. 이렇게 하면 container1 에서만 시스템 관리 작업과 기타 작업을 위한 명령어 사용이 제한됩니다. 아래는 securityContext의 capabilities 섹션에서 remove 필드에 사용할 수 있는 종류 중 일부 목록입니다. 아래 항목을 remove 필드에 추가하여 사용을 제한하면, 컨테이너 보안 강화에 도움이 됩니다.

"SETPCAP": 프로세스의 임의의 캐퍼빌리티 설정을 방지합니다.
"SYS_MODULE": 커널 모듈의 적재 및 언로드를 방지합니다.
"SYS_RAWIO": 장치에 대한 원시 입출력을 방지합니다.
"SYS_PACCT": 프로세스 계정 정보에 대한 접근을 제한합니다.
"SYS_ADMIN": 시스템 관리 작업을 수행할 수 있는 권한을 제한합니다.
"SYS_NICE": 프로세스에 대한 우선 순위 설정을 방지합니다.
"SYS_RESOURCE": 자원 제한에 대한 설정을 방지합니다.
"SYS_TIME": 시스템 시간 설정을 방지합니다.
"SYS_PTRACE": 다른 프로세스에 대한 추적 기능을 제한합니다.
"SYS_BOOT": 부팅 설정을 제한합니다.
"DAC_READ_SEARCH": 파일의 소유권 및 검색 설정에 대한 권한을 제한합니다.
"LINUX_IMMUTABLE": 파일의 변경 및 수정을 방지합니다.
"NET_ADMIN": 네트워크 설정에 대한 권한을 제한합니다.
"IPC_LOCK": 공유 메모리 세그먼트에 대한 락 설정을 방지합니다.

GlusterFS Cluster 정보를 이용하여 Endpoint 를 작성합니다.

# vi endpoint.yaml

* 설명

subsets: address: ip: 는 GlusterFS 클러스터를 구성하는 서버의 실제 IP 주소여야 합니다.

subsets: ports: port: 에 입력하는 포트번호는 무시해도 됩니다.

작성한 yaml 파일을 적용합니다.

# oc apply -f endpoint.yaml
endpoints/glusterfs-cluster created

적용된 Endpoint 를 확인합니다.

# oc get ep
NAME                          ENDPOINTS                                            AGE
endpoints/glusterfs-cluster   115.68.249.122:1,115.68.248.172:1,115.68.249.106:1   12m

PV (Persistent Volume) 생성을 위한 yaml 파일을 작성합니다.

# vi pv.yaml

storageClassName: 빈 문자열을 명시적으로 사용해야 합니다. 그렇지 않으면 기본 StorageClass 가 설정됩니다.

glusterfs: endpoints: 에는 먼저 생성했던 Endpoint 이름 입니다.

glusterfs: path: 에는 마운트할 GlusterFS 의 볼륨입니다. 앞에 슬래시를 꼭 붙여줘야 합니다. 그리고 /gv0/apple 과 같이 쿼터 적용된 디렉토리로도 마운트 가능합니다.

persistentVolumeReclaimPolicy: 의 Retain 값은 PV 가 삭제되어도 GlusterFS 내의 데이터는 삭제하지 않겠다는 뜻입니다.

작성한 yaml 파일을 적용합니다.

# oc apply -f pv.yaml

persistentvolume/glusterfs-pv created

Pod 와 PV 를 연결하기 위한 PVC (PersistentVolumeClaim) yaml 파일을 작성합니다.

# vi pvc.yaml

작성한 yaml 파일을 적용합니다.

# oc apply -f pvc.yaml

persistentvolumeclaim/glusterfs-pvc created

Deployment yaml 를 작성하여 Pod 가 생성되도록 합니다.

# vi deployment_volume.yaml

volumeMounts: mountPath: 는 Pod 내에서 마운트 될 디렉토리를 의미하며 디렉토리가 없는 경우 자동으로 생성됩니다.

작성한 yaml 파일을 적용합니다.

# oc apply -f deployment_volume.yaml

Pod 에 Volume 이 잘 연결되었는지 확인합니다.

# oc get pod
NAME                                    READY   STATUS        RESTARTS   AGE
glusterfs-deployment-7c45b99b7c-pstl5   1/1     Running       0          7s

# oc rsh glusterfs-deployment-7c45b99b7c-pstl5

$ df -h
Filesystem                Size  Used Avail Use% Mounted on
overlay                   233G   36G  197G  16% /
tmpfs                      64M     0   64M   0% /dev
tmpfs                     7.8G     0  7.8G   0% /sys/fs/cgroup
shm                        64M     0   64M   0% /dev/shm
tmpfs                     7.8G   53M  7.7G   1% /etc/passwd
115.68.249.122:/gv0   10G  135M  9.9G   2% /data
/dev/sda4                 233G   36G  197G  16% /etc/hosts
tmpfs                      15G   20K   15G   1% /run/secrets/kubernetes.io/serviceaccount
tmpfs                     7.8G     0  7.8G   0% /proc/acpi
tmpfs                     7.8G     0  7.8G   0% /proc/scsi
tmpfs                     7.8G     0  7.8G   0% /sys/firmware

* 참고

마운트가 되지 않을 경우 Pod 부터 정상 가동 (Running) 되지 않습니다. 그런 경우에 GlusterFS 를 구성하는 노드가 DNS 에서 질의되지 않는 호스트명으로 되어있는지 확인해 볼 필요가 있습니다. gnode1, gnode2, gnode3 등의 호스트명으로 GlusterFS 노드가 구성 되어 있다면 worker 노드에서 마운트 하지 못하므로 모든 스케쥴링 되는 Openshift 노드 (worker node) 에 /etc/hosts 파일을 수정하여 GlusterFS 를 구성하는 노드의 IP 와 호스트명을 등록해놔야 합니다.

본 매뉴얼은 '[Openshift] 미터링 도구 Prometheus + AlertManager 알람' 에 이어서 작성되었습니다.

1. Grafana 설치

Grafana 는 수집한 metrics 값을 보기좋게 시각화 해주는 웹 GUI 환경의 대시보드 입니다.

아래 파일을 생성하고 적용해 줍니다.

# vi grafana.yaml

# oc apply -f grafana.yaml

deployment.apps/grafana created
service/grafana created

Grafana 의 호스트명을 확인하고 30004 포트를 이용하여 웹 GUI 환경으로 접속합니다.

# oc get pod -n monitoring -o wide
NAME                                     READY   STATUS    RESTARTS   AGE     IP             NODE                    NOMINATED NODE   READINESS GATES
alertmanager-689f68c448-88v92            1/1     Running   0          3d3h    10.128.2.254   worker01.az1.sysdocu.kr   <none>           <none>
grafana-577cc7fbdd-rdtcc                 1/1     Running   0          3m55s   10.128.3.41    worker01.az1.sysdocu.kr   <none>           <none>
node-exporter-57djp                      1/1     Running   0          8d      10.131.0.184   worker02.az1.sysdocu.kr   <none>           <none>
node-exporter-w5s8d                      1/1     Running   0          8d      10.128.2.239   worker01.az1.sysdocu.kr   <none>           <none>
prometheus-deployment-859bc6d5c7-mjhvk   1/1     Running   0          25m     10.128.3.37    worker01.az1.sysdocu.kr   <none>           <none>

웹브라우저 접속 URL :http://worker01.az1.sysdocu.kr:30004

2. Prometheus 연동 (데이터 추가)

Prometheus 에 수집된 데이터를 가져와 그래프로 그려보도록 합니다.

좌측 상단 토글 메뉴 > Administration > Data sources > [Add data source] > Prometheus 선택

HTTP 의 URL 항목에 입력해야 할 정보는 아래 명령으로 확인이 가능합니다.

# oc get service -n monitoring
NAME                 TYPE       CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
alertmanager         NodePort   172.30.25.192    <none>        9093:30005/TCP   7d19h
grafana              NodePort   172.30.24.162    <none>        3000:30004/TCP   18m
node-exporter        NodePort   172.30.65.240    <none>        9100:31672/TCP   8d
prometheus-service   NodePort   172.30.191.143   <none>        8080:30003/TCP   59m

URL 항목에 http://172.30.191.143:8080 이라고 입력하고 페이지 맨 아래 'Save & test' 버튼을 눌러 저장합니다.

Grafana 에서 Prometheus 데이터를 가져오도록 설정하였습니다.

3. 템플릿 적용

연동된 Prometheus 데이터를 PromQL 쿼리로 디자인해야 하는데, 손이 많이 가므로 Grafana 사이트에서 공유하고 있는 템플릿을 가져와 적용 시켜봅니다.

(Grafana 홈페이지에서)

대시보드 페이지 접속 https://grafana.com/grafana/dashboards/ > 페이지 가운데 'Search dashboards' 에 'kubernetes' 입력 및 검색 > 원하는 템플릿 클릭 > 'Download JSON' 선택하고 다운로드 받은 JSON 파일의 내용을 '전체 복사' 해둡니다.

(Grafana 설치 페이지에서)

좌측 상단 토글 메뉴 > Dashboards 선택 > 좌측 풀다운 메뉴 [New] 를 클릭으로 펼쳐서 'Import' 선택 > 중간에 'Import via panel json' 입력란에 붙여넣기 (Ctrl + V) 및 [Load] 클릭 > 맨 아래 'Select a Prometheus data source' 에서 Prometheus (default) 선택 후 [Import] 클릭

초기화면으로 자동 이동되면서 예쁜 템플릿으로 구성된 대시보드를 볼 수 있습니다.

helm 은 OC 또는 Kubernetes 클러스터에서 Kubernetes 애플리케이션을 관리하기 위한 패키지 관리 도구입니다.

helm 설치 방법은 다음과 같습니다.

helm 공식 웹사이트에서 운영 체제에 맞는 helm 바이너리 파일을 다운로드합니다.

다음 링크를 사용하면 최신 버전의 helm을 다운로드할 수 있습니다.

URL : https://github.com/helm/helm/releases

페이지 중간부에 Download 섹션이 있고, 64bit 리눅스 OS 를 사용하기 때문에 'Linux arm64' 항목의 주소를 복사하여 리눅스 쉘에서 다운로드 하였습니다.

# wget https://get.helm.sh/helm-v3.12.0-linux-amd64.tar.gz

# tar xvzf helm-v3.12.0-linux-amd64.tar.gz

실행파일을 PATH 경로에 포함된 디렉토리로 이동시킵니다.

# mv linux-amd64/helm /usr/local/bin/

버전을 확인합니다.

# helm version

WARNING: Kubernetes configuration file is group-readable. This is insecure. Location: /root/installation_directory/auth/kubeconfig
version.BuildInfo{Version:"v3.12.0", GitCommit:"c9f554d75773799f72ceef38c51210f1842a1dea", GitTreeState:"clean", GoVersion:"go1.20.3"}

다음과 같이 출력되는 PV 를 삭제하려고 합니다.

# oc get pv
NAME         CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS        CLAIM                    STORAGECLASS   REASON   AGE
pv-example   1Gi        RWO            Retain           Terminating   project412/pvc-example   standard                17h

PV 를 삭제할때 아래와 같이 메세지 출력 후 한참동안 쉘 프롬프트가 출력되지 않는다면

# oc delete pv pv-example
persistentvolume "pv-example" deleted

^C[root@ocp ~]# 

연결된 PVC 정보를 확인해봐야 합니다.

# oc get pv pv-example -o jsonpath='{.spec.claimRef.name}' | xargs -n1 oc get pvc
NAME          STATUS   VOLUME       CAPACITY   ACCESS MODES   STORAGECLASS   AGE
pvc-example   Bound    pv-example   1Gi        RWO            standard       17h

연결된 PVC 가 확인되어 삭제를 선진행하고 PV 를 삭제하면 깔끔히 제거됩니다.

# oc delete pvc pvc-example
persistentvolumeclaim "pvc-example" deleted

# oc delete pv pv-example
persistentvolume "pv-example" deleted

한번 가동된 Pod (Container) 에서 데이터 입력, 수정, 삭제 등의 작업 후 중지, 재시작을 하게 되면 그동안 작업한 모든 데이터는 날아갑니다.

때문에 Volume 을 특정 디렉토리로 마운트 하고 사용하면 해당 디렉토리의 파일은 컨테이너가 중지 되어도 데이터가 유지되는데요.

데이터 유지와 용량 증설 목적을 가지는 Volume 을 어떻게 설정하고 사용하는지 예제를 통해 알아보도록 하겠습니다.

이 예제는 Deployment 오브젝트를 통해 Python 애플리케이션을 배포하고, Persistent Volume Claim (PVC) 을 사용하여 데이터를 보관하기 위한 Volume 1Gi 를 생성, 컨테이너의 /data 디렉토리에 연결하는 것을 보여주고 있습니다.

1. 설명

본 매뉴얼 하단부에서 소개될 yaml 파일과 옵션에 대한 설명으로 시작하겠습니다.

1) PV 와 PVC

PersistentVolume (PV) 은 클러스터 레벨에서 관리되는 볼륨이며 스토리지 저장소라고 생각하면 이해가 쉽습니다. 

PersistentVolume (PV) 과 PersistentVolumeClaim (PVC) 은 1:1 매칭이 가장 일반적인 사용 방식입니다.

즉, 하나의 PV 는 하나의 PVC 와 바인딩됩니다. 이는 PV 가 실제 스토리지 리소스를 나타내고, PVC 가 해당 스토리지 리소스에 대한 요청을 표현하기 때문입니다.
하지만 1:n 매핑도 가능합니다. 즉, 하나의 PV 가 여러 개의 PVC 와 바인딩될 수 있습니다. 이 경우 PVC 는 동일한 PV 의 스토리지를 공유하게 됩니다. 이는 여러 개의 애플리케이션이 동일한 스토리지를 사용해야 하는 경우에 유용할 수 있습니다.

대신 1:n 매핑을 위해서는 다음 사항을 고려해야 합니다.
- PV 와 PVC 의 스토리지 클래스 이름 (storageClassName) 이 일치해야 합니다.
- PV 의 용량은 PVC 들이 요청한 총 용량 이상이어야 합니다.
- PVC 의 액세스 모드 (accessModes) 가 PV 의 액세스 모드와 호환되어야 합니다.

  예를 들어 PV 의 액세스 모드가 ReadWriteOnce 이면, PVC 액세스 모드가 ReadWriteOnce 이여야 합니다.

1:n 매핑은 특정 상황에서 유용할 수 있지만, 주의할 점도 있습니다. 여러 PVC 가 동일한 스토리지를 공유하게 되므로 애플리케이션 간의 스토리지 충돌이 발생할 수 있습니다. 따라서 신중하게 구성해야 합니다.

2) accessModes

위에서 말한 액세스 모드 (accessModes) 는 PersistentVolumeClaim (PVC) 에서 지정하는 볼륨의 액세스 모드를 정의합니다. accessModes 필드는 다음과 같은 값을 가질 수 있습니다.

- ReadWriteOnce (RWO) : 단일 노드에서 읽기/쓰기 액세스를 지원
- ReadOnlyMany (ROX) : 여러 노드에서 읽기 전용 액세스를 지원 (동시 마운트 가능)
- ReadWriteMany (RWX) : 여러 노드에서 읽기/쓰기 액세스를 지원 (동시 마운트 가능)

액세스 모드는 PVC 에서 요청한 볼륨을 할당할 때 PersistentVolume (PV) 의 액세스 모드와 일치해야 합니다. PV 의 액세스 모드는 볼륨이 생성될 때 설정되며 PVC 와 일치하지 않는 경우 PVC 는 해당 PV 에 바인딩될 수 없습니다.

3) persistentVolumeReclaimPolicy

persistentVolumeReclaimPolicy 는 PV 에서 사용되는 속성입니다. 이 속성은 PV 와 연결된 PVC 가 삭제될 때 PV 에서 어떻게 처리할지를 지정합니다. 사용 가능한 옵션은 아래와 같습니다.

- Retain : PV 데이터를 그대로 보존
- Recycle : PV 데이터를 모두 삭제 후 재사용 
- Delete : 사용 종료시 삭제 

4) Volume 유형

PV 에서 구성 가능한 Volume 유형은 여러가지가 있습니다.

볼륨을 로컬 디스크에서 생성할 수 있는 emptyDir 과 hostPath 가 있으며, 전용 스토리지를 이용한 NFS 등의 연결도 가능합니다.

- emptyDir : Pod 내에 존재하는 볼륨입니다.

                    emptyDir 은 Pod 가 생성될 때 생성되며 Pod 의 수명 동안 유지됩니다.

                    (단점) 때문에 Pod 가 삭제되면 emptyDir 에 저장된 모든 데이터가 사라집니다.
                    노드의 로컬 디스크에 생성되며 여러 Pod 들 사이에서 데이터를 공유할 목적으로 사용될 수 있습니다.
- hostPath : 호스트 노드 내에 존재하는 볼륨입니다.

                    hostPath 를 사용하면 Pod 내부의 컨테이너가 호스트 노드의 파일 시스템에 직접 액세스할 수 있습니다.

                    때문에 Pod 가 삭제되어도 볼륨의 데이터는 삭제되지 않습니다.

                    여러 컨테이너가 동일한 hostPath를 공유할 수 있습니다.

                    (단점) Worker node 가 여러개일때, Pod 가 재생성되면 다른 노드에 Pod 가 생성되므로 기존 노드의 볼륨 사용 불가

- PV, PVC : '1)' 에서 소개된 내용과 동일합니다.

                    전용 스토리지를 이용하여 Pod 에 영속성 있는 볼륨을 제공합니다. (Local Disk 또는 외부 Storage 원격 연결 가능)
                    Pod 는 이러한 PV 에 바로 연결하지 않고 PVC 를 통하여 연결됩니다.

2. NFS Volume 생성

본 예제는 PV, PVC 볼륨 유형으로 작성된 NFS 활용 예제입니다.

1) PV 생성

다음은 PersistentVolume (PV) 을 생성하는 yaml 파일입니다.

여기에서는 PV 와 PVC 의 용량을 1:1 매칭으로 구성하였습니다.

# vi pv.yaml

작성한 yaml 파일을 적용하여 PV 를 생성합니다.

# oc apply -f pv.yaml
persistentvolume/pv-example created

생성된 PV 를 확인합니다.

# oc get pv
NAME         CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
pv-example   1Gi        RWO            Retain           Available           standard                6s

2) PVC 생성

PersistentVolumeClaim (PVC) yaml 파일을 작성합니다.

# vi pvc.yaml

작성한 yaml 파일을 적용하여 PVC 를 생성합니다.

# oc apply -f pvc.yaml

persistentvolumeclaim/pvc-example created

생성된 PVC 를 확인합니다.

# oc get pvc
NAME          STATUS    VOLUME       CAPACITY   ACCESS MODES   STORAGECLASS   AGE
pvc-example   Bound     pv-example   1Gi        RWO            standard       12s

3) Pod 생성 및 Volume 연결

Pod yaml 를 생성하여 볼륨을 붙일 수 있지만 본 예제에서는 Deployment 를 이용해 Pod 를 생성해 보겠습니다.

# vi deployment_volume.yaml

위에서 imagePullSecrets 는 이미지를 Registry 에서 다운로드 하기위해 만든 secret 입니다.

claimName 에는 PVC 이름을 넣고, volumeMounts: name: 은 volumes: name: 이름과 동일하게 해주어야 합니다.

작성한 yaml 파일을 적용하여 Pod 를 생성합니다.

# oc apply -f deployment_volume.yaml

deployment.apps/app-example created

생성된 Pod 를 확인합니다.

# oc get pod
NAME                      READY   STATUS    RESTARTS   AGE
app-example-5589d49b8d-j77kc   1/1     Running   0          4s

4) 마운트 확인

/data 에 저장된 데이터가 유지되고, 용량이 1Gi 로 제한 되고 있는지 확인해봅니다.

(NFS 서버에서)

테스트 파일을 하나 만들었습니다.

# ll /data
합계 4
-rw-r--r-- 1 root root 3  5월 12 15:16 test.txt

(Pod 에서)

Pod 이름을 확인하고 쉘 접속을 합니다.

# oc get pod
NAME                      READY   STATUS    RESTARTS   AGE
app-example-5589d49b8d-j77kc   1/1     Running   0          90s

# oc rsh app-example-5589d49b8d-j77kc

마운트 디렉토리로 이동합니다.

$ cd /data_client

디렉토리를 만들지 않아도 deployment yaml 에 지정한 디렉토리가 자동 생성되어 있습니다.
$ pwd
/data_client

NFS 서버에서 생성한 파일이 보이는 것을 확인하였습니다.
$ ls -al
total 4
drwxr-xr-x. 2 root root 21 May 12 06:16 .
dr-xr-xr-x. 1 root root 47 May 12 07:31 ..
-rw-r--r--. 1 root root  3 May 12 06:16 test.txt

* 참고

Pod 에서 보이는 시간이 국제 표준시로 출력됩니다. (한국보다 9시간 느림)

일단 넘어가고, 추후에 한국 시간으로 출력하는 방법을 찾으면 업데이트 하겠습니다.

컨테이너에 외부 접근을 가능하게 하려면  라우트 (route) 를 생성하면 됩니다.

하지만 기본 라우트 도메인은 Pod 이름과 클러스터명을 기반으로 생성됩니다.

형식) <route명>-<프로젝트명>.apps.<클러스터명>

결과) python-sample-project412.apps.az1.sysdocu.kr

1. Ingress 생성

별도의 도메인을 추가하여 접근 가능하도록 하는 방법은 Ingress 를 생성하는 방법입니다.

Ingress 생성시 Route 경로가 추가 생성됩니다. 마찬가지로 Ingress 삭제시 함께 생성되었던 Route 도 같이 삭제 됩니다.

예제는 도메인 두개를 더 추가하는 방법으로 진행했으며, 아래 내용으로 Ingress yaml 파일을 작성하였습니다.

서비스 이름과 포트는 oc get service 명령으로 확인해서 입력해줘야 합니다.

# vi ingress.yaml

작성한 파일을 적용합니다.

# oc apply -f ingress.yaml

ingress.networking.k8s.io/python-sample created

Ingress 생성을 확인합니다.

# oc get ingress

NAME            CLASS    HOSTS                       ADDRESS                            PORTS   AGE
python-sample      sysdocu.kr,www.sysdocu.kr router-default.apps.az1.sysdocu.kr   80      20s

추가된 Route 를 확인합니다.

# oc get route
NAME                  HOST/PORT                                    PATH   SERVICES        PORT            TERMINATION   WILDCARD
python-sample         python-sample-project412.apps.az1.sysdocu.kr          python-sample   8080                          None
python-sample-2ktlf   sysdocu.kr                                   /      python-sample   python-sample                 None
python-sample-rg89r   www.sysdocu.kr /      python-sample   python-sample                 None

이제 추가된 도메인으로 컨테이너 접근이 가능하지만

외부 DNS 에 해당 서버 IP 로 연결이 되어 있는지 확인해 봐야 합니다.

2. SSL 인증서 추가

인증서를 사용하는 프로토콜로 연결하기 위해서는 SSL 인증서를 발급받은 후에 OCP 서버에서 secret 을 생성해야 합니다.

무료 SSL 인증서 발급은 별도의 포스팅을 확인해주세요.

- https://sysdocu.tistory.com/1546

- https://sysdocu.tistory.com/1730

- https://sysdocu.tistory.com/1781

secret 생성시 인증서 경로를 지정합니다.

# oc create secret tls sysdocussl --cert=/root/ssl/cert1.pem --key=/root/ssl/privkey1.pem

secret/sysdocussl created

위에서 테스트 했던 Ingress 삭제 후 아래 내용으로 yaml 파일을 다시 작성하였습니다.

작성할때 서비스 이름과 포트는 oc get service 명령으로 확인해서 입력해줘야 합니다.

# oc delete ingress python-sample

# vi ingress.yaml

작성된 yaml 파일을 적용합니다.

# oc apply -f ingress.yaml

ingress.networking.k8s.io/python-sample created

Ingress 생성을 확인합니다.

# oc get ingress
NAME            CLASS    HOSTS            ADDRESS                            PORTS     AGE
python-sample   <none>   www.sysdocu.kr router-default.apps.az1.sysdocu.kr   80, 443   87s

추가된 Route 를 확인합니다.

# oc get route
NAME                  HOST/PORT                                    PATH   SERVICES        PORT            TERMINATION     WILDCARD
python-sample         python-sample-project412.apps.az1.sysdocu.kr          python-sample   8080                            None
python-sample-cq6w6   www.sysdocu.kr /      python-sample   python-sample   edge/Redirect   None

이제 웹브라우저에서 추가된 도메인으로 접속하면 SSL 인증서 확인이 가능합니다.

https://www.sysdocu.kr

1. Openshift 에서 Service 와 Route 의 차이점

1) 서비스 (Service)

노출된 서비스에 대한 내부 클러스터 IP를 생성하고, 클러스터 내에서 해당 서비스를 사용할 수 있는 DNS 이름을 제공합니다.

서비스는 이러한 내부 IP 및 DNS 이름을 사용하여, 클러스터 내에서 포드(Pod) 간 통신을 할 수 있도록 합니다.

2) 라우트 (Route)

서비스를 클러스터 외부로 노출시키는 방법 중 하나입니다. 라우트는 클러스터 내부의 서비스를 외부에서 접근 가능한 URL로 노출시키는 역할을 합니다. 라우트를 생성하면 외부에서 해당 URL로 접근할 수 있으며, 이를 통해 클러스터 내부에 있는 서비스를 사용할 수 있습니다.

3) 정리
간단하게 말하자면 아래와 같습니다.

- 서비스 : 클러스터 내에서 포드 간 통신을 위한 논리적인 개념

- 라우트 : 외부에서 클러스터 내부의 서비스에 접근하기 위한 논리적인 개념
- 사용법 : 클러스터 내부에서만 사용해야 하는 서비스의 경우에는 서비스만 생성하고, 외부에서 접근이 필요한 경우에는 라우트를 생성하면 됩니다.

- 생성 순서 : 라우트는 서비스가 존재해야 생성 가능합니다. 서비스가 없다면 먼저 서비스를 생성해주어야 합니다.

2. Openshift 에서 Ingress 와 Route 의 차이점

1) 인그레스 (Ingress)

클러스터 외부에서 내부로 들어오는 네트워크 트래픽을 컨트롤러가 실행 중인 서비스로 라우팅하는 방법을 정의하는 API 오브젝트입니다.

Ingress 는 일반적으로 http(s) 요청을 처리하며 http(s) 요청을 서비스로 라우팅하고 SSL 암호화 및 트래픽 로드밸런싱과 같은 기능을 제공합니다. 따라서 Ingress 는 외부에서 클러스터로의 트래픽을 효과적으로 관리하고 컨트롤할 수 있도록 도와줍니다.

2) 라우트 (Route)

서비스를 클러스터 외부로 노출시키는 방법 중 하나입니다. 라우트는 클러스터 내부의 서비스를 외부에서 접근 가능한 URL로 노출시키는 역할을 합니다. 라우트를 생성하면 외부에서 해당 URL로 접근할 수 있으며, 이를 통해 클러스터 내부에 있는 서비스를 사용할 수 있습니다.

3) 비교

Ingress 와 Route 는 둘 다 클러스터 외부에서 클러스터 내부에 있는 서비스에 접근할 수 있도록 해주는 기능을 제공합니다.

다음은 Ingress 와 Route 의 차이점입니다.

- Ingress 는 http 와 https 프로토콜을 지원하고 Route 는 http, https, TLS 등 다양한 프로토콜을 지원합니다.
- Ingress 는 클러스터 레벨에서 관리하며, Route 는 프로젝트 내에서 관리됩니다.
- Ingress 는 Nginx, Traefik, Istio 등과 같은 인그레스 컨트롤러를 사용하여 구현되며, Route 는 OpenShift Router 를 사용하여 구현됩니다.
- Ingress 는 서비스의 라벨 셀렉터를 기반으로 경로를 분배하며, Route 는 서비스를 기반으로 경로를 분배합니다.

  또한 Route 는 서비스 포트와 경로를 연결하여 사용자가 노출시키려는 서비스를 선택할 수 있습니다.
- Ingress 는 기본적으로 Kubernetes API 오브젝트이며, Route 는 Openshift API 오브젝트입니다.

따라서 Ingress와 Route는 비슷한 역할을 하지만, 세부적인 구현 방식과 관리 방법에서 차이가 있습니다.

Openshift 에서는 프로젝트를 만들기 위한 명령어 oc new-project 와 oc create ns (namespace) 를 제공하고 있으며 이 두 명령어는 기본적으로 동일한 결과를 가져옵니다.

모두 새로운 프로젝트 (Project) / 네임스페이스 (Namespace) 를 생성하는 명령어로 사용법도 거의 동일합니다.

다만 "oc new-project" 명령어는 프로젝트 (Project) 를 생성할 때 기본적으로 몇 가지 설정 값을 지정해 줍니다.

예를 들어, "oc new-project" 명령어는 프로젝트 (Project) 에 대한 일부 RBAC (Role-Based Access Control) 권한을 생성하고, 프로젝트 (Project) 를 위한 라벨 (label) 을 자동으로 추가합니다.

반면에 "oc create ns" 명령어는 단순히 네임스페이스 (Namespace) 를 생성하는 명령어로, 추가적인 설정이나 라벨 (label) 을 지정하지 않습니다.

따라서 두 명령어를 사용하는 것은 개인적인 선호나 상황에 따라 다를 수 있지만, 일반적으로는 두 명령어 모두 같은 결과를 가져오며, 기능적인 차이는 크지 않습니다.

[명령어로 확인하기]

1) 생성

# oc new-project cdh1
Now using project "cdh1" on server "https://api.az1.sysdocu.kr:6443".

You can add applications to this project with the 'new-app' command. For example, try:

    oc new-app rails-postgresql-example

to build a new example application in Ruby. Or use kubectl to deploy a simple Kubernetes application:

    kubectl create deployment hello-node --image=k8s.gcr.io/e2e-test-images/agnhost:2.33 -- /agnhost serve-hostname

# oc create ns cdh2
namespace/cdh2 created

2) RoleBinding 확인

파란색 부분에서 차이가 보입니다.

# oc get rolebinding -n cdh1
NAME                    ROLE                               AGE
admin                   ClusterRole/admin                  5m52s
system:deployers        ClusterRole/system:deployer        5m51s
system:image-builders   ClusterRole/system:image-builder   5m51s
system:image-pullers    ClusterRole/system:image-puller    5m51s

# oc get rolebinding -n cdh2
NAME                    ROLE                               AGE
system:deployers        ClusterRole/system:deployer        5m45s
system:image-builders   ClusterRole/system:image-builder   5m45s
system:image-pullers    ClusterRole/system:image-puller    5m45s

3) Project 속성 확인

파란색 부분에서 차이가 보입니다.

# oc describe ns cdh1
Name:         cdh1
Labels:       kubernetes.io/metadata.name=cdh1
              pod-security.kubernetes.io/audit=restricted
              pod-security.kubernetes.io/audit-version=v1.24
              pod-security.kubernetes.io/warn=restricted
              pod-security.kubernetes.io/warn-version=v1.24
Annotations:  openshift.io/description: 
              openshift.io/display-name: 
              openshift.io/requester: system:admin
              openshift.io/sa.scc.mcs: s0:c27,c9
              openshift.io/sa.scc.supplemental-groups: 1000720000/10000
              openshift.io/sa.scc.uid-range: 1000720000/10000
Status:       Active

No resource quota.

No LimitRange resource.

# oc describe ns cdh2
Name:         cdh2
Labels:       kubernetes.io/metadata.name=cdh2
              pod-security.kubernetes.io/audit=restricted
              pod-security.kubernetes.io/audit-version=v1.24
              pod-security.kubernetes.io/warn=restricted
              pod-security.kubernetes.io/warn-version=v1.24
Annotations:  openshift.io/sa.scc.mcs: s0:c27,c14
              openshift.io/sa.scc.supplemental-groups: 1000730000/10000
              openshift.io/sa.scc.uid-range: 1000730000/10000
Status:       Active

No resource quota.

No LimitRange resource.