본문 바로가기

쿠버네티스

(15)
kubernetes statefulset kubernetes statefulset 관리하고 구성,유지,스케일링측면에선 디플로이먼트와 유사한 특징을 갖고있지만 차이점은 각 파드의 순서,고유성을 보장하며 영구스토리지 볼륨에 할당함 -파드의 이름 (pod-1,pod-2 ....) -파드의 볼륨 즉 문제가 생긴 파드와 똑같은 이름,IP를 가진 파드로 유지생성된다 파드내의 프로그램,기타다른정보들을 저장하고자 하는경우 사용한다. ●kubernetes statefulset 생성,관리 레플리카셋,레플리케이션,디플로이등등 서비스는 기본적으로 레이블셀렉터를 기준으로 생성관리해주지만 스테이트풀셋의경우 파드를 고유하게 식별해야 관리할 수 있다. 그러기위해선 헤드리스 시버스를 지정해야한다 ( serviceName: ) 예제 apiVersion: apps/v1 kind..
kubernetes daemonset controller kubernetes daemonset controller 데몬셋 컨트롤러는 노드당 1개씩의 pod를 보장해준다. 특정 node에만 pod보장도 가능하다. 로그수집,모니터링 같은 항상실행 시켜두어야 하는 POD에 적용된다. 데몬셋 예제 apiVersion: apps/v1 kind: DaemonSet metadata: name: nginx-daemonset spec: selector: matchLabels: app: web version: "1.14" template: metadata: labels: app: nginx version: "1.14" spec: containers: - name: nginx image: nginx:1.14 nodeSelector: node: daemon rolling updat..
kubernetes deploymemt rollingupdate kubernetes deploymemt rollingupdate 디플로이먼트는 쿠버네티스에서 상태가없는 앱을 배포할때 가장 기본적인 컨트롤러이다. 디플로이먼트는 레프리카셋을 관리하면서 앱 배포를 더 세밀하게 관리한다. 파드갯수를 보장해주는것 뿐만아니라 롤링,롤백업데이트를 지원한다. 롤링업데이트(rollingupdate): 파드를 점진적으로 새로운것으로 업데이트 하여 서비스 중단 없이 이루어질 수 있도록 함 레플리카셋을 제어해주는 부모역할을 하는 디플로이먼트. ●deployment Controller 생성 ,관리 및 확인 NAME READY STATUS RESTARTS AGE pod/nginx-deploy-84455b7b7c-7ffbf 1/1 Running 0 13s pod/nginx-deploy-8445..
kubernetes replicaset controller kubernetes replicaset controller replicaset은 레플리케이션 컨트롤러와 같은역할을 한다 파드의 갯수를 보장 ...등 한가지 차이점은 집합성 기준의 풍부한 레이블 셀렉터(matchlabels,matchExpressions)를 지원한다.레플리카셋 컨트롤러의 API 버전은 apps/v1버전을 사용 레플리케이션 컨트롤러: key:value 타입 의 일치성 기준 "키=값" 둘다 일치해야만 지원레플리카셋 컨트롤러 : 집합성+일치성 기준 "키=값" ,"키=X" 둘다 일치 혹은 둘중하나만 일치해도 지원 matchExpressions 연산자 ●In : key:value 의 지정된 값이 일치해야 하는 pod만 연결 ●Notin : key는 일치하고 value는 일치 하지않은 pod에 연결 ..
kubernetes pod 환경변수 설정 kubernetes pod 환경변수 설정 Pod내의 컨테이너가 실행될때 필요로 하는 변수 컨테이너 제작시 미리 정의할수있음. Pod 실행시 미리 정의된 컨테이너 환경변수를 변경할수있음. apiVersion: v1 kind: Pod metadata: name: ngin-pod-env spec: containers: - image: nginx:1.14 name: ngin-pod-env ports: - containerPort: 80 env: - name: MYVAR value: "testvalue" ●env: 필드값 name: 사용할 환경변수의 이름을 설정 value: 문자열이나 숫자 형식의 값을 설정 valueFrom:값을 직접 할당하는 것이 아니라 어딘가 다른곳에서 참조하는 값을 설정 fieldRef:파..
kubernetes Pod resource setting 파드 자원관리 kubernetes Pod resource Setting 쿠버네티스에서 Pod 실행,배포시 worker node의 H/W상태를 체크.점검하여 가장 적합한 worker Node에 실행,관리시켜주는 컴포넌트는 master Node의 scheduler 이때 사용량이 많은 파드가 한 node 몰려서 동작시 효율성이 낮아진다. 이를 방지하는 몇가지 기능 중 Pod의 컨테이너 용도에 맞게 CPU,MEM 사용량을 관리해주는것을 kubernetes Pod resource setting 이라고 한다. ●Pod 리소스 단위 쿠버네티스 파드 리소스 표현단위 프로세서(CPU): M , 1 (core) 메모리(memory): Ki , Mi , Gi ●Pod 리소스 요청 및 제한 쿠버네티스 파드 리소스관리의 요청,제한은 두가지로..
kubernetes create & apply 차이점? 쿠버네티스 create VS apply 차이점 쿠버네티스의 Pod 를 배포하는 명령어로 kubectl create 와 kubectl apply 의 두가지 명령어가있다. ●kubectl create : 명령형 관리를 위한것 create는 새로운 리소스를 생성하고 리소스가 이미 존재하면 error가 발생함 ●kubectl apply : 선언적 관리를 위한것 apply는 기존리소스에 변경사항을 적용시켜주고 유지관리시켜줌 리소스가 이미 존재하면 error없이 변경사항만 적용 command 리소스가 존재하지 않을 경우 리소스가 이미 존재할 경우 create 새로운 리소스가 생성 ERROR가 발생 apply 새로운 리소스가 생성 리소스를 구성 (부분적인 spec을 적용) replace ERROR가 발생 리소스가 삭..
kubernetes static pod & kubelet kubernetes static pod & kubelet kube-apiserver를 통하지 않고 kubelet 데몬이 직접 관리,생성한다. 정적인 파드만 실행가능하며 기타리소스는 사용할 수 없다. 보통 static pod는 api,etcd같은 시스템파드를 실행하는 용도로 많이사용 노드마다 존재하는 특정경로에 yaml을 배치하면 실행된다 ( /etc/kubernetes/manifests/ ) 기존 Pod의 실행방식은 kubectl -> master node의 API 요청 -> etcd -> scheduler -> 최적의 node에 실행 static pod는 기존 실행방식이 아닌 각 master node를 포함한 모든 노드는 kubelet 데몬이 동작하고 있는데 kubelet 이 관리하는 static po..