Kubectl과 Namespace

유데미의 Kubernetes for beginners 2023 with AWS EKS examples강의 섹션 1,2,3을 정리. 주로 Kubectl과 Namespace에 대한 내용. 틀린내용 있으면 언제든지 말씀해주세요.

 

Docker에서 말하는 컨테이너란 무엇입니까?

컨테이너는 실행 가능한 소프트웨어의 단위를 의미하며, 따라서 소프트웨어 실행을 위한 코드나 설정값을 가지고 있다.

(아주 심플하게 설명하면 게시판 Container, Mysql Container 같은 것들이다. 앞서 말했듯이 각 컨테이너는 독립적으로 실행이 가능하다.)

 

컨테이너는 Host OS위에 Guest OS를 얹어서 실행하는 방식이 아닌 Host OS의 Resource를 직접 사용하는 방식을 사용한다.

 

아래와 같은 Hypervisor 방식은 Guest OS의 용량도 클 뿐만 아니라, 배포속도 면에서도 Container Engine을 사용하는 방식에 한참 뒤떨어진다.

 

Container Engine에 의해 생성 및 실행되는 Container는 용량 뿐만 아니라 배포 속도면에서 우수하다. 또한, Guest OS의 버전에 맞춰서 프로그램 실행에 필요한 버전을 별도로 관리할 필요가 없어졌다. (신경쓸게 하나 줄었다!!)

Docker를 배우면 꼭 보게되는 그림

컨테이너를 생성하기 위해선 이미지가 필요하다.

Java로 치면 Container는 Instance이고, Image는 Class이다. 즉, 이미지를 인스턴스화한 것이 컨테이너이다.

 

Java의 Class와 Instance와 다른 점이라 하면 Image는 수정이 불가능한 Layer의 집합으로 이뤄져 있다.

따라서, Image는 한번 만들어지고 나면 변경이 불가능하다. (Container도 마찬가지!)

 

이미지는 어디서 관리 되고 있나요?

이미지는 Github과 같은 Docker Registry 공간에서 관리되고 있다.

DockerHub가 많이 쓰인다. Github처럼 Image에 대한 공개/비공개 설정이 가능하다. 다른 사람의 공개 Image를 가져와 이를 확장해서 나만의 Image를 만들어 낼 수 있다. (이미지는 수정불가하기 때문에 확장해서 사용한다!)

 

기업 같은 경우에는 AWS의 ECR을 통해서 이미지를 기업내부에서 관리하기도 한다.

 

도커 이미지 생성 예시

이미지를 생성하기 위해선 Dockerfile을 작성해야한다.

Dockerfile의 내용은  또 다른 이미지와 Docker 명령어를 통해 구성되며 이들을  Layer처럼 쌓는 방식으로 작성된다.

FROM python # 별도의 태그를 작성하지 않으면 최신버전을 사용한다.

WORKDIR /app # 도커엔진 내에 있는 /app로 이동한다

COPY requirements.txt requirements.txt # 로컬 파일을 도커엔진에 있는 /app으로 복사한다

RUN pip install -r requirements.txt # pip install을 실행해서 requirements.txt내 정의된 라이브러리를 설치한다

COPY . /app # 현재경로에 있는 파일들을 /app으로 복사한다

EXPOSE 8000 # 컨테이너 실행시 8000 port를 사용한다.

ENTRYPOINT [ "python", "manage.py" ] # 컨테이너 실행시 python manage.py 명령어를 실행시킨다.
CMD ["runserver", "0.0.0.0:8000"] # runserver 0.0.0.0:8000을 실행한다

docker image ls 명령어를 통해서 내 로컬에 존재하는 이미지들을 조회할 수 있다.

 

---

Kubernetes(k8s) 와 Node

Node는 k8s의 클러스터를 구성하는 Machine이다. (Logical or Physical) Node는 1개 이상의 Container를 포함하고 있는 물리적 또는 논리적 서버라고 생각하면 된다. 그리고 k8s는 이 Node들을 구성하고, Life Cycle을 관리하는 Tool이다.

Node의 종류

Worker Node - 내가 제작한 Application이 실행되고 있는 Node.

Control Plane Node - k8s의 기능들을 관리하는 노드이다. Worker Node를 관리하는 노드.

(여담. AWS과 같은 클라우드 회사들은 Control Plane을 Wrapping한 서비스를 제공하며, 이런 서비스를 Control Plane Node의 가용성을 보장 받을 수 있음. 즉, 나 같은 개발자는 그냥 Worker Node가 잘 떠있는지 체크하기만 하면 된다. AWS의 EKS)

---

Node 뜯어보기

Kube API Server

Kube API Server는 Control Plane Node 내에 있는 API Server이다. 

k8s 클러스터를 제어하기 위한 요청들을 받아 내고, 이 요청들을 적절하게 수행한다. 요청은 kubectl을 설치해서 보내면 된다.

Etcd(distributed key value storage)

