기본 콘텐츠로 건너뛰기

Kubernetes 확장인 CRD와 CR 에 대한 개념 정리

# 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
최근 글

[kubernetes-troubleshooting] Namespace 삭제 명령에도 삭제되지 않는 Pod 삭제하기

# 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

[Kubernetes-Storage] 정상적으로 동작하던 Dynamic NFS Provisioner 오류 해결하기 (SelfLink 관련)

# 정상적으로 동작하던 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

[Kubernetes] kubeadm 으로 ContainerD 기반 K8S Cluster를 CentOS 8 설치하기 (Docker 사용하지 않음)

# 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

[MacOS] 특정 경로 밑의 디렉터리 일괄 삭제하기

How to remove directories from Mac Mac의 임시 파일들을 삭제하는 방법을 게시했던 ._xxx, .DS_Store 등 숨김파일 정리 및 .gitignore 처리하기 에서 언급했던 방식을 응용해서 Node 기반의 개발에서 사용했던 node_modules 디렉터리를 일괄 삭제하는 방법을 정리해 본다. 개발하면서 참조한 소스들, 개발한 소스들이 많기 때문에 특정 경로 이하의 모든 node_modules 들을 찾아서 삭제하는 것보다는 일괄적으로 삭제 하기 위해서 find 명령을 사용하면 된다. $ find . -name "node_modules" -type d -prune -print -exec rm -rf '{}' + find . : 현재 경로를 루트 경로로 설정하고 검색 -name "node_modules" : "node_modules"라는 이름을 지정 -type d : 지정한 이름의 디렉터리만 찾도록 지정 -prune : "node_modules"가 발견되면 그 경로 하위로 내려가지 않도록 지정 -print : 검색된 대상의 경로 출력하도록 지정 -exec rm -rf '{}' + : 일치된 결과에 대한 삭제 처리를 수행하는데, {} + 는 마지막에 선택한 이름을 추가해서 명령줄을 빌드하도록 하는 것으로 전체 발견된 "node_modules"의 수보다 적은 횟수로 호출할 수 있도록 조정하는 것으로 성능 향상을 위한 것이다. 무조건 실행되면 다시 복구할 수 없는 상태 가 되므로 아래의 명령으로 실제 대상들이 제대로 검색되는지를 먼저 확인하고 진행하도록 한다. $ find . -name "node_modules" -type d -prune -print | xargs du -chs 254M ./K3Lab/RNDWorks/apigw/samples/etri/web/node_

[MacOS] Terminal 에서 zsh compinit: insecure directories 문구가 발생하는 경우 대처하기

How to set compinit mode on zsh KinD (Kubernetes in Docker)로 MacOS 상에 Multi-Nodes Kubernetes Cluster를 구성 하면서 kubectl autocomplete를 설정했는데 아래와 같은 메시지가 터미널 실행 시에 계속 나타나는 문제가 발생했다. zsh compinit: insecure directories, run compaudit for list. Ignore insecure directories and continue [y] or abort compinit [n]? 정보를 찾아보니 대 부분 zsh와 관련된 소유권 문제를 많이 이야기하고 있었다. 즉, 외부의 패키지나 라이브러리 등을 설치할 떄 외부의 스크립트를 사용할 경우에 /usr/local/share 폴더의 소유권과 권한이 변경 되는 문제로 발생한다는 것이다. 상황을 확인해 보기 위해서 아래의 명령을 수행한다. $ compaudit There are insecure directories: /usr/local/share 또는 There are insecure directories: /usr/local/share/zsh/.site-functions /usr/local/share/zsh 위의 같은 결과를 확인할 수 있다. 결과를 바로 소유권 및 권한 처리를 하는 방법은 다음과 같다. # 검증 및 변경 처리 $ compaudit | xargs chmod g-w # 재 검증 $ compaudit There are insecure directories: 위의 방법이 아니라 개별적으로 처리하는 경우는 다음과 같다. /usr/local/share/zsh/.site-functions 가 나온 경우 $ cd /usr/local/share/zsh $ sudo chown -R root:root ./site_functions /usr/local/share 가 나온 경우 $ cd /usr/local/share/

[MacOS,Git] ._, .DS_Store 등 숨김파일 정리 및 .gitignore 처리하기

How to remove temporary hidden files like .DS_Store / ._xxxx Remove ._xxxx files MacOS에서 여러 작업을 하다보면 ._ 으로 시작하는 파일들이 생성된 것을 확인할 수 있다. (일반적으로 숨김 파일들이라 보이지 않는다) 이런 파일은 다양한 작업 중에 생성되는데 일반적인 상황은 다음과 같다. MacOS HDD/SDD에서 외장 HDD/SDD로 복사했을 때 MacOS에서 압축했을 때 더 많은 상황이 있을 수 있지만 결국은 다른 플랫폼 (또는 다른 FileSystem)과 혼용할 경우에 아이콘을 생성하기 위해 파일을 가져오는 과정에서 메타정보 저장용으로 자동 생성된다. 이런 파일의 생성과 제거는 다음과 같은 방법들이 존재한다. 압축하는 경우라면 다른 플랫폼에서 이런 파일들이 유지되지 않도록 COPYFILE_DISABLE 설정을 하면 된다. # 압축 명령에서 사용해서 tar가 메타 정보를 추가하지 않도록 설정 $ COPYFILE_DISABLE=1 tar -cf xxxx.tar file* 매번 이렇게 처리하는 것이 귀찮다면 아예 shell에 설정하는 것도 가능하다. # ~/.zshrc 또는 ~/.bash_profile, .... ... COPYFILE_DISABLE=1; export COPYFILE_DISABLE ... 이미 파일이 존재하는 경우라면 일괄 삭제할 수 있다. $ find ./ -name ._\* -delete Git에서 MacOS의 불필요 파일들 제외하기 위에서 설명한 것과 같이 자동 생성되는 파일들을 git 에서 제외하려면 .gitignore 파일을 사용하면 된다. git에 포함되지 않도록 제외하는 경우 # .gitignore 파일 ... # OS Generated Files # ###################### **/.DS_Store **/._* ... 이미 git에 포함된 경우 # git 정보 검색 및 삭제 $ find . -name

[Kubernetes-Troubleshooting] 삭제되지 않는 Namespace 강제로 삭제하기

# How to force deletion of a namespace ## 문제 상황 Argo Project의 Argo Events를 테스트해 보기 위해서 여러 가지 작업을 하던 중 제대로 처리가 되지 않아서 다시 시작할 겸 Namespace를 삭제해서 소속된 리소스들을 모두 삭제했다. ![Kubernetes에서 Namespace가 삭제되지 않는 문제](http://drive.google.com/uc?export=view&id=1xpTaSRfI7ycKqYmU17PPS3H5RTidL9Z_) 그런데 위의 그림처럼 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

[Kubernetes - Operator] KUDO를 활용한 Galera Operator 단계별로 적용하기 - PART 3: Bootstrap 삭제 및 서비스 중단 없이 Scale Up/Down 처리

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

[Kubernetes - Operator] KUDO를 활용한 Galera Operator 단계별로 적용하기 - PART 2: Nodes 참여와 서비스 생성 및 StatefulSet 구성

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 -