쿠버네티스 ⑤ Namespace 와 Helm

 

 

 

 

이번에는 쿠버네티스의 네임스페이스와 Helm에 대해서 알아보자. 

 

 

 

참고한 영상 👇🏼

• https://www.youtube.com/watch?v=X48VuDVv0do

• https://www.youtube.com/watch?v=6n5obRKsCRQ&list=PLApuRlvrZKohaBHvXAOhUD-RxD0uQ3z0c

• 모든 내용은 윗 영상을 캡쳐 및 정리한 내용입니다! 🙌

 

 

 

 

 

 

 

Namespace

• 네임스페이스 안의 리소스들을 관리
• 클러스터 하나를 여러개의 논리적인 단위로 나눠서 사용
• 클러스터 안의 클러스터 또는 가상 클러스터, 기본 네임스페이스
• 기본 4개 네임스페이스 (쿠버네티스 대시보드는 오직 minikube와 사용됨)
  • kube-system
    • 시스템, 마스터, kubectl 프로세스를 관리
    • kube-system 안에서 생성하거나 수정하면 안됨
  • kube-public
    • 퍼블릭하게 접근 가능한 데이터
    • ex) 클러스터 정보를 포함하는 configMap
  • kube-node-lease
    • 노드의 중심
    • 각각의 노드는 네임스페이스의 lease 오브젝트와 연관되어있음
    • 노드의 가용성을 결정
  • default
    • 생성한 자원이 위치 하는 공간
• 네임스페이스 생성하기
  • $ kubectl create namespace [my-namespace]
    • configuration file을 바탕으로 네임스페이스 생성
• 네임스페이스 구성이 필요한 경우
  • 하나의 네임스페이스에 모든 구성이 들어있어 다름 구성과 구별하기 어려울 때 (용도 구별이 필요한 경우 )
    • 리소스를 그룹화하여 네임스페이스별로 구성함
      • ex) data base, monitoring, elastic stack, nginx-Ingress 등
    • 작은 프로젝트의 경우 구별하는 것이 불필요
  • 많은 팀이 존재하는 하나의 어플리케이션에서 config 충돌이 발생하여 첫번째 팀의 deployment를 오버라이딩 해버리는 경우
  • 리소스 쉐어링이 필요한 경우 1) staging과 development 사이
    • 두 환경의 구성을 재활용
  • 리소스 쉐어링이 필요한 경우 2) blue / green deployment
    • 분리된 클러스터가 필요가 없는 경우
      • ex) 어플리케이션의 버전만 다른 경우
  • 자원이나 접근의 제한이 필요한 네임스페이스의 경우
    • 각각의 팀은 고유의 분리된 환경을 가짐
    • limit : CPU, RAM, Storage per NS
• 네임스페이스 구성의 장점
  • 컴포넌트를 구성
  • 팀끼리의 충돌을 방지
  • 다른환경 끼리 자원(서비스)을 공유 가능
  • 네임스페이스 레벨에서 자원이나 접근을 제한 가능
• 특징
  • 다른 네임스페이스에서 대부분의 자원으로의 접근은 제한되어있음
  • 다른 네임스페이스에서 서비스에 접근 가능
  • 네임스페이스에서 생성될 수 없는 구성의 경우
    • 클러스터에서 전역으로 존재하여 고립시킬 수 없음

• 네임스페이스에서 component 생성하기
  • 네임스페이스가 정의되지 않은 경우
    • 기본적으로 components가 디폴트 네임스페이스에 생성됨
  • kubectl 커맨드로 configuration file 을 사용하는 경우
    • 문서화에 유리하며 더욱 편리
• 사용중인 네임스페이스의 이름 변경
  • kubens를 사용
    • brew install kubectx
    • kubens( list all the NSs)
    • kubens [my-namespace]

 

 

 

 

 

 

 

Helm

• 쿠버네티스를 위한 패키지 매니저

 

1) Helm Charts

• YAML 파일의 번들
• Helm을 이용하여 개인의 Helm Charts를 만들 수 있음
• Helm Repository로 pugh 하거나 이미 존재하는 것을 다운받을 수 있음
• 공유
  • $ helm search <keyword> 또는 Helm Hub 사용
  • public registries : Helm Hub
  • private registries : organisations에서 공유할 때

 

 

 

 

2) Templating Engine

• 클러스터가 MSA로 구성되어 있을 때, 각각의 YAML 파일을 생성하여 각각의 어플에 적용됨
• 1) 공통 적용 blueprint를 작성
• 2) 동적인 값은 placeholders에 의해 교체됨

• 3) YAML 파일이나 —set 플래그에 의해 정의된 값들이 object를 만들 때 사용됨
  • ⇒ 실용적인 CI / CD 가능

 

• 다른 환경에서 같은 애플리케이션을 실행할 때 도움이 됨 ( own chart)
  • ex) development, staging, production

 

 

• 템플릿 파일 안에 value 주입
  • $ helm install —values=my-values.yaml <chartname>
  • override 도 가능
  • $helm install —set version=2.0.0

 

 

 

 

3) Release Management

• Helm version 2 vs 3
  • version 2
    • Client (helm CLI)
      • $ helm install <chartname>
      • Tiller 에게 요청을 보냄
    • Server (Tiller)
      • 쿠버네티스 클러스터
      • 요청을 수행하고 생성되거나 변화된 deployment의 configuration을 저장
      • 모든 차트의 수행내역을 저장함
      • 이를 바탕으로 새로운 것을 만들지 않고 이미 존재하는 deployment에 반영함
      • 이를 통해 rollback이 가능해짐
      • 단점
        • Tiller가 쿠버네티스 클러스터 안에서 너무 많은 기능을 수행 (관여도 높음) CRUD 등등
        • 보안상 이슈 발생
  • version 3
    • Tiller 가 사라짐
    • 보안상 이슈 해결됨