Passwd

이미지 버전, 디스크 용량, 애플리케이션 관리자 비밀번호 등 쿠버네티스 환경에서 애플리케이션은 환경에 따라 다른 값을 가질 수 있다. Helm은 아래와 같은 방식을 통해 하나의 패키지로 여러 환경을 구성할 수 있도록 한다. - 값을 변수로 취급할 수 있도록 파일을 템플릿으로 변환한다. - 변수는 중괄호로 감싸서 나타내며, 값을 식별할 변수명을 적는다. 값은 values.yaml에 저장된다. 즉, 템플릿과 values.yaml이 결합한 것이 쿠버네티스가 클러스터에 애플리케이션을 배포하는 데 사용하는 정의 파일에 해당한다. helm chart template + values.yaml + Chart.yaml Chart.yaml에는 차트의 이름, 버전, 설명과 같은 차트와 관련된 정보들이 저장되어 있다. 사용자..

이 글에서는 Helm을 설치하는 방법에 대해 간단히 정리한다. Helm은 리눅스, 윈도우, 맥 OS 등의 환경에 설치할 수 있으며, 설치에는 아래와 같은 전제 조건이 필요하다. 1. 동작 중인 kubernetes Cluster 2. 적절한 자격 증명이 구성된 kubectl Snap (Linux) snap install helm --classic snap; snapcraft Canonical에서 개발한 소프트웨어 배포 및 패키디 도구. 패키지 관리 시스템 샌드박스 형태의 애플리케이션 포맷을 사용함으로써 의존성 문제를 완화하고 애플리케이션 간 간섭일 불가능한 보안 환경을 특징으로 한다. apt (Debian/Ubuntu) Key 및 소스 리스트를 추가해야 한다. curl https://baltocdn.com..

Kubernetes 클러스터에 배포된 애플리케이션이 얼마나 복잡하든, Kubernetes는 각 인프라를 관리할 수 있다. 다만 Kubernetes는 클러스터에 선언된 객체가 존재하고 동작하는 상태를 유지할 뿐, 클러스터 내에서 동작하고 있는 애플리케이션에는 관심이 없다. 즉, 부분 각각을 개별적으로 관리하고 처리한다. Helm Kubernetes 클러스터 내의 각 부분을 애플리케이션과 함께 고려하기 위해 개발되었으며, Kubernetes의 패키지 매니저라고 불린다. Helm은 Kubernetes 객체를 큰 패키지의 부분으로 취급한다. 따라서 Kubernetes 관리자는 변경 작업 수행 시 어떤 패키지에 대해 어떤 개체를 어떻게 변경해야 하는지 지시해야 한다. 패키지 설치 Helm은 설치 마법사와 같이 애..

