꾸준히 개발할 만두

노드 그룹이 생성되지 않아서 검색해본 결과!!! AWS Document에서 NodeCreateFailure는 노드 IAM 역할 권한이 충분하지 않아 발생할 수 있다고 한다. https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/troubleshooting.html Amazon EKS 문제 해결 - Amazon EKS 해당 위치에 스크립트가 없으면 CNI 컨테이너를 실행할 수 없습니다. 다음 명령을 사용하여 스크립트를 수동으로 다운로드하고 실행할 수 있습니다. curl -O https://raw.githubusercontent.com/awslabs/amazon-ek docs.aws.amazon.com 그럼 IAM을 재설정해보자. 우리가 설정해줘야할 Nodegro..

Kubelet 문제로 Cronjob으로 생성한 Patch-istio-configmap이 엄청나게 많이 생성되고, Terminating되어 있는 상태이다...Kubelet 문제는 해결됐는데 Pod들이 아직도 이 상태로 머물러져있다. 이걸 어떻게 일일히 지우지..? 🤔 다행히 regex를 가지고 모든 파드를 지울 수 있었다. kubectl get pods -n istio-system --no-headers=true | \ awk '/patch-istio-configmap/{print $1}'| \ xargs kubectl delete -n istio-system pod --grace-period 0 --force

Worker Node #1. Kubelet 상태 확인하기 journalctl -u kubelet #2. Kubelet 재시작 systemctl restart kubelet #3. 다음과 같은 Log 출력됨. "container runtime status check may not have completed yet" -> container runtime 상태를 확인해보자 #4. container runtime 재시작 systemctl restart containerd #5. container runtime 상태 확인 systemctl status containerd #6. Master node에서 해당 Worker node 상태 확인하기 성공😎 Worker Node의 Kubelet이 제대로 동작하지 않아 N..

ln -s /run/resolvconf/ /run/systemd/resolve

Taints & Tolerations 쿠버네티스는 클러스터의 특정 노드에 테인트를 설정할 수 있다. 테인트를 설정한 노드에는 파드들을 스케줄링하지 않는다. 테인드를 설정한 노드에 파드들을 스케줄링하려면 톨러레이션을 설정해야한다. 그럼 테인트는 톨러레아션에서 설정한 특정 파드들만 실행하고 다른 파드는 실행하지 못하게 한다. 즉, toleration이 있는 Pod는 동일한 taint가 있는 노드를 포함에 모든 노드에 배치되며, worker node는 taint가 설정된 경우 동일 값의 toleration이 있는 pod만 배치한다. $ kubectl get nodes -A NAME STATUS ROLES AGE VERSION kube-master Ready control-plane,master 24d v1.2..

쿠버네티스에서는 파드를 어떤 노드에 실행할 것인지에 관한 다양한 옵션이 있다. 이 옵션을 조합해서 사용자가 원하는 구조대로 클러스터 안에 파드들을 배치할 수 있다. 1. NodeSelector 파드가 클러스터 안 어떤 노드에서 실행될지를 키-값 쌍으로 결정한다. 노드셀렉터는 노드의 레이블에 설정된 값으로 노드를 선택한다. 노드에 label 생성하기 $ kubectl label nodes = kube-worker 노드에 disktype=ssd 라벨을 만든다. $ kubectl label nodes kube-worker disktype=ssd $ kubectl get nodes -L disktype NAME STATUS ROLES AGE VERSION DISKTYPE kube-master Ready cont..

kubernetes에서 pvc를 이용해 nfs 서버에 마운트 하려는 상황에서 계속 mount.nfs: access denied by server while mounting 에러가 떴다. pv yaml apiVersion: v1 kind: PersistentVolume metadata: name: nfs spec: capacity: storage: 1Mi storageClassName: cluster-manager accessModes: - ReadWriteMany nfs: server: 10.0.5.86 path: "/root/.kube/" readOnly: false pvc yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: nfs spec..

Init Container란? 앱 컨테이너 실행 전에 미리 동작시킬 컨테이너이다. 본 Container가 실행되기 전에 사전 작업이 필요할 경우 사용한다. 초기화 컨테이너가 모두 실행된 후에 앱 컨테이너를 실행한다. 초기화 컨테이너는 여러 개를 구성할 수 있다. 초기화 컨테이너가 여러 개 있다면 파드 템플릿에 명시한 순서대로 초기화 컨테이너가 실행된다. 초기화 컨테이너 실행이 실패하면 성공할 때까지 재시작한다. [실습] 다음의 yaml 파일은 두 개의 초기화 컨테이너를 포함한 간단한 파드에 대한 개요를 보여준다. 첫 번째는 myservice 를 기다리고 두 번째는 mydb 를 기다린다. 두 컨테이너들이 완료되면, 파드가 시작될 것이다. apiVersion: v1 kind: Pod metadata: nam..

livenessProbe는 파드의 건강검진과 같다고 생각할 수 있다. Pod가 계속해서 실행할 수 있음을 보장해준다. kubelet은 livenessProbe를 사용해 컨테이너를 재시작해야할 때를 알 수 있다. livenessProbe를 Pod의 Spec에 정의해두면 이 내용을 기반으로 Container의 상태를 주기적으로 확인한다. 만약 Container 상태가 비정상적이라면, Container를 재시작한다. 이때 Container만 재시작하기 때문에 Pod의 IP Address는 그대로 유지된다. livenessProbe 매커니즘 ✅ httpGet probe (web 기반) 지정한 IP 주소, Port, Path에 HTTP Get 요청을 보내 응답을 확인한다. 만약 nginx webserver를 80..

kubernetes cluster는 크게 두 종류의 서버로 구성한다. 1️⃣ master (control plane): 클러스터를 관리하는 서버 2️⃣ node: 실제 컨테이너를 실행시키는 서버 master는 보통 고가용성을 만족하고자 서버 3대 정도 구성해서 운영한다. 평소 실제 클러스터를 관리하는 리더 마스터는 1대고 나머지는 대기한다. 리더 마스터에 장애가 발생하면 자연스럽게 2대 중 1대가 리더 역할을 한다. master와 노드의 구성과 통신 구조 1️⃣ master 마스터를 보면 kubelet이 마스터에 있는 도커를 관리한다. 각 컴포넌트의 중심은 kube-apiserver이다. kube-apiserver를 거쳐 다른 컴포넌트가 서로 필요한 정보를 주고 받으며, etcd에는 kube-apiser..