kubectl

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

• kubespary 같은 경우 kubectl이 같이 설치된다.

• 자동완성 기능을 활성화 시켰기 때문에 kubectl (tab)(tab)를 해주면 사용가능한 서브 커맨드를 볼 수 있다.

• 자주 사용하는 명령어
  get: 어떤 것을 확인할 때 사용, describe: 상세정보를 확인할 때 사용, create: 컨테이너, 파드, 인그레스 등등을 생성, edit: 수정할 때 사용, patch: 수정할 때 사용, replace: 리소스를 교체할 때 사용, apply: 생성과 교체 2가지 개념을 같이 가지고 있음, delete: 삭제할 떄 사용, logs: 로그를 확인할 때 사용

쿠버네티스 오브젝트 관리

명령형 커맨드

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

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

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

#              리소스 종류  이름
kubectl create deployment nginx --image nginx

-> yaml코드로 작성하지 않고 명령으로만 실행한다. 그렇기 때문에 일반적으로 사용하지 않는 방식

명령형 오브젝트 구성

명령형 오브젝트 구성에서는 kubectl 커맨드로 작업(생성, 교체 등), 선택적 플래그, 그리고 최소 하나의 파일 이름을 지정한다. 그 파일은 YAML 또는 JSON 형식으로 오브젝트의 완전한 정의를 포함해야만 한다.

• 구성 파일에 정의된 오브젝트를 생성한다.
  kubectl create -f nginx.yaml

• 두 개의 구성 파일에 정의된 오브젝트를 삭제한다.
  kubectl delete -f nginx.yaml -f redis.yaml

• 활성 동작하는 구성을 덮어씀으로써 구성 파일에 정의된 오브젝트를 업데이트한다.
  kubectl replace -f nginx.yaml

선언형 오브젝트 구성

선언형 오브젝트 구성을 사용할 경우, 사용자는 로컬에 보관된 오브젝트 구성 파일을 대상으로 작동시키지만, 사용자는 파일에서 수행 할 작업을 정의하지 않는다. 생성, 업데이트, 그리고 삭제 작업은 kubectl에 의해 오브젝트마다 자동으로 감지된다. 이를 통해 다른 오브젝트에 대해 다른 조작이 필요할 수 있는 디렉터리에서 작업할 수 있다.

• configs 디렉터리 내 모든 오브젝트 구성 파일을 처리하고 활성 오브젝트를 생성 또는 패치한다. 먼저 어떠한 변경이 이루어지게 될지 알아보기 위해 diff 하고 나서 적용할 수 있다.
  kubectl diff -f configs/
  kubectl apply -f configs/

-> 디렉터리안에 하나 이상의 yml 파일이 존재한다.

• 재귀적으로 디렉터리를 처리한다.
  kubectl diff -R -f configs/
  kubectl apply -R -f configs/

💡 지금은 명령형 오브젝트와 선언형 오브젝트가 yml 파일을 사용해서 한다는 점때문에 비슷한 것이라고 보면된다.

컨테이너 생성 및 실행

# app 생성
vagrant@kube-control1:~$ kubectl create deployment myapp --image=ghcr.io/c1t1d0s7/go-myweb:alpine
deployment.apps/myapp created

# 생성된 것 확인
kubectl get deployments
kubectl get replicasets
kubectl get pods

# 생성된 것을 확인하는데 위 내용 모두 출력
kubectl get all
or
kubectl get deployments,replicasets,pods

#  컨테이너를 외부로 노출시키기 위함, 클라이언트가 프록시를 찾아오고 프록시의 타켓은 컨테이너
-> client -> :80 Proxy -> :8080 container

vagrant@kube-control1:~$ kubectl expose deployment myapp --port=80 --protocol=TCP --target-port=8080 --name myapp-svc --type=LoadBalancer
service/myapp-svc exposed

# 실행한 서비스 확인
kubectl get services
curl 192.168.56.200

컨테이너 복제

# 수동으로 파드 개수 조정
kubectl scale deployment myapp --replicas=2

# 확인, AGE가 적은것은 새롭게 생긴 파드라 볼 수 있다.
vagrant@kube-control1:~$ kubectl get pods
NAME                     READY   STATUS    RESTARTS   AGE
myapp-549f474469-9pv46   1/1     Running   0          8s
myapp-549f474469-qwkwx   1/1     Running   0          12m

# 로드밸런스를 확인하도록 여러번 curl를 보내준다.
curl 192.168.56.200

# 제거
kubectl delete service myapp-svc
kubectl delete deployment myapp
 

• deployment를 확인하면 내가 만들것을 볼수 있고, 다른 것들은 내가 만든 것은 아니지만 자동으로 만들어짐
• 서비스를 확인하고 접속이 되는 것을 확인
• 로드밸런스 되는 모습을 확인

