ParanBlog.

인증서 문제쿠버에서 인증서 관련 문제를 해결하려면 일단 해당 쿠버 클러스터가 어떻게 디플로이되었는지를 알아야 한다.예를 들어 kubeadm을 사용하여 올렸다면 상당 부분을 알아서 해준다kubeadm은 쿠버의 컴포넌트들을 Static Pods으로 올려준다.예를 들어 kube-apiserver는 /etc/kubernetes/manifests/kube-apsierver.yaml에 Pod Specification이 있고, 이 파일의 spec.containers.command 하위의 파라미터들을 통해, kube-apiserver의 인증서들의 존재를 알 수 있다.각 인증서 파일에 대해 openssl x509 -in /path/to/cert.crt -text 명령어로 Readable text 형태의 인증서를 볼 수 ..

쿠버에는 기본적으로 (관리자, 개발자 같은) 사용자라는 개념이 없다. kubectl create user user-name 같은 식으로 사용자를 생성하는 것은 당연히 불가능다만, 사람이 아닌 entity를 위한 Service Account라는 개념은 존재한다.하지만 kube-apiserver에 들어오는 API 콜 (kubectl이든 HTTP API endpoint를 통한 직접 접근이든) 을 무조건 다 받아주면 안되는 것은 자명하다. 어떻게든 user authentication을 거친 뒤에 리퀘를 받아줘야 하는 것이다.Kubernetes 1.19까지는 Client Certificate를 사용하지 않고 인증하는 방식들이 있었다비밀번호,사용자이름,사용자ID[,그룹] 형식의 CSV파일을 넣은 뒤, 요청 시 ID..

무엇을 백업할 것인가방법 1: YAML object configuration file을 백업방법 2: ETCD를 통째로 백업두 방법 모두 마운트해 준 Persistant Volume은 따로 백업해주어야 할 것이다YAML Object Configuration File 백업YAML 설정 디렉토리째로 백업하면 되지 않나요?이 경우 SCM (Git같은)에 소스코드와 함께 보관하는 것도 좋다문제점: Declarative Approach가 권장되는 방법이기는 하지만, 팀에서 누군가가 Imperative하게 Object를 생성/수정해 놓고서 문서화도 안하고 튀었을 수도 있다.해결책: kube-apiserver에 쿼리하여 현재 사용 중인 리소스 설정을 전부 YAML 형태로 내보내기한다.kubectl get all --..

기본적으로 업데이트를 하기 전에, ReplicaSet (이나 Deployment)를 잘 짜서, 한 서버를 내려버리더라도 다른 노드에서 필요한 Pod들이 잘 돌도록 구성할 필요가 있다.어떤 노드가 죽으면, 마스터노드가 죽은 노드에 있던 Pod들의 사망판정을 내리기까지 5분의 유예시간이 존재한다. 이것은 kube-controller-manager --pod-eviction-timeout=5m0s 명령어로 수정할 수 있다.Drain하기노드를 drain하면, 해당 노드에 대한 스케줄링은 멈추고 노드에 있던 모든 Pod들은 종료된다. ReplicaSet같은 게 제대로 설정되어 있다면, 꺼진 Pod들은 다른 노드로 옮겨 갈 것이다. Pod들이 옮겨간 뒤에, 업데이트를 하든 뭘 하든 지지고볶으면 된다.kubectl ..

환경변수를 줄 수 있다.spec: containers: - name: simple-webapp image: simple-webapp env: - name: APP_COLOR value: pink - name: JAVA_HOME value: /usr/ConfigMaps하지만 Pod 설정파일에 모든 환경변수를 때려박는다는것은 별로 가독성에 좋지 않을 수 있다.ConfigMaps는 쿠버에서 K-V 페어의 설정데이터를 저장하는 오브젝트이다(아마).Imperative 방식 생성kubectl create configmap conf-map-name --from-literal=APP_COLOR=pink --from-literal=JAVA_HOME=/usr/혹은 그냥 다음과 같은 파일을 만들고,..

