API 리소스와 kubectl

이 책을 읽기 위한 준비

• 쿠버네티스 환경: Google Kubernetes Engine(GKE), 일부 kind(Kubernetes in Docker)를 사용

• 쿠버네티스 버전: 1.18.16-gke.2100(kind의 경우: 1.18.15)

• kubectl 버전: v1.18.16

kubectl 설치와 자동 완성 기능 설정

• kubectl 설치

• 약간의 설정

쿠버네티스(GKE) 클러스터 생성

• 구축하는 부분이라 따로 또 실습을 해야된다.

쿠버네티스 기초

쿠버네티스의 기본 구조

• 쿠버네티스 마스터: 전체를 관리하는 '두뇌' 역할

• API 엔드포인트 제공

• 컨테이너 스케줄링

• 쿠버네티스 노드: 실제 일을 하는 '손발' 역할

• 도커 호스트와 비슷한 개념

• 실제로 컨테이너를 실행시킴

쿠버네티스 클러스터 관리 도구

• kubectl: 명령줄 도구

• 매니페스트 파일: YAML 또는 JSON 형식의 설정 파일

• 주로 YAML 형식 사용 (가독성이 좋음)

• 파일 확장자: .yaml, .yml, .json

관리 과정

• 매니페스트 파일로 '리소스' 정의
• kubectl이 이 정보를 쿠버네티스 마스터의 API에 전달
• 쿠버네티스 마스터가 이를 바탕으로 클러스터 관리

API 특징

• RESTful API 형태
• kubectl 외에도 다양한 방법으로 직접 호출 가능
• (예: 프로그래밍 언어의 RESTful API 라이브러리, curl 등)

쿠버네티스와 리소스

• 쿠버네티스 관리를위해 등록하는 리소스는
• 컨테이너의 실행과 로드 밸런서 생성 등 많은 종류가 있음
• 그림은 해당 리소스에 해당하는 5가지 종류의 리소스

워크로드 API 카테고리

• 목적: 컨테이너를 클러스터에서 실행하기 위한 리소스
• 주요 리소스: 파드, 레플리카셋, 디플로이먼트, 데몬셋, 스테이트풀셋, 잡, 크론잡 등
• 특징: 컨테이너 실행과 관리의 기본 단위

서비스 API 카테고리

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

• 목적: 서비스 발견과 외부 접속을 위한 리소스
• 주요 리소스: 서비스(여러 타입), 인그레스
• 특징: 네트워크 연결과 로드 밸런싱 담당

컨피그 & 스토리지 API 카테고리

• 목적: 설정, 기밀 데이터, 영구 저장소 제공
• 주요 리소스: 시크릿, 컨피그맵, 영구 볼륨 클레임
• 특징: 데이터 관리와 저장을 담당

클러스터 API 카테고리

• 목적: 클러스터 자체의 동작 정의
• 주요 리소스: 노드, 네임스페이스, 영구 볼륨, 리소스 쿼터, 서비스 어카운트, 롤, 네트워크 정책 등
• 특징: 클러스터 수준의 설정과 보안 관리

메타데이터 API 카테고리

• 목적: 다른 리소스의 동작 제어

• 주요 리소스: LimitRange, HorizontalPodAutoscaler, PodDisruptionBudget, 커스텀 리소스 데피니션

• 특징: 리소스 사용량 제어, 자동 스케일링 등 관리 기능 제공

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

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

네임스페이스의 개념

• 가상의 클러스터 분리 기능
• 완전한 분리는 아니지만, 여러 용도로 클러스터를 나눠 사용 가능

기본 네임스페이스:

• kube-system: 클러스터 구성 요소와 애드온용
• kube-public: 모든 사용자가 공유하는 설정용
• kube-node-lease: 노드 상태 확인용 (일반 사용자는 신경 쓰지 않아도 됨)
• default: 일반적인 사용자 리소스용

네임스페이스 사용의 장점

• 여러 팀이 하나의 클러스터를 공유할 때 유용
• 서비스 환경, 개발 환경 등을 구분할 때 사용 가능

보안과 네트워크 정책

• RBAC: 네임스페이스별로 권한 관리 가능
• 네트워크 정책: 네임스페이스 간 통신 제어 가능

네임스페이스 분리에 대한 조언

• 마이크로서비스 개발 팀별로 분리하는 것이 좋음
• 환경(서비스, 스테이징, 개발)은 네임스페이스가 아닌 클러스터로 분리 권장

클러스터로 환경 분리를 권장하는 이유

• 클러스터 업그레이드 시 모든 환경 동시 장애 방지
• 매니페스트 재사용성 향상
• 서비스 이름 해석 간소화

커맨드 라인 인터페이스(CLI) 도구 kubectl

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

• 직접 API에 요청을 보내거나 클라이언트 라이브러리를 사용하여 클러스터를 조작함

• 수동으로 조작하는 경우에는 CLI 도구인 ‘kubectl’을 사용하는 것이 일반적

4.5.1 인증 정보와 컨텍스트(config)

• Kubeconfig에서 구체적으로 설정이 이루어지는 부분은 clusters/users/contexts 세 가지

• kubectl이 쿠버네티스 마스터와 통신할 때는 접속 대상의 서버 정보, 인증 정보 등이 필요

• kubectl은 kubeconfig(기본 위치는 ~/.kube/config)에 쓰여 있는 정보를 사용하여 접속

• kubeconfig도 매니페스트와 동일한 형식으로 작성

kubeconfig 파일의 중요성

• kubectl이 쿠버네티스 마스터와 통신할 때 사용하는 설정 파일입니다.
• 기본 위치는 ~/.kube/config 입니다.
• 서버 정보, 인증 정보 등을 포함합니다.