k8s 클러스트의 내용을 백업하는 데이터베이스이다.(Key-value 형태) Control Plane Node가 1개 있다면 Etcd도 1개 있다고 생각하면 된다. 

 

아래는 Etcd의 공식 사이트이다. 사용자 목록에 k8s가 있는걸 볼 수 있다.

etcd

k8s가 etcd를 어떻게 활용하고 있는지 설명한 공식 문서.

Operating etcd clusters for Kubernetes

 

Kubelet

클러스터 내에 있는 모든 노드는 kubelet을 가지게 된다. kubelet은 node간 통신이 가능하도록 한다.

즉, Node 전용의 네트워크 장비인 셈.

---

테스트를 위한 환경 구성하기 - Kubectl, MicroK8s 설치

Kubectl

Kubectl은 원격에서 실행중인 K8s 클러스터에 접근하기 위한 클라이언트 툴이다.

k8s 클러스터는 HTTPS를 통한 REST API통신을 허용하기 때문에 Kubectl과 REST API로 통신하게 된다. (여기서 ctl은 controller의 약자이다.)

 

Mac OS 사용자는 아래 링크를 통해 Kubectl 설치가 가능하다.

Install and Set Up kubectl on macOS

 

아래 명령어를 통해서 kubectl이 접속할 Cluster를 확인할 수 있다. kubectl과 관련된 명령어를 실행할 때마다 ~/.kube/config의 설정을 읽어 Cluster로 명령어를 보내게 된다. (kubectl이 읽는 기본 경로임.)

cat ~/.kube/config

위에서 언급한 기본 경로 외에 있는 config파일을 사용하고 싶다면 아래 명령어를 사용하자. (KUBECONFIG라는 환경 변수에 config파일의 경로를 세팅한다)

export KUBECONFIG=/path/to/config   # to set variable
printenv | grep KUBECONFIG          # to view variable 

MicroK8s

MicroK8s는 내 로컬에서 간단히 K8s 클러스를 구축할때 사용한다.

Mac OS 사용자는 아래 링크를 따라서 설치하면 된다.

https://microk8s.io/docs/install-macos

microk8s kubectl get nodes 명령어를 통해서 명령어를 통해서 microk8s내 노드를 확인할 수 있다.

---

(namespace와 kubeconfig는 상호적인 관계라 어떤걸 먼저 설명할지 애매함... 일단 namespace를 먼저 설명하고 kubeconfig에 대해서 설명함.)

2개의 Node를 분리된 환경에 배포하고 싶다면?

방법1 - 클러스터 분리

2개의 완전히 분리된 클러스터가 머리로는 가장 편한 방법이겠지만, 비용적인 측면에서 효율적이지 못하다. (관리해야하는 Control Plane Node 증가 -> 관리 리소스 증가)

방법2 - Namespace 활용하기

k8s에서 제공하는 Namespace를 활용하면 Node의 논리적 구분이 가능하다. 또한, Namespace별로 Node접근에 대한 사용자별 권한 설정이 가능하다. (Namespace를 활용하면 물리적 리소스뿐만 아니라 관리 리소스도 감소하게 된다)

 

아래는 namespace 제어를 위한 kubectl 명령어 예시이다.

 

kubectl get namespaces를 통해서 현재 존재하는 namespace 목록을 확인할 수 있다.

kubectl create ns [namespace명]를 통해서 새로운 namespace를 생성할 수 있다.

kubectl describe namespaces [namespace명]를 통해서 namespace의 상세 정보를 조회할 수 있다.

kubectl get ns [namespace명] -o yaml을 통해서 yaml 형태의 namespace 정보를 확인할 수 있다.

kube-system이란 namespace에 대한 정보를 yaml 형태로 조회

kubectl config view를 통해서도 현재 config 확인이 가능하다. (중요정보는 인코딩되어 출력됨!)

---

 

Kubeconfig 살펴보기

앞서 말한대로 kubectl을 통해서 k8s의 클러스터와 소통하기 위해선 kubeconfig를 참조한다고 했다. kubeconfig가 어떻게 구성되어 있는지 살펴보자.

Clusters 영역

kubectl이 접속할 Cluster의 정보가 기록된 영역이다.

 

Users 영역

클러스터에 접속할 사용자 정보가 기록되어 있다.

token 기반 인증을 사용할 경우 token 필드가 필요하며 그외 username/password와 client-key-data 인증 방식도 가능하다.

Contexts 영역

Combination of Cluster and User. 즉, 위에 작성한 Cluster와 User에 대한 매핑정보를 기록하는 영역이다.
이 영역에서 Cluster와 User를 1대1로 매핑을 할 수 있다.

여기서 namespace 작성이 가능한데 namespace가 default인 경우는 위 사진처럼 아무런 표기를 하지 않아도 된다.

그 외

kind는 k8s의 객체 타입을 나타낸다. (The type of Kubernetes object)

apiVersion은 Kube API서버로 요청시 사용할 API의 버전을 나타낸다.

current-context은 현재 붙어서 작업중인 context가 무엇인지 나타낸다. (The current context we are operating in)