Docker에서 명령어예를 들어, 도커에서 docker run ubuntu로 우분투 이미지를 돌리면, 실행 즉시 종료되어 버린다.docker ps에는 아무것도 보이지 않고, docker ps -a를 해야 그나마 종료되었다는 사실만을 알 수 있을것이다.왜째서인가?Ubuntu의 Dockerfile을 보면, CMD ["bash"]라고 되어 있다.bash는 터미널을 찾을 수 없으면 exit한다.CMD가 끝났기 때문에, 컨테이너도 끝난다.docker run ubuntu 우분투에서-실행할-명령어를 하면, Dockerfile의 CMD ["bash"]가 오버라이드(대체) 된다.혹은, 다음처럼 새로운 Dockerfile을 만들 수도 있다.FROM ubuntuCMD sleep 5CMD는 다음과 같은 형식을 할 수 있다.C..

Deployment를 처음 생성하면 Rollout이 트리거된다새로운 롤아웃은 새로운 Deployment Revision을 만든다 - 예를 들어 Revision 1나중에, 앱이 업그레이드되면 (즉, 컨테이너의 버전이 새로운 버전으로 올라가면)새로운 롤아웃이 트리거되고,새로운 디플로이먼트 리비전이 생성된다 - 예를 들어 Revision 2Rollout 상태 보기: kubectl rollout status deployment/myapp-developmentRollout 히스토리 보기: kubectl rollout history deployment/myapp-developmentDeployment Strategy있는 인스턴스를 다 날리고 새 인스턴스를 만든다 ("Recreate")당연히 downtime이 발생함..

# Monitor Clutser Components- Heapster (Deprecated)- Metrics Server- 쿠버 클러당 1개- In-Memory monitoring solution- Kubelet의 하위컴포넌트인 cAdvisor(Container Advisor)가 Pod에서의 퍼포먼스 메트릭을 받아다 Kubelet API에 노출함- 설치 방법:- Minikube의 경우, `minikube addons enable metrics-server`- 기타 배포판의 경우, Github Repo를 클론한 뒤에 `kubectl create -f deploy/1.8+/`- 설치가 완료되었으면 `kubectl top node`, `kubectl top pod`In-memory 모니터링 솔루션이 아니라, ..

일단 Pod이 생성되면 Scheduling Queue에 들어가게 된다그 다음 Pod에 선언된 spec.priorityClassName에 의해 정렬된다.PrioritySort 플러그인에 의해 처리그 다음엔 필터링 단계에 들어가게 된다.Pod을 구동할 수 없는 노드(Affinity, Tint, Resource 등의 제한)들은 튕겨나간다.NodeResourceFit, NodeName, NodeUnschedulable 플러그인 등에 의해 처리그 다음엔 스코어링 단계이다.해당 Pod가 차지하는 공간을 제외하고 남는 free space의 크기에 따라 점수 부여남는 free space가 클수록 높은 점수가 나온다NodeResourcesFit, ImageLocality 플러그인에 의해 처리ImageLocality: 컨..

쿠버의 아키텍처 돌아보기마스터 노드kube-apiserveretcd clusterController Managerkube-scheduler워커 노드Kubelet워커노드의 Kublet은 Pod을 어떻게 배치할지에 대해 마스터노드의 Kube-apiserver에 의존이 결정은 Kube-scheduler에서 내림이것은 etcd에 저장됨만약 마스터노드가 없다면?워커노드 혼자서 떠있다면?Kubelet 혼자서 노드를 독립적으로 관리하는 것은 가능하다!이런 상황에서 Pod을 만드려고 한다면, kube-apiserver 없이 kublet에 어떻게 Pod definition file을 넣을것인가?kubelet이 특정 디렉토리에서 설정파일을 읽도록 설정할 수 있음이렇게 설정하면, Kubelet이 설정파일을 읽은 뒤에 Pod..