Kubernetes

kubectl

쿠버네티스 클러스터(= 서버)를 관리하는 동작은 대부분이 kubectl이라는 커맨드라인 인터페이스(CLI)로 실행할 수 있다.

kubectl에서 지원하는 명령은 아래와 같이 확인 가능.

kubectl or kubectl입력후 tab두번으로 자동완성 

• 형식 : kubectl [command][TYPE] [NAME][flags]
• 쿠버네티스 자원들의 생성,업데이트,삭제 (create, update, delete)
• 디버그, 모니터링, 트러블 슈팅 (log, exec, cp, top, attach...)
• 클러스터 관리 (cordon, top, drain, taint...)

쿠버네티스 오브젝트 관리

명령형 커맨드 : yaml파일 사용 x
명령형 오브젝트 구성 : yaml파일 사용 o
선언형 오브젝트 구성 : yaml파일 사용 o

📗 오브젝트 = resource
📗 오브젝트 관리 참조

명령형 커맨드

• 명령형 커맨드를 사용할 경우, 사용자는 클러스터 내 활성 오브젝트를 대상으로 직접 동작시킨다. 사용자는 실행할 작업을 인수 또는 플래그로 kubectl 커맨드에 지정한다.

• 이것은 클러스터에서 일회성 작업을 개시시키거나 동작시키기 위한 추천 방법이다. 이 기법은 활성 오브젝트를 대상으로 직접적인 영향을 미치기 때문에, 이전 구성에 대한 이력을 제공해 주지 않는다.

• yaml파일을 작성하지 않고 그냥 한줄로 명령을 실행하는 것.
  약간 ansible에서 adhoc명령과 같은 느낌.

• 예시로, 디플로이먼트 오브젝트를 생성하여 nginx 컨테이너의 인스턴스를 구동시킨다.

  	kubectl create deployment nginx --image nginx

명령형 오브젝트 구성

• 명령형 오브젝트 구성에서는 kubectl 커맨드로 작업(생성, 교체 등), 선택적 플래그, 그리고 최소 하나의 파일 이름을 지정한다. 그 파일은 YAML 또는 JSON 형식으로 오브젝트의 완전한 정의를 포함해야만 한다.
  
  -> 선언형 오브젝트와 다르게 파일을 지정해서 사용한다
  -> 쉽게말해 ansible에서 yaml파일로 작성된 playbook을 실행시키는 느낌

선언형 오브젝트 구성

• 선언형 오브젝트 구성을 사용할 경우, 사용자는 로컬에 보관된 오브젝트 구성 파일을 대상으로 작동시키지만, 사용자는 파일에서 수행 할 작업을 정의하지 않는다. 생성, 업데이트, 그리고 삭제 작업은 kubectl에 의해 오브젝트마다 자동으로 감지된다. 이를 통해 다른 오브젝트에 대해 다른 조작이 필요할 수 있는 디렉터리에서 작업할 수 있다.
  
  -> 명령형 오브젝트 구성과 다르게 파일이 아닌 디렉터리를 지정
  -> 쉽게말해 ansible에서 yaml파일로 작성된 playbook들을 하나의 디렉터리에 모아놓고 해당 디렉터리를 지정해 한번에 실행시키는 느낌

컨테이너 생성 및 실행하기

1 . 컨테이너 생성 예시

kubectl create deployment myapp --image=ghcr.io/c1t1d0s7/go-myweb:alpine
# 깃허브 레지스트리에서 image가져와서 컨테이너 생성

kubectl get deployments
# 배포한 컨테이너 정보 보기

kubectl get replicasets
# 내가 생성하지는 않았지만 자동으로 같이 생성된다
# replicasets 정보 보기

kubectl get pods
# 파드 정보 보기 

-> deployment deployment이름 의 형식으로 입력하는데 deployment는 컨테이너이름을 입력하는 느낌이다.

2 . 1번에서 만든 컨테이너에서 포트포워딩한 서비스 생성

kubectl expose deployment myapp --port=80 --protocol=TCP --target-port=8080 --name myapp-svc --typ
e=LoadBalancer
# 80을 8080에 포워딩 

kubectl get services
# 생성한 서비스 확인 

-> 브라우저에 호스트ip:80(생략) 입력하면 text 확인

3 . 컨테이너 복제 및 확인

kubectl scale deployment myapp --replicas=2
# 1에서 만든 컨테이너를 두개로 복제 

kubectl get pods
# 생성된 컨테이너 확인

-> 실제로 두개가 생성되어있는 것을 볼 수 있다.