🔎 deployment가 replacasets에 신호를 보내면 여기에서 지정한 개수만큼 pods를 만든다.
🔎 deployment가 replacasets에 선언해둔 사이즈가 있기 때문에 파드를 지워도 곧바로 새로운 파드를 생성한다.

nginx 웹서버 만들기

kubectl create deployment myweb --image=nginx:latest
kubectl scale deployment myweb --replicas=4
kubectl get all

kubectl expose deployment myweb --port=80 --protocol=TCP --target-port=80 --name myweb-svc --type=LoadBalancer
kubectl get services

curl 192.168.56.200

• 클러스터 내부에서는 통신이 되지만 외부로는 안되기 때문에 서비스라는 리소스를 만든다. 포트 80은 외부에서 접근할때 사용하는 포트, 이 서비스가 연결되는 파드들의 포트가 target 포트이다. nginx는 default로 80 port로 정해져있기 때문에 target-port를 80으로 지정해줘야 한다.
  nginx 이미지 상세내용

vi 편집기가 아닌 vs code로 가상머신 내에 파일 추가하는 방법

vagarant-config 내용 복사 -> vs code 들어가서 remote ssh 다운 -> 왼쪽 밑에 초록색 버튼 클릭 -> 호스트와 연결 -> configure ssh hosts -> 복사한 내용을 아래와 같이 수정후 이어 붙이기 hostname 각 노드 localhost_ip, port 22 -> 저장 후 다시 왼쪽 밑에 초록색 버튼 클릭 -> 호스트와 연결 -> 하면 추가한 호스트들이 나타나고 연결한 호스트를 클릭해주면 vs code에서 연결이 가능하다.

파드

파드(Pod) 는 쿠버네티스에서 생성하고 관리할 수 있는 배포 가능한 가장 작은 컴퓨팅 단위이다. 파드는 하나 이상의 컨테이너의 그룹이다.

일반적으로 싱글톤(singleton) 파드를 포함하여 파드를 직접 만들 필요가 없다. 대신, 디플로이먼트(Deployment) 또는 잡(Job)과 같은 워크로드 리소스를 사용하여 생성한다.
있는 경우

• 파드에는 반드시 주기능을 하는 컨테이너 하나에 보조기능을 하는 컨테이너를 배치한다. 반드시 파드의 컨테이너들이 모두 각각 주기능을 하는 컨테이너가 되면 안된다.

-> 하나의 하드웨어의 os에 각각의 기능을 하는 모든 프로세스를 올리면 하나가 고장났을때 모두 사용할 수 없게 된다.(Single Point Of Failure) 따라서 논리적으로 app을 분리하기위해 가상화를 사용하고 하나의 HW에 여러 VM을 올려 각각 다르게 작동하도록 한다. 즉 격리/분리가 목표다.

-> 하지만 os를 각각에 VM에 띄워야 하기 때문에 너무 비효율적이여서 하나의 os위에 app을 띄우는데 여기에서 격리된 공간인 컨테이너를 만들어 주는 방식으로 전환 되었다.

💡 app의 분리/격리가 근본적인 목표인데 한 파드 안에 모든 컨테이너가 주기능을 가진다면 말이 안된다. 따라서 주기능은 1개, 나머지는 보조기능을 가진 컨테이너를 생성하는 것이다.

• 단일 컨테이너를 실행하는 파드

• 함께 작동해야 하는 여러 컨테이너를 실행하는 파드.
  파드는 밀접하게 결합되어 있고 리소스를 공유해야 하는 함께 배치된 여러 개의 컨테이너로 구성된 애플리케이션을 캡슐화할 수 있다. 이런 함께 배치된 컨테이너는 하나의 결합된 서비스 단위를 형성한다. 예를 들어, 하나의 컨테이너는 공유 볼륨에 저장된 데이터를 퍼블릭에 제공하는 반면, 별도의 사이드카 컨테이너는 해당 파일을 새로 고치거나 업데이트한다. 파드는 이러한 컨테이너, 스토리지 리소스, 임시 네트워크 ID를 단일 단위로 함께 래핑한다.
  📢참고자료 파드 복합 컨테이너의 패턴

파드가 여러 컨테이너를 관리하는 방법

파드는 응집력있는 서비스 단위를 형성하는 여러 협력 프로세스(컨테이너)를 지원하도록 설계되었다. 파드의 컨테이너는 클러스터의 동일한 물리 또는 가상 머신에서 자동으로 같은 위치에 배치되고 함께 스케줄된다. 컨테이너는 리소스와 의존성을 공유하고, 서로 통신하고, 종료 시기와 방법을 조정할 수 있다.

예를 들어, 다음 다이어그램에서와 같이 공유 볼륨의 파일에 대한 웹 서버 역할을 하는 컨테이너와, 원격 소스에서 해당 파일을 업데이트하는 별도의 "사이드카" 컨테이너가 있을 수 있다.

