헬름 차트는 템플릿 파일들의 집합이다. 헬름은 차트를 관리하는 쿠버네티스 패키지 매니저 도구다. 헬름은 차트와 차트 압축 파일을 만들 수 있다. 헬름은 차트 저장소와 연결해 쿠버네티스 클러스터에 차트를 설치 / 삭제 할 수 있다. 헬름은 차트들의 배포주기를 관리할 수 있다. 용어 정리 차트 : 쿠버네티스에서 실행할 어플리케이션을 만드는데 필요한 정보 묶음 컨피그 : 패키지한 차트에 넣어서 배포 가능한 오브젝트를 만들 때 사용할 수 있는 설정 릴리즈 : 특정 컨피그를 이용해 실행중인 차트의 인스턴스 헬름 클라이언트 : 헬름의 커맨드라인 인터페이스 틸러 서버 : 쿠버네티스 클러스터 안에서 헬름 클라이언트의 명령을 받아 쿠버네티스 API 와 통신하는 서버 차트 뮤지엄 : 차트를 사내에서만 운영해야할 경우 차트..

사용자 정의 자원 사용자 정의 자원 : 쿠버네티스에서 제공하는 내장 자원(Pod, Service) 이외에 사용자가 필요한 자원을 정의 할 수 있다. 사용자 정의 컨트롤러 : 사용자 정의 자원 자체는 구조화된 데이터이고 이를 이용해서 원하는 동작을 하려면 사용자 정의 컨트롤러 API 가 필요하다. 선언적 API 예시 파드를 2개 더 생성하라. (x) 파드가 2개 실행되어야 한다. (o) 트랜잭션을 엄수해야하는 정확한 상태를 명령하는 식이면 안된다. 오브젝트들이 어떤 상태인지를 바라는 지만 나타내야한다. 사용자 정의 자원을 정의 하는 방법 CRD 템플릿을 만든다. CRD를 관리하는 추가 서비스는 없어도된다. 사용자 정의 자원은 kube-apiserver 가 관리한다. Aggregated API Go 언어로 ..

HPA (Horizontal Pod Autoscaler'0 파드를 오토스케일링 해주는 컨트롤러 매니저 오토스케일링 계산식은 다음과 같다. ex. 타겟 CPU 사용률 : 60 파드 A CPU 사용률 : 80 파드 B CPU 사용률 : 50 Math.ceil(80 + 50 / 60) = 3 따라서 파드는 3개로 유지된다. 오토스케일링 샘플 apiVersion: autoscaling/v1 kind: HorizontalPodAutoscaler metadata: name: kubernetes-simple-app-hpa namespace: default spec: maxReplicas: 10 minReplicas: 1 scaleTargetRef: apiVersion: extensions/v1beta1 kind: D..

컨테이너의 로그 수집 컨테이너 로그 수집은 보통 컨테이너 런타임인 도커가 담당한다. 앱컨테이너가 stdout, stderr 스트림을 이용해 로그를 출력하면 로그 드라이버로 리다이렉트하여 출력하게 설정되어있다. 파드의 로그 확인하기 kubectl logs -f 파드이름 명령어를 이용하면 파드가 떠있는 노드에 접근하지 않아도 파드의 로그를 확인할 수 있다. -f 옵션은 로그를 지속해서 수집하는 테일링 옵션이다. 실시간으로 여러개 파드의 로그를 지켜보고 싶을 때는 실시간 로그모니터링 도구인 스턴을 사용할 수 있다. 전통적인 어플리케이션 운영 환경에서의 로깅 로컬 파일 시스템의 지정된 위치에 로그를 저장한다. 로그로테이트를 이용해 로그를 일정 기간만 보관한다. 이런 방식은 항상 지정된 장비에서만 실행된다는 것이..

쿠버네티스 DNS 파드 사이에 통신할 때 IP 가 아닌 도메인을 사용할 수 있다. 특정 서비스에 접근하는 도메인은 "서비스이름.네임스페이스.svc.cluster.local" 이다. 특정 파드에 접근하는 도메인은 "파드IP주소.네임스페이스.pod.cluster.local" 이다. 하지만 파드의 IP 를 도메인에 포함시키면 도메인을 사용할 이유가 없다. DNS 를 클라이언트나 API 게이트웨이가 호출할 서비스를찾는 서비스 디스커버리 용도로 사용할 수 도 있다. DNS 질의 구조 DNS 도 쿠버네티스 클러스터 안에서 파드로 실행되는 것이다. 파드마다 도메인이름을 어떤 순서로 찾을지 설정할 수 있다. 이 때 .spec.dnsPolicy 를 사용한다. .spec.dnsPolicy 는 다음 과 같은 타입을 가질 수..

도커 컨테이너의 네트워킹 일반적인 도커 컨테이너 네트워크는 브리지 타입 네트워크 구조로 되어있다. 브리지 타입 네트워크 구조는 아래와같다. 호스트는 호스트 네트워크 네임스페이스를 가진다. 그리고 여기에 docker0 라는 브리지를 만든다. 컨테이너는 컨테이너 네트워크 네임스페이스를 가진다. 그리고 여기에 컨테이너를 만든다. 컨테이너 네트워크 네임스페이스에는 가상 이더넷(베스)을 가지고 있다. 도커는 docker0에 베스들을 연결하여 통신한다. 네트워크 네임스페이스는 서로 연결되기 전까지 독립적으로 동작한다. 네트워크 네임스페이스는 별도의 ARP, 라우팅, iptable 을 가진다. 도커 컨테이너의 네트워크 타입 브리지 : 호스트에 브리지를 만들고 컨테이너와 호스트는 가상 이더넷(베스)을 이용해 연결한다...