-> 해당 ip에 curl해보면 로드 밸런싱이 되면서 text가 나오는 것을 확인
-> 실제 브라우저에 입력하면 로드 밸런싱은 되지 않는데, 그 이유는 브라우저는 로컬 캐싱을 하기 때문이다.

kubectl get all

-> pods, deployment, service, replicasets의 정보를 한번에 볼 수 있다.

4 . 삭제 및 선언형의 특징 예시

kubectl scale deployment myapp --replicas=5 
# myapp이라는 컨테이너의 복제본을 5개로 선언한 것

kubectl get all 
# 실제 확인해보면 pod가 5개가 생성됨

kubectl delete pod pod명
# 5개중 하나를 삭제

kubectl get all 
# 다시 확인해보면 그대로 5개가 존재하는 것을 확인

-> 이전에 삭제한 pod는 실제로 삭제되었지만 바로 새로운 pod가 생성되면서 5개를 유지한다.
-> 쿠버네티스는 선언한 상태를 유지하려고 한다
📗 pc의 성능이나 환경에 의해 반드시 유지할 수 있는 것은 아니다

5 . nginx이미지로 컨테이너 생성 및 웹 서비스 생성

kubectl create deployment mynginx --image nginx --replicas 2
# 생성할떄 replica를 지정해서 생성할 수 있다.

-> dockerhub에 sudo로 login해서 image를 다운받아도 된다
-> 다운 받지 않아도 그냥 image이름 입력하면 자동으로 이미지를 다운받아서 컨테이너를 생성한다

kubectl get all
# 두개가 생성된 것을 확인 

kubectl expose deployment mynginx --name mynginx-svc --port 80 --target-port 80 --protocol TCP --t
ype LoadBalancer
# 생성한 컨테이너에 포트포워딩한 웹 서비스 생성 

-> 만약 targetport는 위의 2번 예시처럼 8080으로 뚫으면 접속이 안되는 것을 볼 수 있는데, 이유는 2번 예시의 사용된 image는 8080포트를 사용할 수 있도록 임의로 설정한 것이고 nginx 기본 image는 기본 포트가 80이므로 targetport를 80으로 설정해야 한다.

📗 항상 작업을 한 후 만든 것은 지워야 한다

kubectl delete deployment deployment이름
kubectl delete service service이름 
kubectl delete pod pod이름 

쿠버네티스에 vscode 원격 접속

터미널에서 vi를 이용해 yaml파일을 작성할 수 있다._

vi ~/.vimrc # 설정파일 접속 후 아래처럼 작성

syntax on
autocmd FileType yaml setlocal ai ts=2 sw=2 sts=2 et autoindent
set cursorcolumn

-> 설정을 통해 ansible에서 yaml파일 작성한거와 같이 들여쓰기를 편하게 해준다

vi를 이용하지 않고 vscode를 연결하여 yaml파일 작성

1. vscode접속

2. 확장팩 클릭

3. Remote-ssh 설치

4. 터미널에서 vagrantfile있는 디렉터리에 명령어 입력

   vagrant ssh-config

5. 명령어 결과 복사

6. vscode 좌측하단 초록색 버튼 클릭

7. ssh 구성파일열고 users 디레터리에 .ssh선택 후 접속

8. 복사한 명령어를 아래와 같이 수정후 이어 붙이기

• hostname 각 노드 localhostip
• port 22

9. 저장후 좌측 바에 원격접속 클릭후 지정된 control plane으로 접속 (os는 linux선택)
10. vs코드 확장에서 yaml검색 후 설치

워크로드

💡 워크로드 참조

파드

• 쿠버네티스는 컨테이너를 컨트롤하지 않고, 파드를 컨트롤 한다
• 파드(Pod) 는 쿠버네티스에서 생성하고 관리할 수 있는 배포 가능한 가장 작은 컴퓨팅 단위이다.
• 하나 이상의 컨테이너의 그룹이다
• 싱글톤 : 파드안에 컨테이너가 하나만 있는 경우, 일반적으로 많이 사용된다.
• 함께 작동해야 하는 여러 컨테이너를 실행하는 파드 : 파드안에 두개 이상의 컨테이너가 있는 경우
• 파드에는 반드시 주기능을 하는 컨테이너 하나에 보조기능을 하는 컨테이너를 배치한다. 반드시 파드의 컨테이너들이 모두 각각 주기능을 하는 컨테이너가 되면 안된다.
  -> 가상화란 기술의 근본은 하나의 os에 각각의 기능을 하는 모든 서버를 올려버리면 재해에 취약해진다. 따라서 하나의 VM에 os를 올려 하나의 기능만 하게끔 만든다. 즉 격리/분리가 목표다.
  -> 하지만 os는 부팅될때 오래걸린다. 따라서 재해가 발생하면 재해복구 즉시성이 떨어지고, 고가용성을 해친다. 따라서 즉시적으로 재해복구를 하기 위해 컨테이너를 사용한다.
  -> 따라서 분리/격리가 근본적인 목표인데 파드안에 모든 컨테이너가 주기능을 가진다면 모순인 것이다.
  📗 파드 아키텍처 참조
