[Kubernetes] 쿠버네티스 시작 전 알고가기

목록

1. 포스팅 개요
2. 본론
     2-1. 모든 리소스는 오브젝트 형태로 관리
     2-2. 쿠버네티스는 명령어로도 사용할 수 있지만, YAML 파일을 더 많이 사용한다.
     2-3. 쿠버네티스는 여러 개의 컴포넌트로 구성되어 있다.
3. 요약

1. 포스팅 개요

이 포스팅은 위키북스 출판사의 '시작하세요! 도커/쿠버네티스'의 제 6장 쿠버네티스 시작하기를 학습하며 기록한 포스팅이다.

그 중 쿠버네티스를 시작하기 전 알고가면 될 내용들을 정리했다.
쿠버네티스가 어떻게 사용되어야 하는지, 어떤 식으로 사용되는지에 대한 내용이다.

2. 본론

쿠버네티스를 사용하기 전 알고가면 좋을 사항들이 있다.

2-1. 모든 리소스는 오브젝트 형태로 관리된다

• 쿠버네티스는 대부분의 리소스를 '오브젝트'라고 불리는 형태로 관리한다.
  • '오브젝트'
  • 도커 스웜 모드에서 컨테이너의 묶음을 표현하기 위해 서비스(service)라는 것을 사용하는데, 스웜 모드의 서비스도 컨테이너 리소스의 집합을 정의한 것이기 때문에 일종의 오브젝트라고 볼 수 있다.
  • 쿠버네티스는 이러한 개념을 더욱 폭넓고 세밀한 단위로 사용한다.
• 쿠버네티스에서는 컨테이너의 집합(Pods), 컨테이너의 집합을 관리하는 컨트롤러(Replica Set), 심지어 사용자(Service Account), 노드(Node)까지도 하나의 오브젝트로 사용할 수 있다.

쿠버네티스에서 사용할 수 있는 오브젝트 확인

다음 명령어로 확인할 수 있다.

kubectl api-resources
NAME                                SHORTNAMES   APIVERSION
     NAMESPACED   KIND
bindings                                         v1
     true         Binding
componentstatuses                   cs           v1
     false        ComponentStatus
configmaps                          cm           v1
     true         ConfigMap
endpoints                           ep           v1
     true         Endpoints
events                              ev           v1
     true         Event

...

근데 진짜 겁나 많다....

• 이렇게 많은 종류의 오브젝트를 이 책에서 전부 다루지 않는다.
  • 모든 종류와 이름을 외우려고 노력하지 않아도 된다.
  • 자주 사용하는 오브젝트들은 책의 내용을 따라 하면서 자연스럽게 이름과 기능을 외울 수 있기 때문이다.
  • 또한 쿠버네티스 공식 문서에서 대부분의 리소스 오브젝트의 사용 방법을 친절하게 설명하고 있기 때문에 처음 보는 오브젝트라도 당황하지 말고 필요에 따라 배우고 익히면 된다.

특정 오브젝트의 간단한 설명을 보고 싶다면 kubectl explain을

특정 오브젝트의 간단한 설명을 보고 싶다면 kubectl explain 명령어를 사용하면 된다.

$ kubectl explain pod
KIND:       Pod
VERSION:    v1

DESCRIPTION:
    Pod is a collection of containers that can run on a host. This resource is
    created by clients and scheduled onto hosts.

FIELDS:
  apiVersion    <string>
    APIVersion defines the versioned schema of this representation of an object.
    Servers should convert recognized schemas to the latest internal value, and
    may reject unrecognized values. More info:
    https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources

  kind  <string>
    Kind is a string value representing the REST resource this object
    represents. Servers may infer this from the endpoint the client submits
    requests to. Cannot be updated. In CamelCase. More info:
    https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds

  metadata      <ObjectMeta>
    Standard object's metadata. More info:
    https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

  spec  <PodSpec>
    Specification of the desired behavior of the pod. More info:
    https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status

  status        <PodStatus>
    Most recently observed status of the pod. This data may not be up to date.
    Populated by the system. Read-only. More info:
    https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status

2-2. 쿠버네티스는 명령어로도 사용할 수 있지만, YAML 파일을 더 많이 사용한다

• 쿠버네티스에서도 마찬가지로 kubectl 이라고 하는 명령어로 쿠버네티스를 사용할 수 있으며, 대부분의 작업은 kubectl 명령어로 실행할 수 있다.
  • 도커 스웜 모드에서는 docker service create... 와 같은 명령어로 컨테이너 서비스를 생성하고 삭제한다.
    • 스웜 모드에서 스택(stack)을 생성하기 위해 YAML 파일을 사용했던 것처럼 쿠버네티스도 YAML 파일로 컨테이너 리소스를 생성하거나 삭제할 수 있다.
  • 그러나 쿠버네티스에서 YAML 파일의 용도는 컨테이너뿐만 아니라 거의 모든 리소스 오브젝트들에 사용될 수 있다는 것이 가장 큰 특징이다.
  • 예를 들어 컨테이너 자체는 물론이고, 컨테이너의 설정값(ConfigMap), 비밀값(Secrets) 등 도 모두 YAML 파일로 정의해 사용한다
  • 쿠버네티스에서 실제로 서비스를 배포할 때에도 kubectl 명령어가 아닌 여러 개의 YAML 파일을 정의해 쿠버네티스에 적용시키는 방식으로 동작한다.

따라서 쿠버네티스를 잘 사용하는 방법= 'YAML 파일을 잘 작성하는 것' 이다.
해당 책에서 이후에 다룰 모든 리소스 오브젝트는 기초적인 부분을 제외하면 대부분 YAML 파일로 작성하며 진행한다.

