MSFL :: 모리스 소프트웨어 공작소

# Kubernetes의 확장인 CRD Custom Resource Definition 와 CR Custom Resource 에 대한 개념 정리 기존에 [Kubernetes 상의 Operator 나름대로 정리](https://ccambo.blogspot.com/2020/12/kubernetes-operator-kubernetes-operator.html) 라는 게시글을 작성했다. 게시글 자체는 Operator를 설명하기 위한 내용이었는데, 댓글로 문의를 주신 분들의 의문점들을 살펴보니 Operator의 관점에서 바라봤을 때 CRD와 CR에 대한 실체들에 대한 궁금점들이었기 때문에 근본적인 내용을 설명하는 것이 좋을 것 같아서 이 게시글을 작성한다. ## Kubernetes의 기본적 동작 원리 Kubernetes 구성에 대한 자세한 내용은 [Kubernetes Components](https://kubernetes.io/ko/docs/concepts/overview/components/) 참고 - **Kubernetes는 상태관리 시스템** 이다.예를 들어 Replica를 3이라고 지정하면 Kubernetes가 Deployment 요청을 받았을 때 Replica 개수를 확인하고 Pod를 3개 실행시키려고 한다. 즉, `처음 배포되면 사용자가 정의한 Replica 값이 Pod 실행 개수라는 상태 값`이 된다는 것이다. - 운영 중에 3개의 Pod 중에 1개 Pod가 오류로 중지되면 Kubernetes 입장에서는 3개가 유지 (Desired State) 되어야 하는 상태인데, 현재 상태는 2개 (Current State) 가 되므로 이를 다시 3개로 만들려고 액션을 취하게 된다. - 아주 간단한 예는 실행될 Pod의 개수를 의미하는 Replicas 설정이라고 생각하면 된다. 보통 애플리케이션을 작성하고 컨테이너 이미지를 만들고 Kubernetes에 실행을 맡기기 위해 Deployment Spec에 애플리케이션 정보 뿐만 아니라 R

# How to force deletion of pods on namespace ## 문제 상황 이전 게시글인 [삭제되지 않는 네임스페이스 Namespace 강제로 삭제하기](https://ccambo.blogspot.com/2021/01/kubernetes-troubleshooting-namespace.html) 를 통해 네임스페이를 삭제하는 방법을 알아 보았다. 이번 경우는 확실하게 눈으로 확인할 수 있는 파드 Pod 들이 남아 있고 `Terminating` 상태로 삭제되지 않는 문제가 발생했다. 테스트 했던 M3 오퍼레이터 Operator 를 장시간 유지하면서 etcd 클러스터가 응답하지 않는 상태가 발생했고, 삭제를 했지만 삭제되지 않는 문제인 상태다. ```bash $ kubectl -n m3cluster get pods NAME READY STATUS RESTARTS AGE ... etcd-0 1/1 Terminating 2 16d etcd-1 1/1 Terminating 2 16d etcd-2 1/1 Terminating 2 16d ... ``` ## 문제 원인 확인과 처리 방법 정상적으로 삭제될 수 있는 시간을 지나서도 `Terminating` 상태로 남아있는 상태는 대부분은 아래와 같은 원인으로 발생한다. - 파드에 처리되지 않는 파이널라이저 Finalizer 가 연결된 경우 - 파드가 종료 시그널에 응답하지 않는 경우 이런 상황에서 정보를 확인해야 한다. 1. **정보 출력** ```bash $ kubectl -n get pod -p -o yml [> undeleted_pod.yaml] ``` 화면에 출력을 사용하던지 아니면 화일로 출력해서 내용 중에서 `status` 부분과 `metadata.finalizer` 내용을 검토한다. 2. **파이널라이저 확인** st

