블로그

최신순
인기순
좋아요순

[쿠어클#13] Helm과 Kustomize 비교하며 사용하기 (2/2)

Sprint2 추가 강의가 업로드 됐어요! Helm과 Kustomize 비교하며 사용하기 두 번째 시간입니다. 이번 시간에는 Kustomize 패키지 구조를 설명을 드릴 거예요.먼저 최초 패키지를 만드는 방법을 보면, Helm 패키지는 이렇게 helm create 명령을 날리면 이런 구조의 패키지가 자동으로 만들어졌는데, Kustomize는 직접 폴더를 만들어야 되고요. 그리고 이 폴더 밑에 이렇게 하위 폴더 구성도 직접 만들어야 되요.어려운 구조는 아니지만 그래도 사전에 Kustomize의 구성이 이렇다라는 건 미리 알고 있어야 되는 거죠. (물론 Kustomize 가이드에 잘 나와 있어요) 그리고 아래와 같이 각 폴더 밑에 내가 배포할 yaml 파일들도 만들어 줍니다.좀 수동으로 만들어야 할 부분이 많긴 한데, Helm은 알고 있어야 되는 파일들이 많았던 거 에 비해서 Kustomize는 파일 구조가 간단해 보이죠? 이 폴더 구조랑 이 kustomization 파일에 기능만 알면 다 예요.그래서 하나씩 보면, 메인 폴더가 있고 밑에 base는 Default 포맷이 될 yaml 파일들을 넣는 폴더입니다. 기존부터 kubectl로 배포하던 deployment yaml 파일을 그대로 여기에 넣으면, 이게 베이스 yaml 파일이 되는 거예요. 이런 식으로 밑에 배포할 파일들을 다 넣으면 되요.그리고 Kustomization.yaml이 제일 중요한 파일 입니다. 리소스 yaml 파일들 중에서 어떤 파일을 배포할 건지 선택하는 내용이 있고, 또 그 yaml 파일들에서 반복적으로 사용하는 속성들을 공통값을 설정할 수 있어요. 먼저 어떤 파일을 배포할 건지 선택하는 방법은helm의 경우, hpa.yaml 파일 내부에 이렇게 if문이 있고, values.yaml 파일에서 이렇게 false를 하면 이 hpa가 배포가 안됐고요. kustomize는 이 Kustomization 파일에 [resouce] 키가 있어서 내가 배포할 파일들만 명시적으로 정할 수 있어요.이게 배포할 파일을 선택하는데 있어서 두 패키지 매니저에 대한 차이 입니다.그리고 공통값 설정에 대한 차이는Helm은 Deployment 템플릿 내에 변수를 넣는 부분이 있고, 여러 파일들(_helpers.tpl, Chart.yaml, values.yaml)에서 변수를 주입하는 방식이 다양했었죠?반면 kustomize는 Deployment에는 특별한 내용이 없고, Kustomization.yaml 파일에 명시적으로 coommonLabels라는 키가 있어서 여기에 내용을 넣으면, 배포될 모든 yaml 파일에 label로 그 내용이 들어가 집니다.마지막으로 환경별로 배포할 때 기본값 들을 어떻게 주는지 말씀 드릴게요.kustomize는 overlays 폴더 밑에 환경별로 폴더를 만들고, 해당 폴더마다 그 환경에 맞는 yaml 파일들을 넣어 놓습니다.그리고 여기에도 마찬가지로 Kustomization.yaml 파일이 있는데, 하는 역할은 같아요.각 환경별 파일에 있는 yaml 파일들에 대해서 배포할 파일을 지정하고 공통값을 설정할 수가 있습니다. 그래서 개발 환경을 배포 하려면 [kubectl apply -k ./app/overlays/dev] 처럼, 배포 명령에 해당 환경별 폴더 경로를 주면 되고요. 반면 Helm의 경우, values.yaml 파일을 각각의 환경별로 추가하고, 배포할 때 -f 옵션으로 이 원하는 환경의 values-dev.yaml 파일을 선택하면 됩니다. 헬름은 변수를 가져다 쓰는 방법이 다양했는데, 또 한 가지가 더 늘었죠? 그래도 다 사용해야 되는 상황이 있고, 실습을 하면서 자세하게 설명을 드릴게요. 그럼 이번 블로그는 여기까지고요, 해당 강의에서는 실습과 더불어 추가적으로 아래 내용들에 대해서 더 다룹니다 😀[쿠버네티스 어나더 클래스] : https://inf.run/unreT 배포 파이프라인 구축 후 마주하게 되는 고민들ps. 매너가 좋아요♡를 만든다 :)

데브옵스 · 인프라･쿠버네티스･어나더클래스･지상편･Sprint2･일프로･데브옵스･Helm･Kustomize･Jenkins

[쿠어클#12] Helm과 Kustomize 비교하며 사용하기 (1/2)

Sprint2 추가 강의가 업로드 됐어요! 이번 강의는 Helm과 Kustomize 비교하며 사용하기라는 주제 입니다. 지금까지 kubectl을 잘 쓰고 있었는데, Helm이랑 Kustomize를 꼭 써야 되나요? 라고 질문을 하시는 분들께 저는 무조건 그래야 한다고 말씀을 드려요. 왜 그런지는 아래 그림을 보면서 말씀 드릴께요! 먼저 이렇게 배포툴(Jenkins, argo)이 있어요. 지금까지 젠킨스를 배포툴로 써왔는 데, 다음시간에는 argoCD를 배포툴로 쓸꺼고요. 그리고 이 배포툴에서 kubectl을 써서 쿠버네티스로 배포를 해왔었죠.이 kubectl은 단지 커맨드라인 도구인 CLI인 거고, 이 명령중에서 create나 apply 명령으로 쿠버네티스에 자원을 생성했었는데, 그건 그냥 CLI 명령중에 하나를 사용한거지, 배포를 위한 부가 기능은 없어요. 그리고 실무에서는 이 kubectl을 배포한 쿠버네티스 자원을 조회하거나 급한 수정을 해야 될 때 주로 쓰지, 정작 자원을 생성할 때는 잘 쓰지 않습니다. 실제 자원 생성은 주로 Helm이랑 Kustomize를 통해서 해요. kubectl이랑 같은 위치로 들어가고요. 얘네들을 패키지 매니저라고 부릅니다. 똑같은 구조처럼 보이지만 차이가 있는데요. 결국 kube-apiserver한테는 똑같이 6번에 API를 날려주지만, 작업자의 입장에서는 이 yaml 파일들을 명령어 한번으로 배포할 수 있게 해줘요. 어차피 App 하나를 구성하는데 여러 yaml 파일들이 사용되기 때문에, 이 yaml 파일들을 패키지 형태로 관리 할 수 있게 필요하기도 했거든요. 그런 니즈에 잘 마춰 졌고, 그렇기 때문에 이번 수업을 통해서 패키지 매니저인 Helm과 Kustomize에 대해서 잘 알고 있어야 합니다. Helm vs Kustomize 비교 - 최종 정리공통점을 말씀드리면, 바로 사용 목적입니다. 배포를 하기 위해 만들어야 되는 yaml 파일들에 대해서 중복관리하는 걸 최소화 하기 위한 거죠. 이전 시간에 한번 말씀드릴 적 있죠? 이젠 마이크로 서비스 아키텍처를 많이 쓰다 보니까, App을 잘게 쪼개게 되고, 그래서 App 종류가 많아졌어요. 그리고 기존부터 그랬던 부분인 다양한 환경에 배포를 해야되서 그렇고요.그리고 두 번째 공통점으로 이 두 패키지 매니저는 다양한 배포툴에서 지원을 합니다. 지원한다는 의미는 이 툴 에서 helm이나 Kustomize를 더 편하게 쓸 수 있도록 부가적인 기능들을 제공한다는 거죠.이제 다음으로 차이점인데, 지금부터 내용은 그냥 그렇구나 정도로만 알고 넘어가 주세요. 해보지 않은건 크게 와닿지가 않거든요. 이걸 외울 필요도 없고요. 그냥 이번 강의를 쭉 듣다보면 자연스럽게 알게되는 내용들이기도 해요. 먼저 배포 편의기능이 Helm은 200개 정도 되는 거에 비해 kustomize는 10개 정도 밖에 안됩니다. 딱 그렇다는게 아니라 상대적인 비교예요. 근데 “그래서 Helm이 더 좋아요”라고 말할려는 게 아니라, Kustomize는 심플 쓸 수 있다는 장점이 있는 거거든요. “지금 파이프라인을 구축하는데 많은 기능이 필요 없고 빨리 공부해서 구축을 해야 되” 라고 했을 때는 kustomize를 써야 되는 건 거죠. 그리고 다음으로 각각에 패키지 매니저를 이용해서 하나에 패키지를 만들어 었을 때, 그 패키지를 활용 할 수 있는 범위인데 (이건 제가 권고 사항이고요) Helm은 한 패키지를 만들어서 마이크로 서비스 목적이랑 이 다양한 환경으로 배포까지 하는데까지 사용 해도 좋아요. 패키지를 구성할 때 이 두 목적을 모두 챙기면서 만들 수 있다는 거고요.Kustomize는 OR이에요. 둘 중 한 목적만 선택해서 패키지를 구성하는게 좋습니다. 불가능 한건 아닌데, 활용 범위를 늘릴 수록 점점 패키지 내부에 파일량이 많아지는 구조라서 그래요. 그럼 또 이 파일들을 관리하는 게 복잡해지기 시작합니다. 다음으로 사용 목적입니다. Kustomize는 딱 내 프로젝트에 App을 패키지화 시켜서 배포하는 목적으로 쓰이고, Helm은 그거 받고, 기업용 제품을 패키지 하는데 쓰여요. 대부분에 오픈소스들은 여러가지 설치 방법들을 제공하잖아요? 그중에 하나로 꼭 들어가는 설치 방법이 Helm인 거죠. 보통 오픈소스를 설치하는 사람들이 각자 환경이 다르고, 설치하고 싶은 구성이 조금씩 다를 수가 있잖아요? Helm은 그런 상황에 따라서 각자, 자신의 환경에 따라 조절할 수 있도록 패키지를 만들 수 있습니다. 그래서 유즈케이스를 보면, Helm은 App이 5개 이상있고, 주로 대형 프로젝트를 할 때 많이 쓰고요. Kustomize는 App 종류가 5개 미만에 간단한 프로젝트를 할 때 쓴다고 볼 수가 있어요. Helm vs Kustomize 비교 - 설치 구성 kustomize를 보면, 자체적으로 kustomize를 관리하는 사이트가 있고, 다운을 받거나 Release를 관리 하는 Github도 있어요. 근데 이게 1.14버전부터는 Kubectl에 통합이 됐거든요. 그래서 현재 우리가 쿠버네티스 레파지토리에서 kubectl을 받아서 설치했는데, 현재 kubectl는 1.27버전 이기 때문에 kustomize가 포함이 돼있고 바로 사용할 수 있다고 보시면 됩니다.Helm도 마찬가지로 Helm 사이트가 있고, Github에서 Helm을 다운 받아서 설치 합니다. 그리고 kubectl이랑 마찬가지로 이렇게 인증서가 있어야지 kube-apiserver로 통신을 할 수 가 있는 거고요. 그래서 이렇게 설치되는 방식은 좀 다르지만, 구성은 결국 비슷하죠? 이렇게 패키지를 만들면 Helm은 helm으로 시작하는 명령어를 날려서 API가 보내지는 거고, Kustomize는 kubectl에 포함이 됐기 때문에 kubectl 명령에 -k가 kustomize를 쓴다는 옵션이예요.그래서 여기까지보면 둘 다 구성이 비슷해 보일 수는 있는데.. 여기서 Helm은 좀더 큰 생태계를 가지고 있어요. Artifact Hub라고 해서 Helm 패키지들을 저장하는 저장소가 있습니다.Github나 DockerHub 같은 곳이라고 보면 되는데, 이렇게 많은 오픈소스 기업들에서 자신들에 제품들을 Helm 패키지로 설치할 수 있도록 패키지들을 올려놓습니다.그래서 이중에서 설치하고 싶은 게 있으면, Helm 명령어로 필요한 패키지를 다운 받을 수 있는 거죠. 그래서 이렇게 패키지가 받아지고, 내 환경에 맞게 좀 수정해야 되는데, 그건 이걸 올려놓은 기업에서 설치 가이드도 자세히 제공하고 있고요. 그래서 이렇게 더 큰 생태계가 있으니까 그만큼 Helm에서 제공해줘야 하는 기능이 많을 수 밖에 없어 보이죠?그럼 이번 블로그는 여기까지고요, 해당 강의에서는 실습과 더불어 추가적으로 아래 내용들에 대해서 더 다룹니다 😀[쿠버네티스 어나더 클래스] : https://inf.run/unreT Helm vs Kustomize 비교 - 사용방식 [Helm 차트] 구조 상세 설명 [Helm 차트] 변수 사용ps. 매너가 좋아요♡를 만든다 :)

데브옵스 · 인프라･쿠버네티스･어나더클래스･지상편･Sprint2･일프로･데읍옵스･Helm･Kustomize･Jenkins

[워밍업클럽: 쿠버네티스] 미션 #6. ArgoCD - Github 업데이트

큐브옵스 카페의 실습 미션을 기반으로 작성한 내용이다.https://cafe.naver.com/kubeops/553 1. ArgoCD로 App 생성 및 배포1-1. App 생성 하기▶ GENERALApplication Name : api-tester-2232-build-push-git Project Name : default SYNC POLICY : Manual▶ SOURCE※ <Github-Useranme>은 본인의 Username으로 수정Repository URL : https://github.com/wnsrlf0721/kubernetes-anotherclass-sprint2.git Revision : main Path : 2232-build-push-git/deploy/helm/api-tester▶ DESTINATIONCluster URL : https://kubernetes.default.svc Namespace : anotherclass-223▶ HELM 확인 후 Values files 지정VALUES FILES : values-dev.yamlCreate 버튼으로 App 생성을 하면다음과 같은 ArgoCD App이 만들어지게 된다(Healthy 같이 초록창이 뜨지는 않음). 1-2. 자동 배포 설정api-tester-2232-build-push-git > details > SYNC POLICY 순서로 클릭을 해서 아래와 같이 만들자.1-3. 자동 배포 확인잠시 기다리면 Healthy 상태가 되며 파드가 생성될거고, 대시보드를 확인하면 anotherclass-223 ns에 파드가 생성된 걸 볼수 있다. 2. Jenkins에 Github Token 등록카페에 가면 Github에서 토큰을 생성하는 방법이 자세하게 나와있다. 가서 배우자.토큰을 받은 후에 젠킨스 설정에 토큰을 등록하게 되면,Jenkins관리 > Credentials에서 github_token을 확인할 수 있다. Jekninsfile 에서 Credential 사용 확인▶ 2232-build-push-git > JenkinsfileJenkinsfile을 보면, github_token으로 github USERNAME과 PASSWORD로 깃허브에 파일을 업데이트하는 동작을 수행한다. 3. Jeknins에서 Source/Container 빌드 후 Docker로 업로드 하기3-1.새보기 및 item 생성[새보기] 만들기 -> 조회명 : 223, Type : List View [item name] 만들기 -> item name :2232-build-push-git, [Pipeline] 선택 3-2. Configure▶ Configure > General > GitHub project > Project urlProject url : https://github.com/wnsrlf0721/kubernetes-anotherclass-sprint2/▶ Configure > Advanced Project Options > Pipeline > [저장]※ <Github-Useranme>은 본인의 Username으로 수정Definition : Pipeline script from SCM Definition > SCM : Git Definition > SCM > Repositories > Repository URL : https://github.com/<Github_Username>/kubernetes-anotherclass-sprint2.git Definition > SCM > Branches to build > Branch Specifier : */main Definition > SCM > Branches to build > Additional Behaviours > Sparse Checkout paths > Path : 2232-build-push-git Definition > Script Path : 2232-build-push-git/Jenkinsfile3-3.[저장] 후 [지금 빌드] 실행 (이때는 파라미터가 없어서 실행되지 않아요!)3-4.[파라미터와 함께 빌드] 선택 후 본인의 DockerHub와 Github의 Username 입력 후 [빌드] 실행3-5.Stage View결과 확인3-6. ArgoCD에서 자동 배포 확인새로운 이미지가 들어온 걸 인식해서 생성한 후,이미지가 교체된 모습을 볼 수 있다.3-7. 다시 빌드 후 재확인깃허브에도 변경내용이 잘 반영된걸 볼 수 있다.

데브옵스 · 인프라･k8s･Credentials･ArgoCD･Jenkins･Helm･Github･CI/CD

[워밍업클럽: 쿠버네티스] #13. Helm과 Kustomize 비교하기 (3주차)

Helm, Kustomize 내용정리 kubectl -> Helm, Kustomize 사용해보기쿠버네티스 배포를 위한 배포툴로 (jenkins, argoCD) 등을 사용한다.지금까지 배포 툴 위에서 kubectl로 쿠버네티스에 배포 명령(create, apply)을 해왔으나, CLI 명령으론 배포를 위한 부가적인 기능을 기대하기는 어렵다.실무에서는 자원 생성 간 대부분 헬름, 커스터마이즈를 이용해 생성하며, App을 빠르게 조회하거나, 급한 수정이 있을 경우에만 kubectl을 활용한다.헬름과 커스터마이즈는 배포툴에서 동작하는 패키지 매니저 이며, kubectl과는 다르게 앱을 구성하는 yaml 파일들을 패키지 단위로 관리를 한다. 이는 kubectl처럼 여러 yaml 파일을 apply 해줄 필요 없이 한꺼번에 패키지로 처리해주는 것이다. Helm vs Kustomize 비교 정리공통 부분사용하는 목적이 동일하다. 배포를 위한 여러 yaml 파일들을 중복 관리하는 걸 최소화한다. App 종류가 많아지면(MSA 방식 채택 시) 다양한 yaml파일들을 관리해야 하는 불편함이 생기고, 이때 패키지 단위로 yaml을 관리하게 되면 중복으로 yaml파일들을 관리할 필요가 없어진다. 다양한 배포 툴(argoCD, github actions 등)에서 헬름과 커스터마이즈를 지원해준다.차이점배포 편의기능 수 Helm : 200개 ↔ Kustomize : 10개패키지 하나 당 사용하는 활용 범위(권고사항) Helm : MSA 이용하는 경우 And 다양한 배포 환경 (두 목적 모두 가능) Kustomize : MSA 이용 경우 OR 다양한 배포 환경 (둘 중 하나만) →커스터마이즈는 활용 범위가 늘어날 수록 패키지 내부 파일량이 많아지는 구조 (파일관리 복잡해질 수 있음)사용 목적 Helm: 프로젝트관리 패키지용 + 기업 제품 패키지용 Kustomize: 프로젝트관리 패키지용유즈케이스 Helm : 대형 프로젝트에 사용 (App 종류 5개 이상) <-> Kustomize: 간단한 프로젝트에 사용 (5개 미만)Helm은 깃허브에서 다운 받아 설치해서, helm이 동작할 폴더를 생성하는 helm command를 사용해 세팅한다(helm create). Artifact HUB라는 Helm 패키지 저장소를 이용한다(Docker Hub느낌). Kustomize는 kubectl에 포함되어있어서 kubectl -k 명령어로 바로 사용할 수 있다(따로 설치 x).사용 방식 Helm : 템플릿 및 변수주입 방식template 폴더 안에 많은 yaml 파일들이 들어있는 구조이다. helm command로 변수를 주입하는 경우, helm install api-tester-32222 ./app -set port=’80’ -set profile=’dev’ -set nodeport=’32222’ 이렇게 파라미터 값을 주게되면, yaml 파일에 해당되는 파라미터 값을 채워준다.command를 쓰지 않고 파일에 변수 값을 주는 경우, values.yaml, Chart.yaml 등의 파일에 해당 값에 맞는 파라미터를 주입하는 방식을 많이 사용한다.Kustomize : 오버레이 방식 base 폴더 안에 파라미터 값이 없는 yaml 파일이 주어지고, kubectl apply -k ./app/overlays/dev 명령어를 주게 되면, 해당 명령어 뒤에 표시한 파일을 베이스 파일에 덮어쓴다. 즉, 기본 base에 있는 값은 그대로 반영을 하되, 같은 내용이 있는 파일을 덮어 쓸 경우 오버레이한 값으로 수정하고, 내용이 없는 경우 base에 추가를 한다(덮어쓰기). Helm 폴더 살펴보기helm create api-tester 명령어로 api-tester폴더 생성하면 아래와 같이 자동으로 패키지들이 만들어짐Helm 공식문서에 나온 helm create 명령어.생성한 폴더 아래에 yaml파일, ignore파일, charts와 templates 폴더가 생성된다..helmignorehelm은 폴더에 있는 내용 전체를 가지고 배포 yaml 파일을 만들게 되는데, 이때 ignore 파일에 배포하고 싶지 않은 파일목록을 추가해 헬름 차트에서 배포할 파일을 제외할 수 있다. 즉, 배포안할 yaml 파일을 여기에 선언하면됨이런식으로 gitignore같이 파일에 적어두면 여기에 적힌 파일은 배포간에 제외된다.Chart.yaml차트 자체의 기본정보를 선언하는 파일이다. 파일 내에 차트 이름, 버전, App 버전(image) 등이 선언된다.values.yaml배포할 yaml 파일에 들어가는 변수들의 기본값 선언하는 파일이다.templates 폴더 및 하위 파일쿠버네티스에서 필요한 각 yaml들이 여기에 담긴다. tests 폴더 : 메인 App이 배포된 후에 통신이 되는지 체크하는 용도(이번 강의에선 삭제)_helpers.tpl : 사용자 전역변수를 선언하는 파일, 이전에 valus.yaml에서 변수들의 기본값을 선언했지만, 추가로 변수 값들을 가공해 임의의 전역 값을 만들 수 있다.NOTES.txt : 배포 후 안내문구이외의 yaml파일 : 배포때 사용되는 yaml파일들 Kustomize 폴더 살펴보기helm과는 다르게 커스터마이즈는 폴더를 직접 만들어야한다. 심지어 하위 폴더 구성까지도..base 폴더 디폴트로 포맷이 될 yaml파일들을 넣는 폴더이다(helm에서 templates와 유사).kustomization 파일: 이 파일을 통해 우리가 배포할 파일들을 선택하고(helm에서 ignore와 유사), yaml파일에서 공통값(파라미터)를 설정한다(helm에서 values와 유사). 즉, helm에서 ignore와 values의 역할을 모두 맡은 파일이다.역할 : resources 배포 파일 선택 해당 영역에서 내가 배포할 파일을 명시한다. (헬름에서는 values.yaml에서 각 배포파일의 파라미터로 false를 설정해 배포하지 못하게 했음) 역할 : commonLabels 공통값 설정해당 파일에서 commonLabels 요소에 넣고싶은 값들을 넣으면, 모든 yaml 파일에 해당 내용이 labels로 들어간다. (헬름에서는 Deployment 템플릿에 변수를 설정하고, 특정 파일들마다 변수를 주입하는 방식이 다양했음)overlays 폴더오버레이를 할 영역에 대한 상위 폴더이고,(dev,qa,prod 등) 해당 폴더마다 각 환경에 맞게 오버레이할 파일을 넣어야한다.개발 환경을 배포하는경우 kubectl apply -k ./app/overlays/dev 이런 식으로 배포 명령을 준다.반면 Helm의 경우,values.yaml 파일을 환경별로 values-dev / values-qa / values-prod .yaml 이렇게 구분하고, 배포 명령을 할 때 -f 옵션을 추가해서helm install api-tester-32222 ./app -f ./app/values-dev.yaml 이렇게 선택한다.배포 파이프라인 구축 후 생기는 고민들 인증서 보안배포에 필요한 쿠버네티스 인증서, config.json(Docker로그인 정보) 가 서버에 노출되고,이 파일들은 암호화되지 않은 파일이다.config.json은 base64로, 디코딩하면 정보를 알 수 있는 파일이며,쿠버네티스 인증서 (kubeconfig)도 파일 자체로 관리자 권한 인증서라 관리자 권한으로 쿠버네티스 클러스터에 API를 호출할 수 있게 된다.그래서 우리는 이 중요 데이터들을 타인이 활용하지 못하도록 암호화하는 과정이 필요하다.Jenkins의 Credential을 이용하면 암호화할 수 있고, 추가로 도커 config.json은 도커에 로그인 할때마다 추가로 config 파일이 새로 만들어지기 떄문에, 배포시마다 도커허브로 업로드할 때 로그인한 이후에 종료시점에는 항상 로그아웃을 해야한다.(로그아웃 시 접속정보 삭제됨) 물론 Docker-credential-helpers 를 이용하게되면 파일을 열어도 비밀번호가 노출이 안되는 기능을 제공한다. 컨테이너 이미지 제거CICD 서버에서 컨테이너 빌드를 계속 하다보면 이미지들이 쌓이게 되고, 디스크 용량이 다 차게 되면 jenkins가 죽게된다.컨테이너 업로드가 완료되면 서버에 만들어진 이미지는 삭제해야한다.Helm으로 앱을 배포할 때 앱 하나마다 네임스페이스를 만들지 않고,네임스페이스를 미리 만들어두고, 여러 앱들을 한 네임스페이스 안에서 그룹으로 생성될 수 있다.네임스페이스는 배포와 별도로 관리하는 것이 좋다.인스톨 할때는 네임스페이스를 자동으로 만들어주는 기능이 있지만, 언인스톨 할 때는 네임스페이스를 자동삭제해주지 않음(여러 앱들이 한 네임스페이스에 있을 경우 다른 앱들도 같이 삭제될수 있어서) Helm 부가기능 (wait)배포 명령 실행 이후 wait 옵션을 주면 파드가 정상기동이 되는 지 확인을 해주고, 정상적으로 파드와 통신이 되면 배포 종료라는 결과를 보내준다.Helm 부가기능 (Annotations)배포를 했지만 파드가 업그레이드 되지 않는 경우가 있다.위 경우는 Deployment파일에서 templates 스크립트 밑으로 내용의 변경이 있어야 업그레이드가 진행된다.이를 위해 metadata.annotations를 제공해 새 배포마다 랜덤값을 생성해 항상 업그레이드 되도록 한다. Tag (image에 붙이는 버전)Tag는 배포 환경마다 tag를 붙이는 성질이 달라진다.개발 환경에서는 잦은 배포로 versioning이 무의미해 지게 되고, 이 때 tag는 항상 latest로(최신버전의 App), pullPolicy: Always로 한다.Always는 이미지가 없을 때 항상 도커허브에서 이미지를 가져오는 방식이다.HUb가 미연동되어있는 경우, Pod 생성에 에러가 생긴다.Test(검증)나 Prop(운영)환경의 경우는 계획된 배포를 하며, versioning이 필수가 된다.이때 tag는 버전의 유의를 하게되고(항상 latest x), pullPolicy: IfNotPresent를 사용한다.IfNotPresent는 노드에 해당 이미지가 있는 경우 그것을 사용하고, 없을 때 도커허브에서 가져오는 방식이다.운영환경에서는 파드가 scale-out, scale-in 되는 경우가 자주 발생할 상황이 많고, 그럴 떄마다 이미지를 허브에서 가져오게 되면 비효율적이고, 허브에 연결되어있지 않은 경우 파드가 만들어지지 못하게 된다.프로젝트 규모가 커지게 되면, 개발 환경의 버전별로 롤백을 해서 다시 개발을 하는 상황도 생겨서, 빌드한 소스코드의 날짜를 기반으로 tag를 만드는 것이 좋고,latest 버전은 항상 새로운 버전마다 latest를 붙이는 것보단, 운영환경에서 안정적으로 쓰였던 가장 최신의 버전을 latest로 tag해 latest를 최신 안정화 버전으로 사용하는 것이 낫다.

데브옵스 · 인프라･k8s･Helm･Kustomize･pipeline･CI/CD