지식창고

ConfigMap kubectl create configmap app-config --from-literal=APP_COLOR=blue --from-literal 옵션 뒤에는 =형태로 변수 넘겨줌 --from-file 옵션으로 외부의 file 참조하여 생성 가능 Pod(deployment)definition 의 spec.containers.envFrom.configMapRef 에 configmap 명 넣어주면 configMap의 data가 pod의 env variable로 추가됨 Secrets 민감 정보를 저장하기 위한 component 저장시 암호화되어 저장됨 kubectl create secret generic app-secret --from-literal=APP_COLOR=blue --from-li..

Dockerfile Commands pod의 definition 파일에서 Dockerfile의 Entrypoint 명령어에 argument를 전해주려면 spec.containers.args 에 JSON Array 형식으로 넘겨준다. args 로 넘겨주면 Dockerfile의 CMD override함 Dockerfile의 Entrypoint override하려면 spec.containers.command 에 JSON Array 형식으로 넘겨준다. Arguments spec.containers.env 에서 array 형태로 선언해줌. - name: AAA \ value: bbb 로 key-value 형식 value를 configmap이나 secret에서 가져오고자 하면 value: 대신 valueFrom: ..

Rolling Update & Rollback kubectl rollout status deployment-name kubectl rollout history deployment-name으로 revision 확인 가능 rolling update는 default deployment strategy Recreate VS Rolling update Recreate는 replicas가 0으로 먼저 줄고 다시 5로 scale up rolling update는 old revision이 하나씩 줄고 new revision이 하나씩 는다 deployment가 update되면 new version의 replicaset이 생성되고, rolling update가 진행된다. kubectl rollout undo deploym..

Metrics server in-memory monitoring solution 하나의 클러스터에 하나의 metrics server만 node와 pod의 metric을 in-memory에 취합하고 저장 historical metric data를 볼 순 없어서 추가적인 monitoring solution 을 사용해야 함 kubelet의 subcomponente인 cAdvisor에서 pod metric 수집하고 Metrics server으로 보냄 Metrics server는 HPA와 VPA할 때에도 필요함. 설치하면 kubectl top node, pods 명령어 실행 가능 Logging kubectl logs 명령어로 볼 수 있음 Pod에 컨테이너가 하나 이상인 경우 kubectl logs 명령어에 pod..

kubernetes는 여러 개의 custom scheduler를 선언하는 것을 허락한다. binary 다운받아서 --scheduler-name 옵션의 이름 변경하여 실행 pod definition file에서 scheduler 지정하면 원하는 scheduler로 pod 실행시킬 수 있음. spec.schedulerName: 에 scheduler name 설정하면 됨. 제대로 설정되지 않으면 pod는 pending state로 유지됨 scheduler는 pod 형식으로 배포되기 때문에 static pod의 manifests가 위치한 folder에서 yaml 파일 copy 후 scheduler name 옵션 추가하고 저장하면 kubelet이 custom scheduler 배포함 --leader-elect 옵..

K8S 클러스터에서 master node와 다른 worker node 없이 오로지 하나의 worker node만 있다면? kubelet은 특정 디렉토리의 definition 파일들을 보고 pod 생성하는 것 뿐 아니라 pod가 살아있는지 확인함 kubelet은 app crash나면 restart도 시키고, 변경 사항이 생기면 recreate도 함 이 디렉토리에서 yaml 삭제하면 pod도 삭제됨 Static pod : API Server의 개입 없이 kubelet이 자체적으로 생성한 pod replicaset나 deployment나 service는 이 디렉토리에 definition 넣어도 생성 못함. 이것들은 master node의 controller가 필요하기 때문. directory는 어느 위치에나 ..

CKA 70/262 클러스터의 모든 node에 하나씩 pod 를 배포할 수 있도록 함 node가 하나 추가되면 pod도 하나 또 추가됨 kube-proxy같은 monitoring agent나 Network agent가 daemonset으로 좋은 예 DaemonSets가 어떻게 pod를 각 worker node에 배포하는지? k8s 1.11버전까지는 각 pod에 nodeName 값 설정해서 각 nodeName으로 배포되도록 함 1.12버전부터는 node affinity와 default scheduler 사용해서 각 worker node에 배포시킴

특정 pod를 특정 node에 띄우기 위한 방법은 두 가지 NodeSelector spec.nodeSelector로 pod 의 definition에 정의. node에 정의된 label로 key:value 선언 kubectl label nodes =: node에 label 주는 방법 node Selectors로는 or 조건이나 not 조건을 추가할 수 없음 Node Affinity 더욱 복잡하고 다양한 조건을 위한 기능 operator을 In과 NotIn으로 설정할 수 있고, 이의 대상은 values 내의 label value array이다. operator이 exists는 affinity에 선언한 key값이 있는 node들을 대상으로 적용됨. value section은 값을 비교하지 않기 때문에 필요 없..

Taints와 Tolerations 는 어떤 파드가 어떤 node에 놓이면 안되는지를 제한하는 것 taints 와 tolerations 가 없으면 scheduler는 pod를 node에 균등하게 배포함 node에 taint를 설정하고 pod에 toleration을 설정하지 않으면 모든 pod는 node의 taint때문에 해당 node에 배포 불가 taint는 node 대상, tolerations는 pod 대상으로 설정한다 kubectl taint nodes node1 key1=value1:NoSchedule taint-effect 종류 NoSchedule: pod를 해당 node에 신규 배포하지 않음 PreferNoSchedule: pod를 웬만하면 node에 배포를 피하지만 아예 안하진 않음 NoExe..

Kubernetes 클러스터 내의 수백 수천가지의 object를 분류하고 filter할 필요가 있음 어떤 방식으로 분류를 하던 그룹화 하는데에는 labels와 selectors 가 필요함. metadata.labels 에 key-value 형식으로 정의함 ReplicaSet에는 두 개의 labels가 있는데, templates 안에 있는 label은 pod의 label, metadata에 있는 label은 RS의 label임. RS의 spec.selector.mathLabels와 template.metadata.labels가 같아야 RS 가 관리하는 pod가 성공적으로 선택됨