[쿠버네티스] - rolling update & helm

0. 삭제 명령

• kubectl delete 객체종류 객체 ID
• 모든 객체 삭제 : kubectl delete all --all
  • --all 대신에 -n namepsace (label)  설정 가능
• pod 의 경우는 종료되었지만 삭제가 되지 안흔 경우 존재 -> 강제 삭제 이용
  • kubectl delete pods podID --grace-period 0 --force

1. 업데이트

1) 전략

• 롤링 업데이트
  • 정해진 비율만큼의 파드만 점진적으로 배포해나가는 방식
  • 최대로 생성할 수 있는 파드의 개수와 최대로 삭제할 수 있는 pod 의 개수를 옵션으로 설정해서 업데이트
• 블루/그린 업데이트
  • 버전을 구성해서 이전 번전과 새로운 버전에 해당하는 pod 를 전부 생성해두고 트래픽을 새로운 버전으로 전달하는 방식
• 카나리 업데이트
  • 새로운 버전의 일부만 배포해두고 트래픽도 일부만 새로운 버전으로 전달
  • 배포에 문제 없으면 점진적으로 새로운 버전 배포 or  트래픽 전환하는 방식

2) 쿠버네티스의 롤링 업데이트

• 디플로이먼트의 정의를 수정해서 배포를 하게되면 롤링 업데이트를 수행
  • 레플리카의 수만 조정하는 경우에는 업데이트가 발생하지 않음 
  • rollout: 배포를 변경하는 것
• 이미지를 변경 or 다른 설정을 변경 해서 배포를 하면 kubenetes 는 새로운 버전의 pod를 만듦
  • 새로운 버전의 pod 가 replica 개수만큼 생성이 되어 이전 버전의 replica 를 0으로 만들어서 업데이트 완료
• replicat 의 개수를 늘린 경우
  
  • 프롬프트를 ch09 로 이동
  • vweb 디렉터리에 있는 deployment 와 service 를 배포 
  • vweb/update/vweb-v1-scale.yaml 파일을 이용해서 deploy 를 재배포 
    해당 경우 replicas 만 수정함
    • 해당 경우 pod 확인 -> 기존의 pod 가 존재 + pod 의 개수를 늘리거나 줄이는 방식
    • rollout 된 상황은 아님
  • 변경된 내역 확인
    • 수정 진행 -> 실제 변경된 사항이 없어 배포에 사용한 것만 등록
  • 이미지를 변경해서 배포 진행
    • 기존의 3개의 pod 가 모두 중지되고 새로운 pod 2개가 생성
    • 변경된 내역 확인 : REVISION 이 새로 추가됨

3) 롤아웃과 롤백

• 이미지의 태그를 변경해서 업데이트 수행 가능 -> replicas 를 제외한 pod 의 내용을 변경해서 업데이트를 하는 것이 가능
  • label 이나 container 의 이미지 부분은 제외한 부분을 변경하는 것은 다른 객체와의 연관성 문제 떄문에 함부로 하는것은 위험
  • 컨테이너에 영향을 주지 않고 내용을 변경할 수 있는 항목으로 version이 있음
• 버전만 변경해서 deployment 를 변경
  • 배포
  • kubectl apply -f vweb/update/vweb-v11.yaml
  • 버전을 변경 -> pod 의 정의가 수정 -> 변경이 발생하면 하위 객체가 수정됨
  • deploymeny 의 경우 하위에 있는 replicaset 이 수정 -> 이전 replicaset 은 삭제되는 것이 아님 
  • pod 의 개수가 0으로 수정 -> 기존의 pod 들은 terminated 됨
• 환경에 관련된 내용은 별도의 파일에 만들어 두고 사용하는 ConfigMap 의 경우 해당 내용의 변경은 rollout 이 아님
  • 변수의 값이 바뀌는 것은 Pod 의 설정 내용을 바꾸는 것이 아니기 때문
• 기존의 vweb 이라는 deploy 를 삭제

4) 롤링 업데이트 설정

• Depoyment 는 2가지 업데이트 전략을 제공하는데 하나는 Rolling Update / Recreate
• Rollling update :: 새로운 pod 를 만들어서 성공하면 이전 버전을 제거해나가는 방식
  • 업데이트해야하는 pod 의 내요잉 많을 때 업데이트하는데 시간이 오래 걸림
  • 새로운 파드를 만들고 제거해 나가므로 새로운 파드에 문제가 발생하면 이전 파드로 서비스 가능
  • 스케일링 속도를 위한 옵션

• maxUnavailable
  • 업데이트하는 동안 사용할 수 없는 pod의 개수
  • 기존 replicaSet 에서 동시에 종료되는 pod 의 개수
  • 정수로 설정해도 되고 백분율로 설정해도 됨
