K8S-02_쿠버네티스 기초와 kubectl

2021.12.18 - [Devops 2회차/K8S Study] - K8S-01_개요 및 스터디 계획

참조

서적: 쿠버네티스 완벽 가이드

쿠버네티스 API 공식문서: https://kubernetes.io/docs/concepts/overview/kubernetes-api/ 

The Kubernetes API

---

개요

쿠버네티스를 처음 접한다면 어디서부터 어떻게 이해하면 좋을까? 라는 생각을 자주 하곤 했다.
그런데 쿠버네티스를 이해하려고 할수록 깊은 수렁텅이에 빠지듯이 굉장히 시스템의 아랫단에서부터의 이해를 필요로한다.
하지만 시작부터 모든 빙산의 크기를 알려고 하면 너무 많은 러닝커브가 생기기 때문에 우선 빙산의 일각부터 파악해보자.
내가 생각하는 쿠버네티스 공부의 시작은  API리소스의 단위를 이해는 것이다.
앞서 이야기했듯이 쿠버네티스를 익힐때 무조건 생성된 파드에서
kubectl 부터 쳐보기보다는 API리소스의 분류부터 이해한다면 좀 더 효율적으로 쿠버네티스를 이해할 수 있다.

아래는 44bits에서 제공하는 쿠버네티스 기초설명 유튜브인데,
시간이 있다면 이걸 먼저 보고 오는 걸 추천한다. 설명이 깔끔하고 구체적이어서 접근하기가 쉽다.
https://youtu.be/Ia8IfowgU7s

---

용어

이번 내용을 이해하려면 아래와 같은 용어/단어 들과 친숙해야 한다.

kubectl : 쿠버네티스 클러스터를 관리하기 위한 CLI 
manifests : 쿠버네티스의 리소스를 정의 내리는 파일들
.yaml : 파일의 확장자 형식 중 하나 (야믈이라고 읽음) - 주로 쿠버네티스 manifests는 야믈이나 제이슨으로 정의내린다.

---

쿠버네티스 아키텍쳐의 이해

가장 먼저 쿠버네티스의 아키텍처에 대해서 간략하게 정리한다.
이 부분은 GCP의 GKE, AWS의 EKS를 사용한다면 사실 모른다고 하여도 실무를 진행하는데 큰 문제가 되지 않으나,
그건 별로 추천하는 자세는 아니다. (경험상 결국 장애나 문제가 생기면 지식의 깊이가 밑천을 금방 탄로나기때문에..)
그래서 간략한 개념만 정리하고, 만일 궁금하다면 개별적으로 검색해보길 추천한다.

• etcd: 쿠버네티스의 모든 정보가 저장되어 보관되는 아주 중요한 녀석이다.
  분산 KVS(Key Value Store)인데 중요한만큼 가용성 확보가 필수이다.
  또한, 알고리즘 래프트의 특성상 클러스터 구성은 홀수로 구성하는 것을 권한다고 한다. 
• kube-apiserver: 쿠버네티스 API를 제공하는 구성 요소이다.
  우리가 kubectl로 커맨드를 날리면 kube-apiserver로 전달되어 리소스의 생성/삭제 작업 등이 이뤄진다.
  뿐만 아니라 kube-scheduler, kube-controller-manager 등의 구성 요소도 전부 apiserver로 요청을 전달하여 필요한 작업을 한다.
• kube-scheduler: kube-apiserver에 등록된 파드 리소스를 기동하는 노드 정보 부분을 kube-apiserver에 요청을 보내서 수정함으로써 스케쥴링한다.
  단, scheduler는 수정하라고 전달만 하고, 실제 노드에 파드를 기동하는 처리는 kubelet이 담당하게 된다.
• kubelet: 행동대장이다. 각 쿠버네티스 노드에서 동작하는 구성 요소다.
  실제 컨테이너에 대한 기동과 정지 등을 관리한다.
  (예를 들어 노드 정보가 할당되었으나 현황가 다르게 기동하지 않은 파드가 있다면 기동 시킨다.)
