1. 개념 특정 경로에 존재하는 yaml 파일에 대해 kublet이 자동으로 파드로 생성 kube-APIServer에 의하지 않고 kubelet이 파드를 생성 및 관리하는 것이 특징 정적 파드는 파드만 생성 가능하고 레플리카셋 등 다른 리소스는 생성 불가 클러스터의 컴포넌트(kube-API, etcd 등)를 정적 파드로 생성해 장애를 방지하고 설치를 용이하게 하는 등 다양한 목적으로 활용 가능 2. 정적 파드 Lfie-Cycle 생성 : 정적 파드 경로에 yaml 파일이 존재할 경우 자동으로 파드 생성 유지 : 정적 파드 경로에 yaml 파일이 존재할 경우 파드가 삭제되어도 재생성 수정 : 정적 파드 경로의 yaml 파일을 수정하면 자동으로 기존 파드가 삭제되고 새로운 파드가 생성 삭제 : 정적 파드 경..
1. 개념 모든 노드마다 파드를 반드시 한 개씩 배포하는 특성 일반적으로 kube-proxy, calico 등 네트워크 관련 서비스가 데몬셋으로 배포됨 이외에도 클러스터 모니터링에 필요한 에이전트를 배포하는 등 다양한 목적으로 활용 가능 2. 동작 원리 데몬셋으로 배포되는 각 파드에 자동으로 노드 어피니티가 적용되어 모든 노드에 하나씩 배포되도록 함 3. YAML을 활용한 데몬셋 생성 nginx 컨테이너로 구성된 데몬셋을 생성하기 위한 YAML 내용 apiVersion: apps/v1 kind: DaemonSet metadata: name: test-mydaemonset spec: selector: matchLabels: app: agent template: metadata: labels: app: ag..
1. 개념 테인트는 노드의 관점에서 "특정(톨러레이션이 적용된) 파드만 여기에 배포해라!" 라는 목적으로, 톨러레이션이 적용된 파드는 테인트가 적용되지 않은 노드로 배포될 가능성 존재 노드 어피니티는 파드의 관점에서 "특정(노드 어피니티 조건에 부합하는) 노드로만 배포되라!" 라는 목적으로, 노드 어피니티가 적용되지 않은 파드가 노드 어피니티 조건에 부합하는 노드로 배포될 가능성 존재 따라서 테인트/톨러레이션과 노드 어피니티를 복합적으로 적용할 경우 특정 노드에는 특정 파드만 배포 가능하고, 특정 파드는 특정 노드로만 배포되도록 스케줄링 가능
1. 개념 파드를 kube-Scheduler에 의존하지 않고 엔지니어 의도에 따라 특정 노드에 배포할 수 있도록 핸들링하는 설정 배포조건/오퍼레이터/weight를 활용해 배포 스케줄링을 세부적으로 핸들링 할 수 있는 점이 nodeSelctor와의 차이점 2. 노드 어피니티 조건 배포조건 requiredDuringScheduling : 반드시 노드 어피니티 조건에 부합하는 노드에 배포하겠다는 의미 preferredDuringScheduling : 왠만하면 노드 어피니티 조건에 부합하는 노드에 파드를 배포하겠지만, 상황에 따라 조건에 맞지 않는 노드에 배포할 수도 있다는 의미 IgnoredDuringExecution : 파드가 배포되어 특정 노드에서 실행 중인 상황에서 해당 노드의 설정이 변경되어 어피니티 ..
1. 테인트와 톨러레이션 개념 노드 스케줄링을 임의로 핸들링하기 위한 방법 중 하나 테인트가 설정된 노드에는 톨러레이션이 적용된 파드만 배포 가능 테인트는 일종의 '자물쇠' 역할 톨러레이션은 자물쇠를 푸는 일종의 '열쇠' 역할 착각하기 쉬운 점은 톨러레이션이 적용됐다고 무조건 테인트가 적용된 노드로 배포되는 것은 아니며, 테인트가 적용되지 않은 일반 노드로 배포될 가능성도 존재 DB 등 보안이 필요한 노드에 테인트를 적용하여 의도치 않은 파드 배포를 방지하는 형태로 활용 가능 2. 테인트 적용 테인트 적용 kubectl taint node [노드_이름] [테인트_키]=[테인트_값]:[테인트_효과] 테인트 값 확인 kubectl get node [노드_이름] -o yaml | grep -i taint -F..
1. 레이블 개념 AWS 태그 또는 velog의 태그와 같은 개념 리소스 관리를 효율적으로 하기 위해 리소스마다 이름표를 붙이는 것 규격화된 양식은 없으며 DevOps 엔지니어가 원하는 임의의 레이블 지정 가능 app: frontend app: backend type: web ... 2. 셀렉터 개념 여러가지 레이블 중 특정 레이블을 선택하는 개념 ex.) type: web, purpose: dev를 만족하는 디플로이먼트 3. 레이블·셀렉터 활용 app=zero 레이블을 가진 파드 생성 app=zero 레이블을 가진 파드만 조회 다수 레이블에 대한 필터도 가능
1. 개념 파드는 일반적으로 kube-Scheduler에 의해 자동으로 어떤 노드에 배포될지 결정 하지만 nodeName, nodeSelector 필드를 통해 엔지니어의 의도에 따라 특정 노드에 배포하도록 지정 가능 2. 메뉴얼 스케줄링 적용 리소스 생성 시 'nodeName' 항목 지정 리소스 배포 확인 3. 노드 셀렉터 적용 노드 레이블 확인 kubectl get node [노드_이름] -o yaml | grep -i labels -F10 or kubectl get node [노드_이름] --show-labels 노드 레이블 생성 kubectl label node [노드_이름] [레이블_키]=[레이블_값] or kubectl label node [노드_이름] --overwrite [레이블_키]=[레이..
1. 명령형(Imperative) vs 선언형(Declarative) 명령형(Imperative) shell에서 명령어(create, run, create, edit, replace 등)를 활용해 오브젝트를 핸들링하는 방식 (장점) 간단한 작업의 경우 빠르게 수행 가능 (단점) IaC 관리 불가능 (단점) 여러명의 엔지니어가 작업할 경우 히스토리 추적·관리 불가능 (단점) edit으로 변경한 내용이 수정 형태(추가 or 삭제)에 따라 Live Object Configuration 또는 Last Applied Configuration 둘 중 한곳에만 적용되어 설정의 불일치 발생 선언형(Declarative) yaml 파일에 오브젝트 상태를 정의하고 apply로 생성하는 방식 (장점) IaC 가능 (장점) ..
1. 서비스 개념 파드가 끊임없이 생성·삭제되는 쿠버네티스의 특성으로 인해 파드의 IP도 고정되지 않고 계속해서 바뀜 이런 특성은 클러스터 외부에 있는 유저가 웹 서비스에 접근하거나, 클러스터 내부의 백엔드 또는 DB에 리소스를 요청할 때 큰 제약사항 서비스 오브젝트는 이러한 문제를 해결하기 위해 애플리케이션에 접근 가능한 고정된 IP를 제공하는 역할 서비스 타입은 4종류가 존재 ClusterIP NodePort LoadBalancer ExternalName 2. 서비스 타입 ClusterIP 서비스 오브젝트의 기본 타입으로 NodePort 등 별도의 옵션을 설정하지 않을 경우 디폴트로 ClusterIP로 설정 클러스터 내부에서만 접근 가능한 ClusterIP라는 Virtual IP를 생성하고, 내부 리..
1. 네임스페이스 개념 쿠버네티스 클러스터 내에서 파드, 디플로이먼트 등 오브젝트를 서로 격리하기위해 네임스페이스를 사용 네임스페이스는 일종의 "집"으로 다른 네임스페이스에 존재하는 오브젝트는 서로 간섭할 수 없음 네임스페이스마다 개별적으로 접근제어, 자원 할당 등 설정 가능 prod, dev, service 1, service 2 등 목적별로 네임스페이스를 나누어서 클러스터를 관리하는 것이 운영·관리·보안 측면에서 유리 쿠버네티스 클러스터 주요 컴포넌트는 kube-system 네임스페이스에 존재 2. YAML을 활용한 네임스페이스 생성 zero라는 이름의 네임스페이스를 생성하는 YAML 내용 apiVersion: v1 kind: Namespace metadata: name: zero 3. 명령어를 활용..
