[2-6] Helm과 Kustomize 비교하며 사용하기 (2)

📚 패키지 구조에서 Helm VS Kustomize

Helm

• 패키지 자동 생성
• hap.yaml 파일에 {{-if.Values.autoscaling.enabled}} 이 있고 values.yaml에서  false를 하면 배포가 안됨

 

Kustomize

• 패키지 직접 생성 + 하위 폴더 구성도 직접 구성해야함
• Kustomization.yaml : 어떤 파일을 배포할 것인지 선택 및 공통값 선택
• 실제 overlay 할 파일들은 또 따로 지정해야함

	Helm	Kustomize
패키지 생성	자동 생성	직접 생성 + 하위 폴더 직접 구성
패키지 구성	templates	base
공통값 설정	deployment 내에 변수 넣음	Kustomization.yaml에 commonLabels

 

 

 

---

 

 

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

문제

• Helm 배포에 필요한 인증서와 docker 로그인에 사용한 config.json(암호화 안되어 있음) 보안 관리가 필요함
• 디스크를 교체하게 됐을때 누군가 복원할 수 있음
• 따라서 디스크에는 암호화되진 않는 중요한 정보를 남기지 않아야 됨

해결책

• 이 둘을 Jenkins에 들어가서 Credential 등록을 하자!!
• -> 그러면 인증서를 암호화 시킨 상태에서 사용할 수 있음
• -> 등록한 사람도 등록한 이후에는 이 내용을 볼 수가 없음

---

문제

• 그런데 도커 로그인의 경우 유저 네임이랑 패스워드가 암호화되지만
• 이걸 가지고 로그인 하는 과정에서 config.json파일이 또 만들어짐

해결책

• 도커 업로드를 할때마다 로그인, 로그아웃 둘 다하면 파일의 접속 정보는 사라짐
• docker-credential-helpers를 통해 암호화를 하면 config.json 파일을 열어도 비밀번호를 알 수가 없음

---

문제

• 빌드를 계속 하다보면 CI/CD 서버에 컨테이너 이미지들이 계속 쌓임

해결책

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}"   // 이미지 삭제

• 업로드를 한 후 이미지를 잘 삭제해주자!!!

 

---

 

 

📒 Helm에서 네임스페이스 관리

• Helm으로 앱을 배포할 때 앱 하나마다 네임스페이스를 만들지 않고
• 그룹 개념으로 네임스페이스를 만들게 될 때가 많음
• 네임스페이스는 배포와 별도로 관리를 해주는게 좋음
• Helm도 install 할때 네임스페이스가 없으면 생성하라는 기능이 있지만
• uninstall 할 때는 네임스페이스가 삭제되지는 않음
• Helm이 의도적으로 네임스페이스가 지워지면 다른 앱들도 삭제 될 수 있으니 이런 방식을 선택한 것

 

---

 

 

📕 Helm에서 자주 쓰는 부가 가능

배포 명령어 뒤에 '-wait' 옵션