• kube-controller-manager: 각각 담당하는 컨트롤러를 실행하는 구성요소이다.(디플로이먼트나 레플리카셋과 같이)
  예를 들어 파드 수를 늘리는 경우 controller-manager는 변경된 파드 수에 대한 정보를 생성한다.
  (생성만 하고 스케쥴링은 kube-scheduler가 한다)
• kube-proxy: 실제 서비스를 하면 요청이 전달될텐데,
  kube-proxy는 노드에서 동작하면서 ClusterIP나 NodePort로 가는 트래픽이 파드에 정상적으로 전송되도록 하는 역할을 한다. 
• kube-dns: 쿠버네티스 클러스터 내부의 이름 해석이나 서비스 디스커버리에 사용되는 클러스터 내부의 DNS 이다.

단어가 너무 어렵고 낯설다. 그냥 읽고 넘어가 본다. 자연스럽게 하면서 익히는것을 추천한다.
kubectl로 pod를 하나 생성하면
-> kube-apiserver를 통해 파드가 등록되고
-> kube-scheduler에 의해서 파드가 기동되는 노드가 결정되고
-> kubelet은 그것을 감지하고 자신의 노드에서 기동해야 하는 컨테이너를 기동한다.

---

쿠버네티스 API 리소스 카테고리

여기서부터 쿠버네티스를 이해하기 시작하길 추천한다.

API 종류	개요
워크로드 API	컨테이너 실행과 관련된 리소스 (파드, Replicasiton 컨트롤러, 레플리카셋, 디플로이먼트, 데몬셋, 스테이트풀셋, 잡, 크론잡 등)
서비스 API	컨테이너를 외부에 공개하는 Endpoint를 제공하는 리소스 (ClusterIP, ExternalIP, NodePort, LoadBalancer, Headless, ExternalName, None-Selector
컨피그 & 스토리지 API	설정/ 기밀 정보/ 영구 볼륨 등에 관련된 리소스 (시크릿, 컨피그맵, PersistentVolumeClaim)
클러스터 API	보안이나 쿼터 등에 관련된 리소스 (노드, 네임스페이스, PersistentVolume, Quota, Service Account, Role, Cluster Role, RoleBinding, ClusterRoleBinding, NetworkPolicy)
메타데이터 API	클러스터 내부의 다른 리소스를 관리하기 위한 리소스 (LimitRange, HorizontalPodAutoscaler, PodDisruptionBudget, CustomResourceDefinition)

위와 같은 종류가 있다는 것만 우선은 알아두자.
아무래도 앞으로 한 영역씩이 대주제가 될 것 같다.
위에 있는 내용들은 실무하면서 당연히 이해해야하고,
어떻게 사용하냐에 따라서 서비스의 품질이 결정될 수 있는 중요한 녀석들이다.

kubectl

쿠버네티스를 관리하며 발생하는 변화나 조작은 모두 쿠버네티스의 마스터 API를 통해 이루어진다.
수동으로 이를 조작하는 대표적인 방법이 CLI 도구인 kubectl을 사용하는 것이다.

kubectl은 kubeconfig(~/.kube/config)에 쓰여 있는 정보를 사용하여 접속한다.
kubeconfig도 하나의 매니페스트이며 동일한 형식으로 작성되어 있다.
kubeconfig 내부 설정

• clusters (kubectl config set-cluster)
• users (kubectl config set-credentials)
• contexts (kubectl config set-context)

테스터 클러스터는 이미 생성 되어 있고, 아래는 context 정의를 수정하는 예시이다.
set-context는 클러스터/인증정보/네임스페이스 정의 등을 추가하거나 변경할 수 있는 command 이다.

kubectl config set-context tistory-admin \
--cluster=tistory-test-cluster \
--user=admin-user \
--namespace=default

기본적인 환경만 셋팅이 되어 있다면 이제부터는 엄청나게 많은 kubectl 커맨드를 사용할 것이다.

아래의 커맨드를 한번씩 해보면서 이번 편은 마무리한다.

kubectl config get-contexts
kubectl config use-context tistory-admin
kubectl config current-context