이유: kubeconfig 파일은 kubectl이 클러스터에 연결하고 작업을 수행하는 데 필요한 모든 정보를 담고 있어 매우 중요합니다. 이 파일이 없으면 kubectl은 클러스터와 통신할 수 없습니다.

kubeconfig 파일의 구조

• apiVersion, kind, preferences, clusters, users, contexts, current-context로 구성.
• 매니페스트와 동일한 YAML 형식으로 작성.

이유: 이 구조는 쿠버네티스의 일관된 설정 방식을 따르며, 사용자가 쉽게 이해하고 수정할 수 있도록 설계되었습니다.

kubeconfig의 주요 섹션

• a. clusters: 접속 대상 클러스터 정보를 정의합니다.

• b. users: 인증 정보를 정의합니다.

• c. contexts: cluster와 user, 네임스페이스를 조합하여 정의합니다.

  이유: 이렇게 분리된 구조를 통해 여러 클러스터, 사용자, 네임스페이스 조합을 쉽게 관리할 수 있습니다.

kubeconfig 설정 변경 방법

• 직접 파일 편집
• kubectl 명령어 사용 (예: kubectl config set-cluster, set-credentials, set-context)

이유: 직접 편집은 유연성을 제공하지만, kubectl 명령어를 사용하면 오류를 줄이고 일관성을 유지할 수 있습니다.

컨텍스트 관리

• 목록 표시: kubectl config get-contexts
• 전환: kubectl config use-context
• 현재 컨텍스트 확인: kubectl config current-context
• 명령어별 컨텍스트 지정: kubectl --context

이유: 컨텍스트 관리 기능을 통해 여러 환경이나 권한 사이를 쉽게 전환할 수 있어, 복잡한 멀티 클러스터 환경에서도 효율적으로 작업할 수 있습니다.

인증 방식

• X.509 클라이언트 인증서, 토큰, 패스워드, 웹훅 등 다양한 방식 지원

이유: 다양한 인증 방식을 지원함으로써 조직의 보안 정책이나 인프라 구조에 맞는 유연한 인증 설정이 가능합니다.

kubectx/kubens를 사용한 전환

• 컨텍스트나 네임스페이스를 전환할 때 kubectl 명령어를 사용하는 것이 불편하다면 오픈 소스 소프트웨어인 kubectx/kubens4를 사용하는 것을 검토
• 컨텍스트와 네임스페이스 전환을 쉽게 만들어주는 도구

kubectx/kubens의 필요성

• 많은 클러스터나 네임스페이스를 관리해야 할 때 유용합니다.
• kubectl config use-context나 kubectl --namespace 명령어 사용의 비효율성을 해결합니다.

이유: 이는 왜 이 도구들이 필요한지, 어떤 문제를 해결하는지 설명합니다. 복잡한 환경에서 작업 효율성을 높이는 데 중요합니다.

kubectx/kubens의 장점

• 자동 완성 기능 제공

• 컨텍스트 변경 시 컨텍스트명 지정이 매우 쉬움

  매니페스트와 리소스 생성/삭제/갱신

  

  • kubectl을 사용하여 실제 매니페스트를 기반으로 컨테이너를 기동해보자. 여기서는 하나의 컨테이너를 가진 파드를 sample-pod라는 이름으로 생성

    

    

    리소스 생성에도 kubectl apply를 사용해야 하는 이유

    
    
    

kubectl apply 사용의 두 가지 주요 이유

• 일관성 유지

• kubectl create는 생성, kubectl apply는 업데이트에 사용된다는 구분이 불필요
• CI/CD 파이프라인이나 스크립트에서 조건 분기 없이 항상 apply를 사용할 수 있습니다.

이유: 이는 코드의 복잡성을 줄이고, 오류 가능성을 낮추며, 일관된 워크플로우를 유지할 수 있게 합니다.

b) 변경 사항 감지의 정확성

• create와 apply를 혼용하면 apply 실행 시 변경 사항을 제대로 감지하지 못할 수 있습니다.

이유: 이는 리소스 관리의 정확성과 일관성을 보장하기 위해 중요합니다.

kubectl apply의 동작 방식

• 세 가지 정보를 비교하여 변경 사항을 결정합니다:

• 이전에 적용한 매니페스트

• 현재 클러스터에 등록된 리소스 상태

• 이번에 적용할 매니페스트

• 필드 추가/변경: 현재 상태와 새 매니페스트 비교
• 필드 삭제: 이전 매니페스트와 새 매니페스트 비교

이유: 이 복잡한 비교 과정은 리소스의 상태를 정확하게 추적하고 변경할 수 있게 합니다.

'last-applied-configuration' 어노테이션

• kubectl create --save-config 또는 kubectl apply 사용 시 저장됩니다.
• metadata.annotations.kubectl.kubernetes.io/last-applied-- configuration에 JSON 형식으로 저장됩니다.

이유: 이 어노테이션은 apply가 변경 사항을 정확히 계산하는 데 필요합니다.

kubectl create의 문제점

• --save-config 옵션 없이 사용하면 'last-applied-configuration'이 저장되지 않습니다.
• 이로 인해 필드 삭제 시 의도한 대로 반영되지 않을 수 있습니다.

이유: 이는 리소스 관리의 일관성과 정확성을 해칠 수 있어 주의가 필요합니다.

경고메시지:

• create 후 apply 사용 시 경고가 발생합니다.

이유: 이 경고는 잠재적인 문제를 사용자에게 알려주어 오류를 예방합니다.

책에서의 접근 방식

• 특별히 명시하지 않는 한 kubectl apply를 사용합니다.
• 각 리소스 설명 후 kubectl delete로 리소스를 삭제합니다.

이유: 이는 일관된 학습 환경을 제공하고, 각 예제를 독립적으로 이해할 수 있게 합니다.