stage('헬름 배포') {
  steps {
    withCredentials([file(credentialsId: 'k8s_master_config', variable: 'KUBECONFIG')]) {
      sh "helm upgrade api-tester-2224 ./2224/deploy/helm/api-tester -f ./2224/deploy/helm/api-tester/values-dev.yaml" +
         ...
         " --wait --timeout=10m" +  // 최대 10분으로 설정

• 파드가 실제 기동 중인지 while문으로 loop돌렸으나
• 파이프라인을 돌리다 보면 배포 명령을 실행한 후 파드가 실제 정상적으로 기동이 됐는지까지 확인
• 이후 정상적으로 기동이 됐으면 성공으로 프로세스를 종료하기를 원함
• 이 옵션을 사용하면 Helm이 알아서 체크를 하고 파드가 모두 정상적으로 통신이 되면 배포가 종료됐다는 결과를 보내줌

 

metadata.annotations

apiVersion: apps/v1
kind: Deployment
spec:
  template:
    metadata:      
      annotations:  
        rollme: {{ randAlphaNum 5 | quote }} // 항상 새 배포를 위해 랜덤값 적용

• 배포는 했는데 파드 업그레이드 진행이 안되는 상황
• k8s는 deployment 파일의 template 밑으로 변경이 있어야 업그레이드를 시작함
• 아무런 변경사항이 없다는 걸 인지하지 못하고 배포하면 업그레이드가 안됨
• annotations는 새 배포마다 랜덤 값을 생성해 줌
• 배포가 될 때마다 이 부분이 변하기 때문에 k8s가 변경사항이 있다고 감지하고 업그레이드 시작

 

---

 

 

⭐️ 이미지 태그

• 버전 명령 규칙상 v를 빼는게 맞다...
• latest는 넘버링에 상관없이 가장 마지막 배포 버전이라는 의미
• 태그를 안붙이면 자동으로 latest 이미지가 다운 받아짐

 

개발환경

• 개발환경에서는 잦은 배포를 하게 되고, 그로 인해 versioning 하는 것이 무의미
• latest로 태그를 달자
• pullPolicy : 파드에 사용되는 이미지를 어떻게 가져올지에 대한 부분
• -> Always라고 주면 항상 도커 허브에서 이미지를 가져옴
• template 밑으로 아무런 변경 사항이 없기에 배포를 해도 업그레이드가 되지 않음

 

검증/운영환경

• 검증환경이나 운영환경에서는 계획된 배포를 하기 때문에 versioning을 하는 것은 필수
• pullPolicy : ifNotPresent
• -> 노드에 해당 이미지가 있으면 그걸 먼저 사용하고 없으면 hub 확인
• 최초에 도커 허브에서 이미지를 가져와야 된다는 건 always랑 같음

그래도 ifNotPresent 쓰는 이유는??

• 운영 중에 파드가 스케일인이나 아웃이 돼서 늘어났다가 줄어든다...
• 그럴 때마다 이미 해당 노드에 이미지가 다운받아져 있는데 또 이미지를 받아오는 건 비효율적
• 또한 always 사용시 dockerhub에 연결이 안되는 상황이 발생하면 무조건 파드가 생성되지 않음
• ifNotPresent는 해당 노드에 이미지가 있으면 파드가 만들어질 수 있는 확률은 존재

 

실무에서는??

• 개발자들은 자신의 앱을 개발하고 소스빌드까지만 함
• 컨테이너 빌드랑 배포는 인프라 담당
• 어제 배포한 컨테이너 이미지를 롤백해달라는 요청이 들어옴
• -> 이런 상황에서 latest로만 태그를 달아서는 이런 요청에 대응하기가 어려움
• 따라서 개발환경에서도 배포시 마다 새 태그를 달아줌(날짜 등등)
• pullpolicy도 ifNotPresent로 변경
• 네임스페이스를 처음에 한 번 만들어 놓고 건들 일이 별로 없을 경우가 많음
• -> 초반에 kubectl로 네임스페이스를 만들고 스크립트에서 제외 시키거나
• -> 네임스페이스만 별도로 관리하는 배포 파이프라인을 만들어놔도 됨

 

제 3자의 시선에서 latest?

• 단순히 마지막 배포 버전을 원하는 것이 아님
• 최신 안정화 버전을 기대한다!!!
• 따라서 latest는 최신 안정화 버전이라는 의미로 두자

 

---

 

 

☠️ k8s 노드에 쌓인 이미지는??

// GC 속성 추가하기
[root@k8s-master ~]# vi /var/lib/kubelet/config.yaml
-----------------------------------
imageMinimumGCAge : 3m // 이미지 생성 후 해당 시간이 지나야 GC 대상이 됨 (Default : 2m)
imageGCHighThresholdPercent : 80 // Disk가 80% 위로 올라가면 GC 수행 (Default : 85)
imageGCLowThresholdPercent : 70 // Disk가 70% 밑으로 떨어지면 GC 수행 안함(Default : 80)
-----------------------------------

// kubelet 재시작
[root@k8s-master ~]# systemctl restart kubelet

• -> k8s가 사용하지 않는 이미지를 자동으로 삭제해줌
• Kubernetes Garbage Collector라고 함

 

 

---

출처

[인프런] 쿠버네티스 어나더 클래스 (지상편) - Sprint 1, 2

저자 : 일프로