# 정상적으로 동작하던 Dynamic NFS Provisioning에서 오류가 발생하는 문제 해결 > **참고** > > --- > > 쿠버네티스 Kubernetes 클러스터에 동적으로 NFS Network File System Provisioning 에 대한 글은 아래 게시글 참고 > > - [CentOS 8에 NFS 구성하기](https://ccambo.blogspot.com/2020/12/centos-nfs-centos-8-nfs.html) > - [Kubernetes Cluster에 NFS 기반의 Dynamic Storage Provision 설정하기](https://ccambo.blogspot.com/2021/01/kubernetes-storage-centos-8-dynamic-nfs.html) ## 상황 위의 게시글을 기준으로 NFS Provisioning 을 잘 사용하고 있었다. 추가로 쿠버네티스 클러스터를 구성해서 테스트를 해야하는 작업이 생겼고, 최신 버전의 쿠버네티스로 설치를 진행했다. 동일하게 NFS Provisioning 설정을 했고, 애플리케이션을 배포했을 때 계속 `Pending` 상태로 진행되지 않는 상황이 발생해서 로그 정보들을 통해서 검증하기 시작했다. 결론은 아래와 같이 `nfs-client-provisioner` 파드에서 오류가 발생하는 것으로 확인할 수 있었다. ```bash 2021-06-09T06:31:34.335294986Z E0609 06:31:34.335012 1 controller.go:682] Error watching for provisioning success, can't provision for claim "default/test-web-0": events is forbidden: User "system:serviceaccount:default:nfs-provisioner" cannot list

# Docker를 사용하지 않고 Containerd 기반의 Kubernetes Cluster를 CentOS 8 에 kubeadm으로 설치하기 CentOS 8 버전부터 도커 Docker 는 레드햇의 도구인 `podman, buildah` 로 대체된 상태로 기본 패키지 저장소에서 제거되었고, API를 사용해서 처리되는 것이기 때문에 특정 툴에 한정될 필요가 없다. 현재 제공되고 있는 컨테이너 런타임 Container Runtime 은 다음과 같다. - [Docker](https://kubernetes.io/docs/setup/production-environment/container-runtimes/#docker) - [CRI-O](https://kubernetes.io/docs/setup/production-environment/container-runtimes/#cri-o) - [Containerd](https://kubernetes.io/docs/setup/production-environment/container-runtimes/#containerd) 이 문서는 containerd를 사용해서 클러스터를 구성한다. - 1개의 마스터 노드와 3개의 워커 노드 모두 CentOS 8 설치 - 각 노드는 2G RAM, 2 CPU 를 최소 사양으로 한다. - 모든 노드는 저장소에서 쿠버네티스 Kubernetes 및 기타 필수 패키지를 설치할 수 있도록 인터넷에 연결이 가능해야 하고, dnf 패키지 관리자를 사용할 수 있으며 원격으로 패키지를 가져올 수 있는지 검증되어야 한다. > **설치환경 요약** > > 쿠버네티스의 `최소 요구 사항은 2G RAM, 2 CPU` 를 기준으로 한다. > > - Master > - CentOS 8.2.2004 > - monitor.master > - centos > - Worker > - CentOS 8.2.2004 > - monitor.wo

# How to force deletion of a namespace ## 문제 상황 Argo Project의 Argo Events를 테스트해 보기 위해서 여러 가지 작업을 하던 중 제대로 처리가 되지 않아서 다시 시작할 겸 Namespace를 삭제해서 소속된 리소스들을 모두 삭제했다.  그런데 위의 그림처럼 Argo Events Namespace가 삭제되지 않고 `Terminating` 상태로 계속 유지되는 문제가 발생했다. ## 문제 원인 정상적으로 삭제될 수 있는 시간을 지나서도 `Terminating` 상태로 남아있어서 원인에 대한 부분을 찾다가 Namespace의 다른 모든 Resource들은 삭제되었는데 (정확하게는 Dashboard에도 조회가 되지 않고, kubectl get 명령으로도 보이지 않는) Namespace만 저런 상태라서 Namespace에 대한 정보를 출력해 보았다. ```bash # Resource 정보 출력 $ kubectl get namespace argo-events -o yaml apiVersion: v1 kind: Namespace metadata: creationTimestamp: "2021-01-13T10:40:07Z" deletionTimestamp: "2021-01-15T09:31:30Z" ... spec: finalizers: - kubernetes # Namespace에 대한 Finalizers status: conditions: - lastTransitionTime: "2021-01-15T09:31:36Z" message: All resources successfully discover

