구름엔지니어만들기

PV, PVC 를 사용하고있는 pod나 storageClass를 삭제했음에도 불구하고 PV 또는 PVC를 삭제해도 terminating 상태에서 계속 멈춰있는 경우가 있다.  원인?PV, PVC의 정보를 보면 finalizers 필드에 kubernetes.io/pvc-protection이 설정되어있을 수 있다 $ kubectl describe | grep FinalizersFinalizers: [kubernetes.io/pvc-protection] . PV, PVC가 삭제될 때 관련된 리소스가 남아있거나, 작업중인 리소스가 있다면 데이터 손실을 방지하기 위해 안전장치를 걸어주는 역할을 한다는데 어차피 삭제할 PV, PVC 이니 이 설정을 해제시키고 다시 삭제를 해봤다.  # PV 삭제 안되는 경..

예를 들어 kubernetes에서 돌고있는 pod의 특정 정보를 뽑아내야 한다고 하자.   추출할 정보 예시:1. deployment로 배포한 pod의 deployment 이름2. 배포한 pod의 개수(replica)3. 컨테이너 각각의 이름, 리소스 kubectl get deployments -o json | jq -c ' .items[] | { name: .metadata.name, newReplicaSet: .status.replicas, containers: [ .spec.template.spec.containers[] | {name, resources: .resources} ] }' 필요한 필드값을 명시하면 된다.   결괴 예시:web dep..

metric-server를 설치 했는데도 정상적으로 작동하지 않는 경우가 있다.  1. kubectl logs 결과 tls 에러가 발생하는 경우 pod가 돌지도 않고, hpa targets도 unknown으로 뜬다.  tls: failed to verify certificate: x509: cannot validate certificate for 10.0.2.10 because it doesn't contain any IP SANs" node="master"  이 경우에는 kubectl edit deployment metrics-server -n kube-system 명령어로 파일에 진입해서 kubelet과의 TLS 인증서 검증을 무시하도록 하고, 메트릭 서버가 클러스터 노드의 네트워크 인터페이스를 직접..

0. 설치 전 확인사항호환되는 리눅스 머신. 쿠버네티스 프로젝트는 데비안 기반 배포판, 레드햇 기반 배포판, 그리고 패키지 매니저를 사용하지 않는 경우에 대한 일반적인 가이드를 제공한다.2 GB 이상의 램을 장착한 머신. (이 보다 작으면 사용자의 앱을 위한 공간이 거의 남지 않음)2 이상의 CPU.클러스터의 모든 머신에 걸친 전체 네트워크 연결. (공용 또는 사설 네트워크면 괜찮음)모든 노드에 대해 고유한 호스트 이름, MAC 주소 및 product_uuid. 자세한 내용은 여기를 참고한다.컴퓨터의 특정 포트들 개방. 자세한 내용은 여기를 참고한다.스왑의 비활성화. kubelet이 제대로 작동하게 하려면 반드시 스왑을 사용하지 않도록 설정한다. 1. VM서버 구성 서버 설정 만약 너무 과도하게 리소스를..

StorageClass로 NFS 스토리지를 Pod에 연결하려니 발생한 에러   journalctl -u kubelet -n 100 명령어로 확인해보니  master kubelet[896]: E1127 08:46:29.250652 896 kubelet.go:2345] "Skipping pod synchronization" err="container runtime is down"   kubelet이 컨테이너 런타임에 연결할 수 없다는게 뭔소린가 했더니nfs-common 을 master와 nfs 서버에만 설치해서 발생한 문제였다.  apt install nfs-common 명령어를 모든 master와 node에 다 돌리고 나니 문제 해결.

Kubernetes에서 더이상 Docker shim을 사용하지 않아 containerd, CRI-O 와 같은 런타임만 필요로 한다.  그래도 Docker를 쓰는 김에 Docker Engine을 컨테이너 런타임으로 사용했었는데 kubeadm init을 하면 unknown service runtime.v1.RuntimeService 에러가 발생해서 설정파일을 삭제하는 등의 귀찮은 작업을 해야하고, 그마저도 에러가 많이 발생해서 CRI-O로 바꿨다.   아래는 CRI-O 설치 방법이다. https://github.com/cri-o/packaging/blob/main/README.md#usage packaging/README.md at main · cri-o/packagingCRI-O deb and rpm pa..

0. 설치 전 환경 설정 https://goharbor.io/docs/2.10.0/install-config/installation-prereqs/ Harbor – Harbor Installation Prerequisites Harbor Installation Prerequisites goharbor.io 설치 당시 하드웨어, 소프트웨어, 네트워크 포트 조건 위 조건을 참고해서 만든 VM 환경은 다음과 같다: OS: ubuntu 20.04 Hardware: 2 CPU 4G Software: docker v24.0.7, docker-compose v1.25.0 public IP: 192.168.77.163 private IP: 10.10.20.145 docker와 docker-compose 설치 방법: #..

긴 kubectl 명령어를 간편하게 사용하기 위한 초기 세팅   터미널에서 .bashrc 파일 열vi ~/.bashrc 파일의 끝에 아래의 코드를 추가# 별칭 설정: 'k'가 kubectl와 동일한 의미를 가지도록 함alias k=kubectl# 명령어 자동완성: tab키를 누르면 명령어 자동완성source  변경 사항 적용source ~/.bashrc  결과:

지난 포스팅에서는 단일 컨트롤 플레인(마스터 노드)에 노드를 조인하는 방법을 알아봤다. 이번에는 클러스터에 여러 개의 컨트롤 플레인를 구성해보자. VM 구성(총 7개): bastion: 10.10.20.10 master1 : 10.10.20.83 master2 : 10.10.20.149 master3 :10.10.20.101 worker1 : 10.10.20.152 worker2 : 10.10.20.96 worker3 : 10.10.20.109 bastion 서버는 로드밸런싱 용도로 만들었다. HaProxy를 설치해서 트래픽을 세 개의 컨트롤 플레인에 분산시킬 예정이다. 0. 기본 세팅 지난 포스팅의 3번 - control plane와 worker node 공통 작업까지 진행한다. 클러스터 생성 전 단..

해결:# 컨테이너 런타임 설정파일 삭제 후 재시작sudo rm /etc/containerd/config.tomlsudo systemctl restart containerd control plane에서 오류가 발생했다면 다시 sudo kubeadm init 명령어로 클러스터 초기화를 진행한다.worker node에서 오류가 발생했다면 다시 kubeadm join ... 명령어로 control plane과 연결한다.    그럼에도 안되면 아래 Kubernetes 컨테이너 런타임 추천 포스팅 참고 https://minha0220.tistory.com/200   Kubernetes 컨테이너 런타임 추천(containerd, CRI-O, Docker Engine)Kubernetes에서 더이상 Docker shim..