이 글에서는 2022.01.24 - Deployment Strategy - Blue Green 에 이어서 Canary라고 불리는 Deployment Update 전략에 대해 정리한다. Canary Updates Canary Updates의 진행 방식은 아래와 같다. 업데이트 진행 순서 1. 기존 버전의 Deployment이 동작하고 있는 환경에 새 버전의 Deployment을 배포한다. 단, 전체 트래픽의 적은 비율만을 새 버전의 Deployment로 라우팅 되도록 한다. 즉, 이 단계에서는 대부분의 트래픽이 기존 버전의 Deployment로 라우팅되는 상태이다. 2. 새 버전의 Deployment에 대한 테스트가 완료되면, 기존 버전의 Deployment를 새 버전으로 업그레이드(Rolling upda..

2021.08.07 - Rolling Updates & Rollbacks in Deployments 위의 이전 글에서 Deployment의 update 전략 중 recreate 전략과 rolling update 전략을 정리했었다. 그 내용을 간단하게 요약하면 아래와 같다. Deployment Strategy - Recreate 기존 버전의 Pod를 모두 삭제한 후, 새 버전의 Pod를 한꺼번에 생성하는 방법 기존 버전을 중지하고 새 버전이 정상적으로 동작할 때까지 서비스 중단이 발생한다. Deployment Strategy - Rolling Update 기존 버전의 Pod 하나를 삭제한 후, 새 버전의 Pod 생성을 반복하는 방법 서비스 중단이 발생하지 않으며 Deployment Upgrade Start..

Operator Framework Custom Resource Definition(사용자 정의 리소스 정의, CRD)와 Cutom Resource를 관리하는 Custom Controller(사용자 정의 컨트롤러)는 별개의 객체이다. 또한, Custom Resource를 사용하기 위해서는 CRD와 Custom Controller를 수동으로 생성 및 배포해야 한다. Operator Framwork는 이 두 개의 객체를 단일 객체로 배포할 수 있도록 패키징 한 것이다. 즉, Operator를 배포함으로써 내부적으로 CRD 및 리소스를 생성하고 Controller를 Deployment로 배포할 수 있다. Operator와 관련된 정보는 아래 hub에서 찾을 수 있다. https://operatorhub.io/ ..

Controllers는 ETCD에 저장된 객체의 상태를 모니터링하고, 객체를 생성/수정/삭제한다. 또한, 반복해서 동작하는 프로세스 또는 코드이며 지속적으로 쿠버네티스 클러스터를 모니터링하면서 특정 객체의 이벤트를 감지한다. 그중 Custom Controllers는 사용자 정의 리소스(Custom Resources)를 관리하는 컨트롤러에 해당한다. Custom Controllers 코드 작성은 필요하지만, 인증과 같은 공통 태스크 처리를 구현한 클라이언트 라이브러리를 사용하면 되기 때문에 API 호출 맟 요청/응답을 직접 구현할 필요는 없다. 클라이언트 라이브러리 https://kubernetes.io/ko/docs/reference/using-api/client-libraries/ 구축 방법 1. 개발..

Resources Kubernetes는 pod, deployment와 같은 리소스를 생성하고, 해당 정보는 ETCD에 저장한다. 즉, 리소스를 생성하고 삭제하는 작업은 ETCD에 리소스를 생성하고 삭제하는 것과 동일하다. Controllers 실질적으로 Resource 생성 및 관리를 수행하는 주체로, Deployment 리소스를 관리하는 Controller는 Deployment Controller에 해당한다. 백그라운드로 실행되는 프로세스이며, 관리하는 리소스를 지속적으로 모니터링하며 설정 정의된 상태를 유지한다. Controller는 GO로 개발되어, Kubernetes에 기본 내장되어 있어 별도로 생성할 필요가 없다. Custom Resources Kubernetes 기본 리소스 외의 사용자 정의 ..

하나의 API Group은 여러 개의 API Version을 지원한다. 그렇다면 여러 버전을 지원해야 하는 이유는 무엇이며, 몇 가지 버전을 지원해야 하는가? 더 이상 사용하지 않는 오래된 버전은 어느 시점에 제거할 수 있는가? 이 글에서는 위와 같은 부분을 위한 Kubernetes API Deprecations(지원 중단 정책)에 대해 정리한다. Deprecations 정책 1. API 요소는 API Group의 버전을 증가시키는 방법으로만 제거할 수 있다. 즉, v1alphav1의 요소는 v1alphav2 이상의 버전에서 삭제할 수 있다. 2. API 개체는 일부 버전에 존재하지 않는 전체 REST 리소스를 제외하고, 특정 릴리스의 API 버전 간에 정보 손실 없이 변경할 수 있어야 한다. 즉, v1..

각 API Group의 버전은 크게 세 가지 버전이 존재하며 그 종류는 아래와 같다. 버전 /v1alpha1 : alpha 개발 후 Kubernetes에 처음으로 release 된 API다. 테스트 부족으로 치명적인 버그가 존재할 수 있다. 예고 없이 삭제될 수 있으며 이후 release에서 사용할 수 있다는 보장 자체가 없다. 기본적으로 활성화되지 않아 사용을 위해서는 내부적으로 활성화가 필요하다. API Group 테스트 및 피드백에 관심이 있는 사용자를 위한 API다. /v1beta1 : beta alpha 버전의 주요 버그 수정 및 end to end 테스트가 완료된 API 버전이다. /v1으로 이동될 가능성이 존재해 기본적으로 활성화되어 있으나, 마이너한 버그는 여전히 존재할 수 있기 때문에 피..