How to building real world sample step by step - Part 3 게시글 참고 이 게시글은 KUDO Blog 샘플을 기준으로 테스트하면서 발생한 문제점들을 처리하고 동작을 검증하면서 정리한 내용입니다. PART 1 에서는 부트스트랩 노드 구성 PART 2 에서는 클러스터에 노드들이 참여할 떄 사용할 서비스와 설정등을 구성하고 StatefulSet을 구성 이 문서는 KUDO Blog 샘플을 기준으로 테스트하면서 발생한 문제점들을 해결하고 동작을 검증하면서 정리한 내용으로 구성된 Galera Cluster의 사용하지 않는 bootstrap 정보를 제거하고, 외부 연결을 위한 서비스 생성 및 서비스의 중단없이 Scale Up/Down 할 수 있도록 나머지 부분을 적용해 본다. 이 과정까지 완료되면 프로덕션 환경에 적용할 수 있는 정도가 된다. Cleanup bootstrap node PART 2 에서 모든 노드들을 클러스터에 참여시켰기 때문에 더 이상은 부트스트랩 노드가 필요하지 않다. 따라서 operator.yaml 에 부트스트랩 노드와 관련된 리소스를 제거하는 Step과 Task를 추가하도록 한다. ... plans: deploy: strategy: serial phases: - name: deploy strategy: serial steps: ... - name: cleanup # 추가 tasks: - bootstrap_cleanup tasks: ... - name: bootstrap_cleanup # 추가 kind: Delete spec: resources: - bootstrap_deploy.yaml - bootstrap_service.yaml - bootstrap_confi

How to building real world sample step by step - Part 2 게시글 참고 이 게시글은 KUDO Blog 샘플을 기준으로 테스트하면서 발생한 문제점들을 처리하고 동작을 검증하면서 정리한 내용입니다. PART 1 에서는 부트스트랩 노드 구성 PART 3 에서는 사용하지 않는 부트스트랩을 제거하고, 외부 접속을 위한 서비스를 생성하며, 안전한 Scale Up/Down 처리 구성 이 문서는 KUDO Blog 샘플을 기준으로 테스트하면서 발생한 문제점들을 해결하고 동작을 검증하면서 정리한 내용으로 초기 구성된 Galera Cluster의 부트스트랩을 이용해서 클러스터에 노드들이 참여할 떄 사용할 서비스와 설정등을 구성하고 StatefulSet을 구성하는 방법을 정리한다. Cluster에 참여하는 Node를 위한 초기 설정 구성 operator.yaml 파일에 아래와 같이 firstboot_config 라는 Step과 Task를 추가하도록 한다. apiVersion: kudo.dev/v1beta1 appVersion: 0.1.0 kubernetesVersion: 0.16.0 kudoVersion: 0.17.2 maintainers: - email: ccambo@gmail.com name: ccambo name: galera-operator operatorVersion: 0.1.0 plans: deploy: strategy: serial phases: - name: deploy strategy: serial steps: - name: bootstrap_config tasks: - bootstrap_config - name: bootstrap_service tasks: - bootstrap_service -

[Kubernetes - Storage] How to configure a dynamic storage provisioner for Kubernetes using a network file system on CentOS 8 참고 이 문서는 Network File System을 CentOS 8에 설치하여 NFS Server로 운영하면서 Kubernetes의 PVC (Perssistent Volume Claim) - StorageClass - NFS 로 연동되는 PV (Persistent Volume)를 자동으로 구성하는 방법을 정리한 것입니다. CentOS 8에 설치되는 NFS를 Kubernetes의 Dynamic Storage Provisioning 으로 활용해서 PV (Persistent Volume)를 구성해 본다. Network file system 구성 NFS 서버를 구성하는 부분은 CentOS 8에 NFS 설정 및 테스트 글을 참고해서 진행하도록 한다. NFS 서버는 물리적인 머신으로 네트워크 상에 존재하면 되며, Network을 통해서 Kubernetes Cluster에서 NFS 서버로 접근할 수 있어야 한다. 위에서 구성한 NFS 서버를 사용할 수 있도록 처리하는 NFS Provisioner Pod가 Kubernetes Cluster에 PV를 배포할 수 있도록 하기 위해서는 필요한 권한 설정이 필요하다. 따라서 PV를 배포할 수 있도록 ClusterRole, ClusterRoleBinding, Role, RoleBinding 설정을 가지는 Service Account를 생성해 줘야 한다. Service Account 생성 서비스 계정을 생성한다. (serviceaccount.yaml) apiVersion: v1 kind: ServiceAccount metadata: name: nfs-provisioner 아래의 명령을 사용해서 Kubernetes에 적용한다. $ kubectl apply -f serviceaccount