• 파드안에 컨테이너들에게 각각 ip가 부여되는 것이 아니라 파드자체에 하나의 ip가 부여된다 = Network 공유
  
  -> 추가적으로 Volume도 공유한다

📗 사실 파드는 직접 생성할 필요없이 deployment, job과 같은 워크로드 리소스( = 컨트롤러)를 사용하여 생성한다. 파드가 상태를 추적해야 한다면, 스테이트풀셋(StatefulSet) 리소스를 고려한다.

📗 파드 개념 참조

컨트롤러 ( =워크로드 리소스)

• 파드를 컨트롤하기 위한 것

📗 워크로드 리소스 개념 참조

템플릿

쿠버네티스 클러스터의 오브젝트나 컨트롤러가 어떤 상태여야 하는지를 적용할 때는 YAML형식의 템플릿을 사용

• JSON형식으로도 작성할수 있지만 사람이 사용하기 복잡하다.

apiVersion: v1
kind: Pod
metadata:
spec: # spec은 리소스마다 아래에 들어가는 항목이 모두 다르다

-> YAML파일의 최상위에는 항상 이 항목이 들어가고, 이 형태로 작성이 된다.
-> 리스트가 아닌 이상 순서는 상관없다
-> 명사가 두개이상 나오는 경우는 두번째부터 명사 시작에는 항상 대문자 시작한다 = camel case
-> YAML파일에 정의한 작업은 api서버에 요청한다

-> kubectl api-resources를 보면 KIND라는 항목이 있는데 이 항목이 YAML파일의 kind에 들어간다. 항상 대문자로 시작하며, 단수이다.
-> YAML파일의 apiVersion에는 아무 버전이나 입력하는 것이 아니라 위의 사진처럼 리소스에 해당하는 버전을 사용한다.

< 버전 >
v1 alpha1 -> v1 alpha2 -> v1 alpha3 .....
-> v1 beta1 -> v1 beta2 -> v1 beta3 .....
-> v1 (stable) = 가장 최신 버전
📌 버전 개념 참고
💡 쿠버네티스는 3개월마다 새로운 버전이 나오면 기존의 버전은 1년뒤에 지원을 종료한다. 따라서 항상 1년동안 한번은 버전 업그레이드를 해야한다.

• 버전 예시

  api-versions # 버전 찾기 

  
  = v1-> v2beta1-> v2beta2-> v2

< metadata >

• YAML파일로 생성하고자 하는 오브젝트의 이름이나 레이블, 오브젝트의 설명이다.

1 . 템플릿 구성 예시

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mycon
    image: nginx
    ports:
    - containerPort: 80

-> 단어끝에 s, 복수형이면 아래에는 보통 리스트 형태가 온다.

kubectl create -f test.yml
# 작성한 yaml파일 실행

kubectl get pods
# 생성된 컨테이너를 담은 파드 확인 

kubectl delete -f test.yml 
# 생성된 컨테이너를 담은 파드 삭제 
# yaml파일이 지워지지는 않는다

2 . 설명 보기 (중요)

• pod를 생성하는데 필수적으로 들어가는 항목이 있고, 우리는 이것을 알고있어야 한다. 하지만 리소스마다 버전부터 시작해서 작성해야할 항목을 다 암기할 수 없다. 따라서 까먹었다면 explain 명령어를 통해 도움을 받을 수 있다.

kubectl explain pods
kubectl explain pods.apiVersion
kubectl explain pods.kind

kubectl explain pods.metadata
kubectl explain pods.metadata.name
kubectl explain pods.spec 

kubectl explain deployments
등등...

-> Deprecated라고 표시되어있는 것을 볼 수 있는데 이것은 추후에 없어질 기능이라는 것이다
-> Read-only라고 표시되어있는 것은 우리가 정의할 수 있는 것이 아닌 그저 읽기용이라는 것이다.
-> -required- 라고 표시되어있는 것은 반드시 들어가야할 항목, 필수라는 것이다.
-> kubectl explain pods.spec을 해보면 각 항목마다 자료형이 정의되어있다.
📌 예를 들어, <[]Object> 라고 표시되어 있다면 리스트, < integer > 라고 표시되어 있다면 정수를 사용해야 한다.