• maxSurge 
  • 업데이트할 때 만들어지는 새로운 버전의 최대 개수
  • 해당 설정 후 업데이트 -> 기존 개수 + maxSurge 만큼 증가 -> 기존의 파드 제거
  • 적절히 이용 -> 생성 후 삭제, 삭제 후 생성, 동시 생성 및 삭제등의 기능

---

• 업데이트 예시
  • replicat: 3
  • maxSurge 를 1로 설정하고 maxUnavailable 으로 설정하는 것이 default 값 
  • 3+1 의 상태를 만들고 새로운 버전이 정상적으로 동작을 하면 하나를 제거해 나가는 방식
  • maxSurge 를 0 으로 maxUnavailable 를1로 하면 1개가 제거 -> 1개 생성
  • maxSurge 를 1로 하고 maxUnavailable 를 1로 설정하면 1개가 제거 -> 2개 생성
• 업데이트 속도 조절 옵션 : pod 가 생성이 되고 일정 시간이 지난 후에 교체하기 위함
  • minReadySeconds
    • 신규 pod 의 상태가 안정적인지 확인할 수 있는 시간 여유를 두는 옵션 -> 기본값이 0
  • progressDeadlineSeconds
    • 해당 시간동안 pod 가 만들어지지 않으면 생성 실패로 간주하는 것 -> 기본값은 600
• Deployment 를 만들때 minReadySeconds 는 반드시 설정하라고 권장함

• Recreate 전략 :: 기존의 파드를 제거하고 새로운 pod 로 교체하는 방식 
  • 기존 Delpoyment 의 replicas 를 0으로 먼저 설정하고 pod 를 생성해나가는 방식
  • 새로운 버전에 문제가 발생하면 서비스 중단
  • 빠르게 업데이트 가능
  • 간단한 애플리케이션이고 테스트가 충분히 이루어진 경우 사용
  • spect.strategy.type 속성에 Recreate 사용

5) DaemonSet 과 StatefulSet 의 업데이트 전략

• 종류
  • Rolling Update: 기존의 Deployment 와 동일, 업데이트가 바로 수행
  • OnDelete: 삭제하면 업데이트가 수행되는 것, 사용자가 원하는 시점에 업데이트가 수행

 

2. Helm

1) 개요

• kubenetes 는 pod 를 생성하는 Deployment, ReplicaSet, Pod, StatefulSet, DaemonSet, Job. CronJob 만으로 구성할 수 있음
• Service 나 ConfigMap, Secret, Claim 등과 함께 구성되는 경우가 많음
• 여러개의 객체를 별도로 괸리하면 어려움
• 다양한 리소스를 각각 관리하지 않고 하나의 패키지로 관리하는 도구가 Helm
• 리눅스에서 yum, apt 나 Python 의 pip 등과 유사한 개념
• 많은 프레임워크 개발 업체들이 Kubenetes 환경에서 helm 을 사용해 애플리케이션을 설치하도록 helm 파일을 제공

2) Helm 의 주요 구성 요소

• Helm chart
  • 애플리케이션 설치에 사용되는 네트워크, 스토리지, 보안과 관련된 여러 kubenetes 리소스를 묶어놓은 패키지
  • 애플리케이션을 설치 시 -> kubenetes 에 하나의 디렉터리에 관련 파일을 묶어놓음 -> helm chart 를 이용해 한번에 설치 완료
  • 디렉터리 구성

• chart.yml : 차트에 대한 정보가 담긴 파일
• LICENSE: 라이선스 정보가 담긴 텍스트 파일
• README.md: 설명
• vlaues.yaml : 차트의 기본 템플릿 변수 파일
• charts/: 차트에 종속된 차트들을 포함하는 디렉터리
• crds/: 커스텀 자원
• templates/: 유효한 kubenetes 매니페스트 파일
• templates/NOTES.txt: 차트 사용법

• helm repository
  • helm chart 를 저장하고 있는 장소
  • 솔루션 업체들이 직접 html repository 를 제공 -> 없는 경우 ArtifactHib 에서 찾을 수 있음
  • 여러 원격 repository 를 등록해서 사용하는 것이 가능
• helm template
  • 별도의 파일에 값을 저장하고 다른 파일에서 사용하는 기능
  • values.yaml 파일에 키와 값 형태로 데이터 저장 후 다른 파일에서 가져다가 사용

3) helm chart 를 이용한 nginx 웹 서버 설치

• 과정
  1. 애플리케이션 설치에 사용되는 helm repository 를 등록
  2. helm chart 다운로드
  3. 애플리케이션 설치
  4. 필요한 경우 재배포
  5. helm chart 삭제

4) helm 설치

•  다운로드
  • 스크립트 파일을 다운로드 받아서 bash 로 바로 명령문을 수행해서 /usr/local/bin/helm 에 설치
  • 삭제를 하고자 하면 설치된 디렉터리의 파일을 삭제

