Kustomize 구조

Kustomize는 폴더를 수작업으로 생성해야한다.

메인폴더

• 디폴트 포맷 폴더

  • kustomization.yaml ← 배포할 파일 선택 및 공통값 설정

  • 베이스 YAML 파일

• 오버레이 영역 폴더

  • 배포 환경을 각 폴더로 구분해 선택적으로 배포할 수 있음

    • kustomization.yaml ← 배포할 파일 선택 및 공통값 설정

    • 배포 환경에 맞게 오버레이 될 파일

배포할 파일 선택에 대한 차이점

• Helm: hpa.yml 파일에서 선언한 조건문이 values.yaml 파일에 의해 제어되어 배포됨

• Kustomize: kutomization.yaml 파일에 배포할 파일을 명시적으로 선언해 배포

공통값 설정에 대한 차이점

• Helm: YAML 템플릿 내에 다른 파일에서 변수를 주입됨

• Kustomize: Kustomization.yaml 파일 내 coomonLabels 키의 Lables가 모든 YAML 파일에 주입됨

환경별 설정에 대한 차이점

• Heml: values-dev.yaml, values-qa.yaml, values-prod.yaml 로 구별

배포 명령에 -f 옵션으로 환경 파일를 선택: helm install api-tester-32222 ./app -f ./app/values-dev.yaml

• Kustomize: 각 환경 폴더 dev, qa, prod 로 구별

배포 명령에 폴더를 선택: kubectl apply -k ./app/overlays/dev

1. 다양한 배포 환경을 위한 Kustomize 배포하기 - 2222

dev 개발환경이 선택되어 있다. -> Jenkins 파일 내에 있지만 처음 배포에 인식 안됨

dev 환경으로 배포 시작

실제 실무 환경에서는 K8s 네임스페이스 구분이 없어도 문제되지 않는다.

2. 다양한 배포 환경을 위한 Helm 배포하기 - 2223

배포 파이프라인 구축 후 마주하게 되는 고민들

1. 컨테이너 빌드 후 도커 허브에 업로드할 때 사용되는 config.json에는 도커 허브의 사용자 정보가 저장된다. config.json 파일은 암호화가 되지 않기 때문에 인증 정보가 노출될 수 있다. Helm에서 사용하는 K8s 클러스터의 인증서는 리눅스 ROOT 권한으로 관리되어 인증서 파일을 복사하면 누구나 K8s 클러스터에 API 요청을 진행할 수 있다.

⇒ CI/CD 서버의 접근 제어를 강화해야한다.

⇒ 도커 허브 계정 정보와 K8s 클러스터 인증서를 Jenkins의 Credential로 등록하고 암호화하여 관리한다.

⇒ 도커의 경우 Jenkins에서 암호화하더라도 config.json은 암호화되지 않는다, 배포시마다 로그인/로그아웃을 해 접속 정보를 삭제해야 한다.

⇒ docker-credential-helpers는 config.json에 대한 암호화를 제공한다.

2. 컨테이너 빌드가 지속적으로 진행되면서 CI/CD에 컨테이너 이미지가 누적된다. 서버의 디스크가 모두 사용되면 Jenkins 서비스가 중단된다.

⇒ 도커 허브에 업로드 후 CI/CD 서버에 만들어진 이미지를 삭제한다.

3. Helm을 통해 여러 App을 배포할 때 지난 실습처럼 App 하나마다 네임스페이스를 만들지 않고, 별도의 그룹 개념으로 App을 묶어 관리하는 경우가 많다.

⇒ 네임스페이스는 배포와 별도로 관리하는게 좋다, Helm 앱을 삭제할 때 네임스페이스를 제거하면 네임스페이스에 포함된 리소스가 삭제되므로 Helm은 의도적으로 삭제하지 않는다.

4. 배포 이후에 Pod가 완전히 정상적으로 기동됐는지 체크가 필요하다.

⇒ Helm의 자주 쓰는 부가 기능으로 --wait 옵션을 사용한다.

5. K8s는 Deployment의 Template 영역의 수정이 발생해야 업그레이드를 진행하므로 Helm 배포를 해도 업그레이드가 되지 않는 경우가 있다.

⇒ Helm의 자주 쓰는 부가 기능으로 annotations를 사용해 새 배포시마다 랜덤 값 생성해 Helm 배포시마다 K8s가 업그레이드를 수행하도록 한다.

6. 컨테이너 이미지의 태그 관리에서 개발환경은 잦은 배포를 진행하므로 versioning의 의마가 없지만, 검증/운영 환경은 계획된 배포를 진행해 versioning이 필수이다.

⇒ 컨테이너 이미지의 버전 명명 규칙상 v를 제거하는게 맞다.

⇒ 개발 환경은 이미지 태그로 latest를 사용하고, pullPolicy로 Always(항상 도커 허브에서 이미지를 가져온다)를 사용한다. 단, 인터넷 연결이 없으면 도커 허브에 접근을 못하므로 Pod 생성이 실패되고, Heml의 annotations을 사용하지 않는다면 이미지 태그가 latest로 고정되어 Template 수정이 없으므로 K8s가 업그레이드를 전혀 수행하지 못한다.

⇒ 검증/운영 환경은 이미지 태그에 버전을 명시하고, pullPolicy로 IfNotPresent(K8s Node에 해당 이미지가 있으면 사용, 없으면 도커 허브에서 다운로드)를 사용한다. 운영 환경에서 Pod가 재시작되거나 스케일링이 작업 중인 상태에서 이미지를 도커 허브에서 다운로드받는 비효율적인 작업이 생략된다.

7. 개발 환경에서 컨테이너 이미지에 대란 롤백을 요청하는 경우

⇒ 개발 환경의 빌드부터 버전 관리를 시작해 개발자가 요청하는 버전으로 교체될 수 있도록 대응한다.

매 배포시마다 이미지 태그가 변하므로 pullPolicy를 IfNotPresent로 변경해도 K8s에서 업그레이드를 수행할 수 있다.

8. 컨테이너 이미지를 받는 사람은 Latest가 단순 최신 개발 버전이 아닌, 운영환경까지 배포된 최신 안정화 버전으로 기대하고 다운로드 받는다.

⇒ 프로젝트가 커질 수록 개발 이미지를 버전 관리하면서 바꿔가는게 좋다.

9. CI/CD 서버와 마찬가지로 K8s 클러스터도 이미지를 계속 다운로드 받는다.

⇒ Kubernetes Garbage Collector에서 사용하지 않는 이미지는 자동으로 삭제된다.

 3. 배포 파이프라인 구축 후 마주하게 되는 고민들 2224

 3-3-1. 중요 데이터 암호화 관리

 3-3-1-1. 도커 접속 정보 및 쿠버네티스 config를 위한 New credentials 생성

 ● Docker 접속정보 Credentials 등록

 3-3-1-3. CI/CD Server에서 Docker Logout 및 kubeconfig 삭제

3-4. [파라미터와 함께 빌드] 실행 후 PROFILE을 [dev]로 선택하고 [빌드하기] 클릭

 (빌드를 계속 하는 중,.,,,,)