[Kubernetes & Docker] 4-2. API 리소스

도커 로고

1. 쿠버네티스 기초

쿠버네티스는 쿠버네티스 마스터와 쿠버네티스 노드로 구성되어 있다.

(젠킨스도 마스터와 슬레이브 구조로 구성할 수 있는데.. 갑자기 생각이 난다.)

• 쿠버네티스 마스터
  
  • API 엔드포인트 제공, 컨테이너 스케줄링, 컨테이너 스케일링 등을 담당한다.
• 쿠버네티스 노드
  • 도커 호스트에 해당하며, 실제로 컨테이너를 기동시킨다.

 

쿠버네티스 컴포넌트 구성

 

2. 쿠버네티스와 리소스

쿠버네티스를 관리하기 위해 등록하는 '리소스'는 컨테이너의 실행과 로드 밸런서 생성 등 많은 종류가 있다.

 

종류	개요
워크로드 API 카테고리	컨테이너 실행에 관련된 리소스
서비스 API 카테고리	컨테이너를 외부에 공개하는 엔드포인트를 제공하는 리소스
컨피그 & 스토리지 API 카테고리	설정/기밀 정보/영구 볼륨 등에 관련된 리소스
클러스터 API 카테고리	보안이나 쿼터 등에 관련된 리소스
메타데이터 API 카테고리	클러스터 내부의 다른 리소스를 관리하기 위한 소스

 

여기서 개발자가 주로 사용하는 리소스 카테고리는 워크로드 / 서비스 / Config & Storage, 세 종류 라고 한다.

 

2.1 워크로드 API 카테고리

클러스터 위에서 컨테이너를 기동하기 위해 사용되는 리소스

• 파드 (Pod)
• 레플리케이션 컨트롤러 (ReplicationController)
• 레플리카셋 (ReplicaSet)
• 디플로이먼트 (Deployment)
• 데몬셋 (DaemonSet)
• 스테이트풀셋 (StatefulSet)
• 잡 (Job)
• 크론잡 (CronJob)

 

2.2 서비스 API 카테고리

컨테이너 서비스 디스커버리와 클러스터 외부에서도 접속이 가능한 엔드포인트 등을 제공하는 리소스

사용자가 직접 관리할 수 있고, 서비스와 인그레스(Ingress) 라는 두 종류의 서비스 API 카테고리가 있다.

• 서비스
  • Cluster IP
  • External IP (Cluster IP의 한 종류)
  • NodePort
  • LoadBalancer
  • Headless(None)
  • ExternalName
  • None-Selector
• 인그레스(Ingress)

 

2.3 ConfigMap & 스토리지 API 카테고리

시크릿과 ConfigMap설정 맵은 모두 키-밸류 형태의 데이터 구조로 되어있고, 데이터가 기밀인지 설정 정보인지 구분된다.

영구 볼륨을 제공하는 리소스이고, 컨테이너에서 영구 볼륨을 요청할 때 사용한다.

• Secret
• ConfigMap
• 영구 볼륨 클레임 (PersistentVolumeClaim) 

 

2.4 클러스터 API 카테고리

보안 관련 설정, 정책, 관리성을 향상시키는 기능을 위한 리소스

• 노드 (Node)
• 네임스페이스 (Namespace)
• 영구 볼륨 (PersistentVolume)
• 리소스 쿼터 (ResourceQuota)
• 서비스 어카운트 (ServiceAccount)
• 롤 (LOL Role)
• 클러스터 롤 (ClusterRole)
• 롤바인딩 (RoleBinding)
• 클러스터롤바인딩 (ClusterRoleBinding)
• 네트워크 정책 (NetworkPolicy)

 

2.5 메타데이터 API 카테고리

다른 리소스 동작을 제어하기 위한 리소스이다. 예를 들어, 파드를 오토 스케일링 시키기 위해 사용하는 HorizontalPodAutoscaler (HPA)는 디플로이트 리소스를 조작해 레플리카 수를 변경함으로써 오토 스케일링을 구현한다.

• LimitRange
• HorizontalPodAutoscaler (HPA)
• PodDistruptionBudget (PDB)
• 커스텀 리소스 데피니션 (CustomResourceDefinition)

 

3. 네임스페이스로 가상적인 클러스터 분리

쿠버네티스에는 네임스페이스(NameSpace) 라 불리는 가상적인 쿠버네티스 클러스터 분리 기능이 있다.

하나의 쿠버네티스 클러스터를 여러팀에서 사용하거나 서비스 환경/스테이징환경/개발환경 으로 구분하는 경우 사용할 수 있다.

 

(Multi Tenancy Architecture 를 구현하게 도와주는 기능이라고 생각하면 될 것 같다.)

 

기본 설정에서는 다음 네 가지 네임스페이스가 생성된다.

• kube-system
  • 쿠버네티스 클러스터 구성 요소(대시보드 같은)와 애드온이 배포될 네임스페이스
• kube-public
  • 모든 사용자가 사용할 수 있는 설정값 (ConfigMap) 등을 배치하는 네임스페이스
• kube-node-lease
  • 노드 하트비트(?) 정보가 저장된 네임스페이스
• default
  • 기본 네임스페이스
  • 임의의 리소스를 등록하는 데 사용할 수 있다.

 

쿠버네티스 클러스터는 RBAC (Role-Based Access Control) 가 기본값으로 활성화되어 있다. 클러스터 조작에 대한 권한을 네임스페이스 별로 구분할 수 있고, 네트워크 정책과 사용하여 네임스페이스 간의 통신을 제어할 수 있는 구조다.

 

이런식으로 접근 권한을 부여한다.

 

하지만 저자는 여러개의 쿠버네티스 클러스터 단위 로 나눠야 한다고 주장하고 있는데, 이유는 다음과 같다.

• 쿠버네티스 클러스터 업그레이드 시 동시에 모든 환경에서 장애가 발생한다면?
• 네임스페이스 명명 규칙에 대한 재사용성이 떨어짐.
• 서비스 이름 해석 시 SERVICE.prd-ns1.svc.cluster.local 등의 다른 목적지에 통신을 해야한다.
  • 이건 무슨 말인지 이해 못했는데 추후 알게 되리라 믿는다.

저자는 네임스페이스가 아닌 클러스터로 나누는 것을 주장하고 있지만, 그렇게 되면 아키텍처와 DB 통신에 대한 고민을 같이 해 볼 필요가 있어 보인다.

 

4. kubectl

쿠버네티스 클러스터 조작은 쿠버네티스 마스터의 API 를 통해 이루어 진다.

직접 API 에 요청을 보내거나 클라이언트 라이브러리를 사용하여 클러스터를 조작할 수 있지만, 수동으로 조작하는 경우엔 kubectl 을 사용한다.

 

다음 시간엔 kubectl 부터 계속...

 

후기

• 대략적인 쿠버네티스의 구조를 알게 되었다.
• Role 을 관리하는 부분이 마치 AWS 의 IAM 을 보는 것 같았다.
  • AWS 에서 쿠버네티스로 서비스를 전환하는 것도 가능할지도?
• 전반적으로 책을 훑어보았더니 생각보다 심화적인 내용이 많아 공식 홈페이지의 쿠버네티스 매뉴얼을 먼저 볼까하는 생각이 든다.. 🤔