지식창고

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가 성공적으로 선택됨

kubectl apply가 대표적인 declarative commands kubectl apply -f pod.yaml 실행하면 cluster 내부 메모리에 live object configuration에는 status라는 정보가 추가됨 Last applied configuration은 local file을 json 형태로 변환하여 저장하고 있음. 이전의 리소스 정보와 현재의 정보를 비교하여 어느 부분이 삭제되었는지 확인하는 용도 Last applied configuration은 Live object configuration 의 metadata.annotation.kubectl.kubernetes.io/last-applied-configuration에 저장되어 있음. imperative commands는..

Imperative commands 는 바로 반영이 가능하지만 기능상의 제약이 있고, 한번 실행되고 사라진다. keep track 하기 힘듦 명령어 실행 전 항상 현재 상태에 대해서 파악을 한 후에 실행해야 하는 제약이 있음(update하려면 기존에 생성이 되어 있는지 파악을 먼저 해야 하는 번거로움) --dry-run: will not create the resource, instead, tell you whether the resource can be created and if your command is right. -o yaml: This will output the resource definition in YAML format on screen. POD Create an NGINX Pod kub..

어플리케이션의 안팎에 있는 컴포넌트들과 커뮤니케이션을 가능하게 해줌 enable loose coupling between microservices NodePort 노드 IP의 Port를 listen하고 있다가 요청을 뒤의 pod로 전달해줌. 이것이 NodePort TargetPort: pod에 열려있는 port no Port: 서비스 관점에서의 자체 Port 30000에서 32767 사이의 숫자만 선택 가능 definition의 spec.type에 NodePort 로 선언 Pod나 node의 개수에 관계 없이 service는 하나만 생성 ClusterIP cluster 내에 virtual IP 생성하여 통신 가능하게 함 definition의 spec.type에 ClusterIP로 선언 LoadBalanc..

0. Kubernetes 환경 현재 프로젝트에서 구축한 Kubernetes 환경은 Kubernetes 1.15 버전이고, Node Autoscaling과 Pod Autoscaling 이 적용되어 있다. Worker Node가 AZ별로 이중화되어 있는 환경에서 Pod가 분산 배포되지 않고 한 Node에 몰려있으면, 그리고 그 Node가 Down 상태가 되면 Pod 의 서비스가 같이 Down되게 된다. 이러한 문제점을 피하기 위해 Pod에 Affinity 옵션을 설정하여 Pod을 분산 배포한다. 1. Pod Affinity 파드간 어피니티와 안티-어피니티를 사용하면 노드의 레이블을 기반으로 하지 않고, 노드에서 이미 실행 중인 파드 레이블을 기반으로 파드가 스케줄될 수 있는 노드를 제한할 수 있다. 규칙은 ..

0. VPA(Vertical Pod Autoscaling)이란 Vertical Pod Autoscaling은 Node에 배포된 Pod의 CPU 사용량(또는 베타 지원의 다른 애플리케이션 지원 메트릭)을 관찰하여 Pod에 선언된 Resource Request를 적절하게 조정하거나 적정 Resource Request를 추천한다. Request 조정을 통해 클러스터 리소스 사용률을 개선하고 다른 포드를 위한 CPU 및 메모리를 확보할 수 있다. 1. Metric Server 설치 Horizontal Pod Autoscaling 적용하기 1번을 참조한다. 2. CPU 리소스 확인 Horizontal Pod Autoscaling 적용하기 2번을 참조한다. 3. Vertical Pod Autoscaler 배포 하단..

namespace는 k8s 내 가상의 리소스 격리 공간 namspace 옵션 주지 않으면 default namespace에 생성됨. kube-system과 kube-public은 k8s에서 자동으로 생성해줌. 외부 ns의 service 도메인은 app.namespace.svc.cluster.local로 호출해야 함. 서비스가 생성될 때 이와 같은 DNS Entry가 생성됨. cluster.local : default domain name of the k8s cluster svc. : subdomain 리소스의 definition의 metadata.namespace에 추가하면 해당 NS 에 생성됨. kubectl config set-context $(kubectl config current-context)..

ReplicaSet의 상위 components 배포된 instance들을 rolling update로 seamless하게 upgrade하거나, change를 되돌리고, 일시정지했다가 재개하는 등의 작업을 가능하게 해줌 deployment 생성하면 RS 생성하고 RS는 Pod 생성함. Deployment에 resources requests 설정하지 않으면 기본으로 cpu, memory 설정되도록 LimitRange 라는 리소스 생성해서 관리가 가능함. Memory 선언 시에 1G(Gigabyte)와 1Gi(Gibibyte)의 단위는 다르다! CPU Limit이 설정되어 있으면 kubernetes는 그 이상의 CPU 사용하면 throttle 걺. but Memory는 limit보다 더 쓸 수 있음. 하지만 ..

0. HPA(Horizontal Pod Autoscaling)이란 Horizontal Pod Autoscaling은 Node에 배포된 CPU 사용량(또는 베타 지원의 다른 애플리케이션 지원 메트릭)을 관찰하여 레플리케이션 컨트롤러, 디플로이먼트, 레플리카 셋 또는 스테이트풀 셋의 파드 개수를 자동으로 Scale Out하고 Scale In하는 기능을 말한다. 비슷한 기능으로 Vertical Pod Autoscaling이 있는데, 이는 HPA와는 달리 Pod에 할당된 resource request 값을 적절히 조절하여 pod의 "크기"를 조정하는 것이다. 1. Metric Server 설치 Metric Server는 각 Pod와 Node의 리소스 사용량을 확인할 수 있는 컴포넌트이다. 아래의 명령어를 통하여..