Use kubectl to see a list of Pods in a cluster
kubectl 명령어를 통해서 쿠버네티스를 관리하는 일련의 과정은 어떻게 이루어지는 것일까?
클러스터에 대한 권한을 가지고 있는 관리자가 kubectl 명령어를 치면, kubectl은 이를 command line 명령어에서 API call로 변경한다. 이는 HTTPS를 통해 쿠버네티스 제어 영역의 kube-apiserver로 보내진다. kube-apiserver는 해당 request를 etcd에 쿼리를 던짐으로서 처리한다. 처리된 결과는 다시 kube-apiserver를 통해서 다시 kubectl에게 전달되고, 이 결과가 관리자에게 command prompt를 통해 전달된다.
Kubectl must be configured first
kubectl을 사용하기 전에 먼저 인증이 필요하다. 해당 인증파일은 $HOME/.kube/config 아래에 있다. GKE를 사용하는 경우, 해당 인증은 GKE가 제공해준다. 이 인증 파일 안에는 타켓 클러스터 이름과 클러스터에 대한 인증 정보가 포함되어 있다. 현재의 인증 정보를 확인하고 싶은 경우 kubectl config view를 사용하면 된다.
Connecting to a Google Kubernetes Engine cluster
kubectl로 GKE와 통신하기 위해서는 아래와 같이 인증 정보를 설정해줘야 한다. 당연히, kubectl과 gcloud cli가 둘 다 설치된 경우에 해당 커멘드를 설정해줄 수 있다.
그런데 왜 kubectl 커멘드가 아니라 gcloud 커멘드를 사용하는 것일까? 그 이유는 당연하다! kubectl 커멘드를 사용하기 위해서는 우선 인증 정보가 필요하기 때문이다. 따라서 gcloud get-credentials를 사용해 GKE 클러스터에 필요한 인증을 받을 수 있게 해야 한다. 즉, 쉽게 정리하자면 1) kubectl 커멘드를 사용하기 위해서는 쿠버네티스 클러스터에 대한 인증 정보가 필요하고, 2) 그 인증 정보는 GKE가 제공해주기 때문에 gcloud 커멘드를 사용해야 한다.
위의 명령어를 통해서 GKE 클러스터와 연결할 수 있다. 연결한 후에는 kubectl 커멘드를 사용할 수 있다. kubectl 커멘드는 이미 존재하는 클러스터의 내부적인 상태를 변경하기 위한 명령어이기 때문이다. 하지만 새롭게 클러스터를 만들거나 이미 존재하는 클러스터의 형태를 바꿀 수는 없다. 이 경우에는 gcloud 명령어를 사용해야 한다.
The kubectl command systax has several parts
이제 kubectl 커멘드를 사용하는 법을 알아보자.
command: 원하는 action(get, describe, logs…)등을 정의한다.type: 어떤 쿠버네티스 객체(pods, deployment, nodes)에 action을 취하고 싶은 지를 정의한다.name: 해당 type에 존재하는 객체 중 어떤 특정 객체를 가져오고 싶은 지를 명시한다. 필수적인 것은 아니다. 특히,kubectl get pods처럼 리스트 전체를 가져오고 싶은 경우에는 명시할 필요가 없다.flags: 어떤 명령어는 flag를 지정해주기도 한다. 해당 명령어는 특정한 label이 붙은 쿠버네티스 객체를 보게 만들어주기도 하고, -o wide와 같은 옵션을 통해 기존의 command가 보여주는 것보다 더 자세한 내용을 출력해줘서 보여주기도 한다.
Deployments declare the state of Pods
배포는 파드의 원하는 상태(desired state)를 지정한다. 예를 들자면, “5개의 nginx 파드가 반드시 실행 중인 상태”같은 것을 지정할 수 있다.
- 배포는 새로운 업데이트를 파드에 적용한다. 예를 들어, 새로운 컨테이너 이미지를 적용한 경우 새
ReplicaSet이 생성되고 오래된 파드는 오래된ReplicaSet에서 제거된다. - 만약 업데이트된 파드가 안정적이지 않다면, 배포는 기존 버전으로 롤백할 수 있다.
- yaml 파일을 수정하거나 커멘드를 사용해서 pod의 스케일을 확장할 수 있다.
- 배포는 stateless 어플리케이션을 위해 만들어졌다. stateless 어플리케이션을 정보를 저장하거나 관리하지 않는다. 대표적인 예는 web frontend이다. backend를 위해서는 배포가 아닌 다른 객체를 사용해야 한다.
배포는 원하는 상태가 선언적으로 정의된 configuration 파일을 통해 생성된다. 해당 파일을 통해 쿠버네티스의 제어 영역에 제출하면 배포 controller가 생성되는데, 이 컨트롤러는 원하는 상태를 실제로 만들고, 그 상태를 유지하는 역할을 한다. 컨트롤러는 쿠버네티스에 의해 통제되는 loop 프로세스로, 클러스터의 상태를 감지하고, 원하는 상태와 비교하고, 원하는 상태가 되도록 변경하는 역할을 한다.
이 프로세스 동안 ReplicaSet이 생성되는데, 이는 특정한 숫자의 파드가 항상 돌아갈 것을 보장하는 컨트롤러이다. 배포는 파드의 상태를 정의하는 high-level 컨트롤러이고, 그 아래에 ReplicaSet 컨트롤러가 있어 특정한 버전의 파드를 관리하고 유지하는 역할을 한다. ReplicaSet 컨트롤러는 yaml 파일에서 replicas를 통해서 지정할 수 있다.
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 3
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: my-app
image: gcr.io/demo/my-app:1.0
ports:
- containerPort: 8080Deployment has thre different lifecycle states
모든 배포는 3개의 라이프사이클 상태를 가지고 있다.
progressing state: task가 실행됐다는 것을 나타낸다. 새로운 ReplicaSet을 생성하거나, 스케일 업 또는 다운을 하는 것이다.complete state: 오래된 ReplicaSet은 실행 중이지 않으며, 새로운 ReplicaSet으로 업데이트가 완료되어 실행 중이라는 것을 의미한다.failed state: 새로운 ReplicaSet 생성이 완료될 수 없음을 나타낸다. 이는 쿠버네티스가 새로운 이미지를 pull 할 수 없는 상황이나, 명령을 실행하기 위해 충분한 리소스가 없었을 때 등등에서 나타날 수 있다. 명령이 실패하면 기존 버전으로 롤백해야 하므로, 이를 위해서 yaml 파일을 버전 관리를 통해 관리하는 것이 좋다.