2-3. 쿠버네티스는 여러 개의 컴포넌트로 구성되어 있다.

• 쿠버네티스 노드의 역할은 크게 마스터와 워커로 나뉘어져 있다.
  • 마스터 노드는 쿠버네티스가 제 대로 동작할 수 있게 클러스터를 관리하는 역할을 담당한다.
  • 워커 노드에는 애플리케이션 컨테이너가 생성된다.
• 도커 스웜 모드를 사용할 때는 단일 도커 데몬만을 설치해 사용했지만, 쿠버네티스는 도커를 포함한 매우 많은 컴포넌트들이 실행된다.
  • 예)
    • 마스터 노드에서는 API 서버(kube-apiserver), 컨트롤러 매니저(kube-controller-manager), 스케줄러(kube-scheduler), DNS 서버(coreDNS) 등이 실행
    • 모든 노드에서는 오버레이 네트워크 구성을 위해 프락시(kubeproxy)와 네트워크 플러그인(calico, flannel 등)이 실행된다.
  • 이러한 컴포넌트들은 기본적으로 컨테이너로서 실행되고 있다.
  • 마스터 노드에 SSH로 접속해 crictl 명령어를 실행해보면 매우 많은 컨테이너가 실행되고 있는 것을 확인할 수 있다.

# 안 되면 sudo 를 앞에 붙이자.
$ crictl --runtime-endpoint unix:///run/containerd/containerd.sock ps
CONTAINER           IMAGE               CREATED             STATE               NAME                      ATTEMPT             POD ID              POD                                    NAMESPACE
711b0dda8ec1f       dc4a8a56c133e       17 hours ago        Running             tigera-operator           0                   7f91cbdd62076       tigera-operator-ccfc44587-4mmc4        tigera-operator
f5e799efbe05b       f1332858868e1       17 hours ago        Running             kube-proxy                0                   c1e8f0397bffe       kube-proxy-lmtq6                       kube-system
91257a6a823eb       b6a454c5a800d       17 hours ago        Running             kube-controller-manager   0                   fd747ad58da2a       kube-controller-manager-kuber-master   kube-system
b7f3197f66c83       a9e7e6b294baf       17 hours ago        Running             etcd                      0                   008ad01926e35       etcd-kuber-master                      kube-system
01b7d790bb31f       85b7a174738ba       17 hours ago        Running             kube-apiserver            0                   dda9ca16083c3       kube-apiserver-kuber-master            kube-system
0c2c03c309ed6       d8e673e7c9983       17 hours ago        Running             kube-scheduler            0                   e5aeaa73c4344       kube-scheduler-kuber-master            kube-system

Docker Desktop for Windows/Mac에서는 Preferences에서 [Kubernetes] 탭을 선택한 다음 Show system containers 항목에 체크하면 docker ps 의 출력에서 쿠버네티스의 컴포넌트 컨테이너를 확인할 수 있다.
단 쿠버네티스에 대한 자세한 지식 없이는 핵심 컴포넌트를 건드리지 않는 것이 좋다..!!

• 쿠버네티스 클러스터 구성을 위해 kubelet이라는 에이전트가 모든 노드에서 실행된다.
• kubelet은 컨테이너의 생성, 삭제뿐만 아니라 마스터와 워커 노드 간의 통신 역할을 함께 담당하는 매우 중요한 에이전트다.
  • 따라서 kubelet이 정상적으로 실행되지 않으면 해당 노드는 쿠버네티스와 제대로 연결되지 않을 수도 있다.
  • 쿠버네티스의 입장에서 보면 컨테이너 런타임 인터페이스를 제공하는 containerd나 cri-o, 또는 도커 데몬 또한 하나의 컴포넌트다.
  • 도커 스웜모드와 달리 쿠버네티스는 도커에 내장된 기능이 아니며, 오히려 컨테이너를 사용하기 위해 쿠버네티스가 다른 컴포넌트를 이용하는 방식이다.
  • 따라서 쿠버네티스에서 반드시 containerd를 사용해야 할 필요는 없으며, OCI(Open Container Initiative)라는 컨테이너 런타임 표준을 구현한 컨테이너 런타임을 갖추고 있다면 어느 것을 써도 문제는 없다.

---

참고

컨테이너 런타임 인터페이스(Container Runtime Interface)는 kubelet 이 컨테이너를 제어하기 위한 인터페이스를 의미한다.
컨테이너 런타임 인터페이스의 개념에 대해 좀 더 알고 싶다면 쿠버네티스 공식 문서 및 블로그를 참고하자.

---

• 참고로 이렇게 많고 복잡한 컴포넌트의 구조를 지금 당장 외우거나 이해하려고 하지 않아도 됩니다.
• 이러한 것들을 자세히 알지 못해도 쿠버네티스의 기능을 익히는 것에는 큰 문제가 없으며, 필요할 때마다 쿠버네티스의 기능과 컴포넌트를 함께 엮어서 설명한다.
• 지금은 kubelet 이라는 에이전트가 모든 노드에서 기본적으로 실행되며, 마스터 노드에는 API 서버 등이 컨테이너로 실행된다' 정도만 알고 넘어가면 된다.

3. 요약

• 쿠버네티스의 모든 리소스는 오브젝트 형태로 관리된다.
• 명령어보단 YAML 파일을 더 많이 사용한다.
• 쿠버네티스는 여러 개의 컴포넌트로 구성되어 있다.
  • kubelet 에이전트는 모든 노드에서 기본적으로 실행되며, 마스터 노드에는 API 서버 등이 컨테이너로 실행된다.