일부 파드에는 앱 컨테이너 뿐만 아니라 초기화 컨테이너를 갖고 있다. 초기화 컨테이너는 앱 컨테이너가 시작되기 전에 실행되고 완료된다. 또한 볼륨 컨테이너도 무조건 존재하는 것이 아니여서 없어도 된다.

• 파드안에 컨테이너가 여러개여도 파드 자체는 하나의 IP주소만 가진다. 볼륨도 공유하고 네트워크도 공유한다는 것이다.

main: web sercer / second: file puller

템플릿(오브젝트)

쿠버네티스 클러스터의 오브젝트나 컨트롤러가 어떤 상태여야 하는지를 적용할 때는 YAML 형식의 템플릿을 사용한다. 템플릿의 내용을 표현하는 YMAL은 JSON과 비교했을 때 간결하며, 주석도 지원하므로 가독성이 좋다.

• 오브젝트를 정의해놓은 파일을 manifest라고도 함

• 템플릿의 기본 형식, 간혹 spec이 아닌 다른것이 나타날 수도 있음

• apiVersion: 사용하려는 API 버전 명시

• kind: 어떤 종류의 오브젝트 혹은 컨트롤러에 작업인지 명시

• metadata: 메타데이터를 설정, 해당 오브젝트의 이름이나 레이블 등을 설정, 오브젝트를 유일하게 구분지어 줄 데이터

• spec: 파드가 어떤 컨테이너를 갖고 실행하며, 실행할 때 어떻게 동작해야 할지 명시

파드 사용

#키워드가 2개이면 두번쨰 단어의 시작은 대문자
vi pod.yml

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

kubectl create -f pod.yml
kubectl get pods

• kubectl explain pods: pod를 생성하는데 필수적으로 들어가는 항목이 있지만 리소스마다 버전부터 시작해서 해당 내용이 많다. 따라서 상세내용을 explain 명령어를 통해 확인 가능하다.
  
• kubectl explain pods.metadata.name: pods 내부에서 일부 정보를 자세히 볼 수 있다.
• -required 라고 표시되어있는 것은 반드시 들어가야할 항목, 필수라는 것이다.
• kubectl explain pods.spec을 해보면 각 항목마다 자료형이 정의되어있다.
  예를 들어, < Object > 라고 표시되어 있다면 리스트, < integer > 라고 표시되어 있다면 정수를 사용해야 한다.
• status는 읽기 전용이다.(Read-only이기 때문에)

API 버전 규칙

API 버전의 차이는 수준의 안정성과 지원의 차이를 나타낸다.

순서
alpha -> beta -> stable

• 알파(Alpha):

  • 버전 이름에 alpha가 포함된다(예: v1alpha1).

  • 버그가 있을 수도 있다. 이 기능을 활성화하면 버그에 노출될 수 있다. 기본적으로 비활성화되어 있다.

  • 기능에 대한 기술 지원이 언제든 공지 없이 중단될 수 있다.

  • 다음 소프트웨어를 릴리스할 때 공지 없이 API의 호환성이 깨지는 방식으로 변경될 수 있다.

  • 버그에 대한 위험이 높고 장기간 지원되지 않으므로 단기간 테스트 용도의 클러스터에서만 사용하기를 권장한다.

• 베타(Beta):

  • 버전 이름에 beta가 포함된다(예: v2beta3).

  • 코드가 잘 테스트 되었다. 이 기능을 활성화해도 안전하다. 기본적으로 활성화되어 있다.

  • 구체적인 내용이 바뀔 수는 있지만, 전반적인 기능에 대한 기술 지원이 중단되지 않는다.

  • 오브젝트에 대한 스키마나 문법이 다음 베타 또는 안정화 릴리스에서 호환되지 않는 방식으로 바뀔 수도 있다. 이런 경우, 다음 버전으로 이관할 수 있는 가이드가 제공된다. 스키마 변경은 API 오브젝트의 삭제, 편집 또는 재생성이 필요할 수도 있다. 편집 절차는 좀 생각해볼 필요가 있다. 이 기능에 의존하고 있는 애플리케이션은 다운타임이 필요할 수도 있다.

  • 이 소프트웨어는 프로덕션 용도로 권장하지 않는다. 이후 여러 버전에서 호환되지 않는 변경 사항이 적용될 수 있다. 복수의 클러스터를 가지고 있어서 독립적으로 업그레이드할 수 있다면, 이런 제약에서 벗어날 수도 있다.

• 안정화(Stable):

  • 버전 이름이 vX이고 X 는 정수다. ex) v1, v2

  • 안정화 버전의 기능은 이후 여러 버전에 걸쳐서 소프트웨어 릴리스에 포함된다.

# 버전 찾기 
kubectl api-versions 

# 리소스 내용 보기
kubectl api-resources