(14) Helm과 Kustomize 비교하며 사용-2

⚓ 쿠버네티스 어나더 클래스 (지상편) - Spring 1, 2 을 듣고 작성하는 복습 블로그 입니다.

 

패키지 구조 비교 및 배포하기

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

 

1-1. 아이템 생성

• name : 2222-deploy-kustomize
• copy from 2221-deploy-helm

1-2. 옵션 수정

• Spare Checkout paths > Path : 2222
• Script Path : 2222/Jekinsfile

1-3. 배포 시작에서 Abort 누르기

• 최초 실행시엔 매개변수 입력 버튼이 안나오고, [dev / qa / prod] 중 dev가 적용된다
• 스크립트에 있는데 처음에 실행할 때는 젠킨스 파이프라인이 모르기 때문에 그냥 dev로 적용

1-3-2. 다시 빌드하면 PROFILE 을 선택해서 빌드할 수 있다

 

• 구성에 들어가서 보면 매개변수로 지정되어 있다

1-3-3. Stage View

 

1-4. 디렉토리 설명

 

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

1-1. 아이템 생성

• name : 2223-deploy-helm
• copy from 2222-deploy-kustomize

1-2. 옵션 수정

• Spare Checkout paths > Path : 2223
• Script Path : 2223/Jekinsfile

2. 배포하기

• 이전 아이템을 복사해왔기 때문에 배포 환경이 미리 들어있다

 

3. 코드 확인

stage('헬름 템플릿 확인') {
    steps {
        // K8S 배포
        sh "helm template api-tester-${CLASS_NUM} ./${CLASS_NUM}/deploy/helm/api-tester" +
           " -f ./${CLASS_NUM}/deploy/helm/api-tester/values-${params.PROFILE}.yaml -n anotherclass-222-${params.PROFILE}"
        // --set replicaCount='3' --set port='80' --set profile='dev' --set nodeport='32223'
    }
}

stage('헬름 배포') {
    steps {
        input message: '배포 시작', ok: "Yes"
        sh "kubectl apply -f ./${CLASS_NUM}/deploy/kubectl/namespace-${params.PROFILE}.yaml"
        sh "helm upgrade api-tester-${CLASS_NUM} ./${CLASS_NUM}/deploy/helm/api-tester" +
           " -f ./${CLASS_NUM}/deploy/helm/api-tester/values-${params.PROFILE}.yaml" +
           " -n anotherclass-222-${params.PROFILE} --install"  //  --create-namespace
    }
}

• values 파일에 dev 를 붙여서 환경변수 파일을 만들어준다
• 템플릿에서 사용하는 변수들은 values 파일에 저장하고, 값을 뒤집어 쓴다
• set 옵션을 주면 최종적으로 반영되는 변수
• helm 배포에는 namespace 를 반영시키는게 좋지 않아서 따로 분리

 

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

중요 데이터 암호화 관리

• 젠킨스가 컨테이너 빌드를 통해서 dockerhub로 업로드도 하고 helm 배포도 한다
• dockerhub 에 업로드를 하기 위해서 config.json 파일이 생성
  • 암호화가 안되어 있기 때문에 값을 볼 수 있다

Jenkins 에 Credential 로 등록

• 인증서를 암호화한 상태에서 사용할 수 있다
• 배포시마다 로그인/로그아웃하는 명령어를 넣어야 한다
• 로그아웃시 접속 정보 삭제
• docker-credential-helpers : 암호화 제공
• Dashboard > Jenkins 관리 > Credentials > System > Global credentials (unrestricted) 에서 [Add Credentials]
• kind : Username with password (도커 허브 로그인 패스워드 입력)
• Kind : Secret file (쿠버네티스 클러스터 접근 인증서)

 

업로드 후 CI/CD Server 에 만들어진 이미지 삭제

• 컨테이너 빌드를 하다보면 이미지가 계속 생긴다
• 용량을 많이 차지 할 수 있다.
• 그러므로 이미지를 주기적으로 삭제해줘야 한다
• 쿠버네티스가 사용 안하는 이미지는 자동 삭제해준다

stage('컨테이너 빌드 및 업로드') {
  steps {
	script{
	  // 도커 빌드
      sh "docker build ./${CLASS_NUM}/build/docker -t ${DOCKERHUB_USERNAME}/api-tester:${TAG}"
      sh "docker push ${DOCKERHUB_USERNAME}/api-tester:${TAG}"
      sh "docker rmi ${DOCKERHUB_USERNAME}/api-tester:${TAG}"   // 이미지 삭제

 

네임스페이스 배포와 별도로 관리

• 네임스페이스는 앱과 별도로 관리를 해주는게 좋다

stage('네임스페이스 생성') {  // 배포시 apply로 Namespace 생성 or 배포와 별개로 미리 생성 (추후 삭제시 별도 삭제)
  steps {
    withCredentials([file(credentialsId: 'k8s_master_config', variable: 'KUBECONFIG')]) {
      sh "kubectl apply -f ./2224/deploy/kubectl/namespace-dev.yaml --kubeconfig " + '"${KUBECONFIG}"'
...
stage('헬름 배포') {
  steps {

 

Helm 부가기능

• pod 가 완전히 기동됐는지 체크 필요
  • helm command —wait
• 배포해도 업그레이드가 진행되지 않는 경우
  • metadata.annotaions : 새 배포 시 마다 랜덤값을 생성
  • 그래서 배포시마다 새 랜덤값이 생성되어서 업그레이드가 진행

 

이미지 태그

• api-tester:v1.0.1
  • 버전 규칙상 v를 빼는게 맞다
• 개발환경 (잦은배포, 버저닝 무의미)
  • image: api-tester:latest
  • pullPolicy: Always (항상 hub에서 이미지를 가져옴)
  • 개발하다보면 이전버전으로 돌려달라고 하는 경우가 있는데 위처럼 버저닝을 하면 어렵다
  • image: api-tester:1.0.1-202312.181512 (배포 시마다 새 태그 달기, 날짜 / Git커밋 No / Jenkins 빌드 seq)
  • pullPolicy: ifNotPresent
• 검증환경 / 운영환경 (계획된 배포, 버저닝 필수)
  • image : api-tester:1.0.1
  • pullPolicy: IfNotPresent (Node에 해당 이미지가 있으면 그걸 먼저 사용하고, 없으면 hub 확인)