💡 Deployments replicaset의 상위 오브젝트 replicaset에 없는 배포 작업의 세분화, 롤링업데이트, revision 등의 기능을 사용 가능 Yaml & kubectl 기반 Deployment 생성 # 생성, --replicas=3 으로 레플리카 수 지정 가능 kubectl create deployment [deploy-name] --image=[image-name] --dry-run=client -o yaml > [yaml-name] # Yaml 생성 apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment labels: app: nginx spec: replicas: 3 selector: matchLabels: ..

💡 Labels 쿠버네티스 객체를 식별할 수 있고, 그룹으로 구성 가능한 기능 좋은 Use-Case는 Pod에 배치된 어플리케이션을 기반으로 그룹핑 하는것과 환경이나 고객 & 팀 & 소유자 & 릴리즈 버전에 따라 그룹화 하는 다양한 레이블 규칙 개발 가능 리소스를 생성할때 레이블을 무조건 지정해서 사용하기 커밋 컨벤션 처럼 레이블 컨벤션을 도입하기 Pob Template 활용, 파드 템플릿은 쿠버네티스 컨트롤러에서 파드를 생성하기 위한 manifest 파일임 공통적인 옵션들에 대한 레이블 리스트 만들기 (어플리케이션id, 버전, 소유자, 환경, 릴리즈 버전 등) 더 광범위한 레이블 리스트 만들기 쿠버네티스에서 추천하는 레이블 사용 Lable List Exsample # 쿠버네티스 추천 레이블 apiVer..

💡 Namespace 물리 클러스터 기반의 가상 클러스터, 기본 네임스페이스는 default 이다. 같은 네임스페이스 내에서 리소스의 이름은 중복 불가능 Kubectl 기반 Namespace 생성 # 1. yaml의 metadata 하위 name: 에 지정해도 됨 # 2. 리소스를 생성할때 -n [namespace-name] 으로 옵션 지정도 가능 # 3. kube-node-lease, kube-system, kube-public 네임스페이스는 사용하지 않는게 좋음 # Namespace 생성 kubectl create namespace [namespace-name] # Namespace 조회 kubectl get ns # 기본 Namespace의 모든 Resource 조회 kubectl get all -..

💡 Pod 클러스터 안에서 배포되는 가장 작은 단위의 객체 기본 개념 1개 이상의 컨테이너를 모아놓은 것으로 쿠버네티스 어플리케이션의 최소 단위 Pod는 노드IP와 별개로 고유IP를 할당 받으며, Pod 안의 Container들은 그 IP를 공유한다 파드 안의 컨테이너들은 동일한 볼륨과 연결이 가능하다 Pod의 Lifecycle Pending 단계로 시작해서 컨테이너 실행이 성공하면 OK, 실패시 Pendind & Failed Pod 실행 실패 시 kubectl logs [pod-name] | events 을 입력해 실패 이벤트 로그를 확인 Kubectl 기반 Pod 생성 & 관리 # Pod 생성 kubectl run [pod-name] --image=[image-name] --dry-run=client..

💡 Kubernetes 구성 컨트롤 플레인 컴포넌트 클러스터에 관한 전반적인 결정을 수행하고 클러스터 이벤트를 감지하고 반응한다. API-Server Control Plane(Master) 의 중심 컨트롤 플레인 컴포넌트, 모든 역할의 출발점 etcd 모든 클러스터의 데이터가 저장 되어 있는 고가용성 Key-Value Database etcd는 항상 백업해두자 Scheduler 새로 생성된 Pod를 감지하고, 컨테이너를 생성할 노드를 선택하는 컨트롤 플레인 컴포넌트 결정을 위해 고려되는 요소 리소스에 대한 개별 & 총체적 요구사항 하드웨어, 소프트웨오, 정책적 제약 Affinity & Anti-Affinity 명세 데이터 지역성, 데드라인 Controller-Manager 컨트롤러 프로세스를 실행하는 컨..