curl https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 | bash
# 버전 확인
helm version

5) 주요 명령어

• helm repo add 
  • 애플리케이션 설치에 사용되는 helm repository 를 로커 환경에 추가 
• helm pull
  • helm char 파일을 로커 호스트로 내려 받음
• cp 파일경로 파일경로 
  • 앞에 해당하는 파일을 뒤의 경로로 복사
• helm install {helm 이름} -f 환경설정파일
• helm ls
  • 설치된 helm char 목록을 출력
• helm get manifest
  • 현재 실행 중인 helm chart 의 전체 YAML 파일 목록 및 설정을 확인
• helm upgrade 
  • 재배포
• helm delete
  • helm chart 삭제

6) nginx 설치

1. repository 등록
2. 로컬 repository 의 캐시를 업데이트
3. nginx helm chart 검색
4. nginx helm chart 다운로드
5. 압축된 파일이 다운로드 되었으므로 압축을 해제
6. 원본 파일 삭제
7. 버전 관리를 하고자 하는 경우 디렉터리 이름을 수정
8. 압축을 해제한 디렉터리
   1. templates 디렉터리에 kubenetes 관련 파일이 만들어지고 values.yaml 파일에 환경변수를 기재 -> 해당 파일의 내용을 변경해서 배포
9. 압축을 해제한 디렉터리에서 실행
10. 만들어진 helm 삭제
11. 설정을 변경해서 설치
    1. values.yaml 파일을 복사
    2. my-values.yaml 에서 replicaCount 를 3으로 수정
    3. 압축을 해제한 디렉터리에서 실행

7) kiamol.net repository 의 kiamo/vweb 을 설치

1. repository 등록
2. repository 업데이트 (로컬 repository 캐시 업데이트)
3. vweb helm chart 검색
4. 환경 변수를 values.yaml 파일에 기록해두기도 하지만 기본값을 변경해서 설치
5. 기본값 확인
6. 기본값을 수정해서 배포
7. 만들어진 deployment 와 replicaset 을 확인
8. 기존의 helm 을 업데이트할 때는 helm upgrade 명령을 수행
9. helm 을 사용하는 경우 replicas 만 변경해도 reivision 이 만들어짐

8) 로컬 helm chart 실행

1. install 은 로컬과 repository 모두 설치가 가능 -> lint 는 로컬에 있는 것만 검증 가능
2. 로컬에 있는 web-ping 디렉터리가 helm chart 가 될 수 있는지 확인
3. 설치는 동일함

9) repository 생성

• 원격 repository 

• Google Cloud Storage
• Git Hub Page
• Harbor OCI
• 일반 웹 서버 : yaml 파일과 tgz 파일만 서빙할 수 이싿면 가능
• ChartMuseum 서버 
• AWS 의 S3

• 로컬 repository 
  • ChartMuseum 이용해서 구현
• Public IP 가 있다면 원격 repository 로 사용 가능 -> public ip 가 없으면 로컬 repository 가 됨
  • helm 을 이용하기 위해서 저장소 추가
  • 업데이트
  • 저장소를 만들수 있는 ChartMuseum 을 설치
  • URL 확인
  • 등록
  • 업로드 - 패키징

10) 의존성 설정

• docker-compose 를 사용하는 이유
  • 여러 개의 컨테이너가 의존 관계 형태로 묶여 있는 경우에 순차적으로 컨테이너 생성
  • 직접 컨테이너를 생성 시 실수 발생 가능 및 자동화 불가능
• helm 도 의존성 있는 chart 를 하위로 설정을 해서 하위 chart 가 전부 실행이 되면 상위 chart 를 생성하도록 설정 가능
• chart.yaml 파일에 dependencies 라는 속성을 이용해서 기재

11)  helm 의 업그레이드와 롤백

helm 은 쿠버네티스와 상관없이 업그레이드와 롤백이 가능함

12)  helm 을 사용해야 하는 경우 

• 마이크로 서비스의 개수가 많이 늘어나면 배포와 관련된 별도의 팀을 두는 것이 일반적
• 마이크로 서비스를 개발하는 팀이 직접 배포를 수행하는 경우 해당 서비스와 연관된 서비스가 있으면 배포에 혼란이 올 수 있음
  • 같이 수정해서 배포해야하는 경우 순서대로 배포하지 않으면 에러가 발생할 수도 있음
  • helm 을 도입하면 여러 개의 YAML 파일을 하나로 합쳐서 적은 수의 YAML 파일로 배포 가능
• 여러 개의 쿠버네티스 pod 를 배포하다보면 동일한 설정 값을 사용하는 경우가 있음 
• helm 을 이용하면 하나의 values.yaml 파일에 만들고 이를 재사용할 수 있음