[kubernetes] 쿠버네티스 정의 방법 및 기본 명령어 호출

어떤 어플리케이션을 얼마나 어디에 어떤 방식으로 배포할지는 yaml 파일로 정의하며

해당 파일을 kubectl로 적용 요청 하면 RestAPI 를 통해 클러스터에 전달 된다.

yaml 파일에는 오브젝트를 정의하게 되는데 오브젝트 몇가지만 설명하면 아래와 같다.

오브젝트	설명
Pod	어떤 어플리케이션을
ReplicaSet	얼마나
Node, Namespace	어디에
Deployment	어떤 방식으로 배포할것인가
Service,Endpoints	트래픽을 어떻게 로드밸런싱 할것인가

이제 실제 yaml 파일을 보면서 파악하도록 하며 구조는 아래와 같다!

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
   metchLabels:
     app: nginx
  replcas: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
status:
...

apiVersion은 오브젝트를 생성할때 사용하는 API 버전이며, kind는 생성하고자 하는 오브젝트 종류로 현재 배포 방식에 대한 정의임을 알 수 있다.

metadata는 오브젝트를 구분 지을수 있는 정보이며, spec 필드는 사용자가 원하는 오브젝트 상태이다.

status의 경우 클러스터 생성후 쿠버네티스가 현재 실행중인 오브젝트의 상태 정보를 추가해주는 정보로

클러스터의 ControllerManeger가 spec과 status 정보를 비교하며 동일하게 유지 될 수 있도록 동작하며 상태도 업데이트 한다.

이제 기본 명령어를 호출해보는 실습을 진행해보자!

1. 클러스터 오브젝트 목록 조회

$ kubectl api-resources
NAME                              SHORTNAMES   APIVERSION                             NAMESPACED   KIND
pods                              po           v1                                     true         Pod
...

위와 같이 입력하면 Name 풀네임, ShortNames 축약어,  APIVersion API 버전, Namespaces 네임스페이스(논리적으로 구분하는 단위로 실무에서 팀단위로 리소스 적용시 사용하기도 한다.)로 구분 될 수 있는지 여부 Kind 오브젝트 종류를 확인 할 수 있다.

2. 오브젝트 설명 보기

$ 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	<Object>
     Standard object's metadata. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

   spec	<Object>
     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	<Object>
     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

오브젝트 설명과 정의 가능한 속성이 나온다.

만약 spec 하위 속성이 궁금하다면 아래와 같이 '.'  뒤에 속성을 추가하여 확인 할 수 있다.

$ kubectl explain pod.spec
KIND:     Pod
VERSION:  v1

RESOURCE: spec <Object>

DESCRIPTION:
     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

     PodSpec is a description of a pod.

FIELDS:
   activeDeadlineSeconds	<integer>
     Optional duration in seconds the pod may be active on the node relative to
     StartTime before the system will actively try to mark it failed and kill
     associated containers. Value must be a positive integer.

   affinity	<Object>
     If specified, the pod's scheduling constraints

   automountServiceAccountToken	<boolean>
     AutomountServiceAccountToken indicates whether a service account token
     should be automatically mounted.

   containers	<[]Object> -required-
     List of containers belonging to the pod. Containers cannot currently be
     added or removed. There must be at least one container in a Pod. Cannot be
     updated.

3. 클러스터 노드 목록 조회

$ kubectl get nodes
NAME                                           STATUS   ROLES    AGE    VERSION
gke-corin-cluster-default-pool-123             Ready    <none>   114m   v1.25.7-gke.1000
gke-corin-cluster-default-pool-456             Ready    <none>   114m   v1.25.7-gke.1000
gke-corin-cluster-default-pool-789             Ready    <none>   114m   v1.25.7-gke.1000

클러스터 생성시 노드 3개 생성하였으므로 3개가 나오는것을 확인할 수 있다.

4. 오브젝트 생성 및 변경

해당 실습을 위해 yaml 을 생성한다.

# nginx-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
        resources:
          limits:
            memory: "64Mi"
            cpu: "50m"

이제 적용을 위해 아래와 같이 입력한다.

$ kubectl apply -f nginx-deployment.yaml
deployment.apps/nginx-deployment created

5. 실행중인 Pod 목록 조회

위에 deployment 오브젝트를 생성하였으니 아래와 같이 파드를 조회해보면 replica 설정한대로 2개가 생성되어 있다.

$ kubectl get pods
NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-64779c7579-fsn9q   1/1     Running   0          90s
nginx-deployment-64779c7579-gg856   1/1     Running   0          90s

6. 이제 어플리케이션 배포한 파드 개수를 조정해보도록 하자!

아래와 같이 scale 명령어를 통해 조정 가능하며 명령어 호출시 pod 가 3개 된것을 볼 수 있으나 Ready 가 아직 안되었으며 조금만 기다렸다가 조회하면

$ kubectl scale -f 06_deployment.yaml --replicas=3
deployment.apps/nginx-deployment scaled
$ kubectl get pods
NAME                                READY   STATUS              RESTARTS   AGE
nginx-deployment-64779c7579-fsn9q   1/1     Running             0          2m43s
nginx-deployment-64779c7579-gg856   1/1     Running             0          2m43s
nginx-deployment-64779c7579-m7f8w   0/1     ContainerCreating   0          3s

아래와 같이 3개 파드가 정상적으로 준비 된것을 볼 수 있다!

$ kubectl get pods
NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-64779c7579-fsn9q   1/1     Running   0          2m59s
nginx-deployment-64779c7579-gg856   1/1     Running   0          2m59s
nginx-deployment-64779c7579-m7f8w   1/1     Running   0          19s

 

7. 이제 현재 오브젝트 설정과 입력한 파일의 차이 분석해보자!

아래와 같이 입력하면 replia 수 변경된 부분을 감지하며 scale 명령어로 변경시 파일 수정이 따로 안되는것을 알 수 있다.

$ kubectl diff -f nginx-deployment.yaml
...
-  replicas: 3
+  replicas: 2
   revisionHistoryLimit: 10
   selector:
     matchLabels:

8. 오브젝트 spec을 편집하는 또 다른 방법인 edit로 편집해보도록 하자!

우선 deployment 명을 조회한다.

$ kubectl get deployment
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3/3     3            3           11m

spec을 4개로 수정하기 위해 아래와 같이 edit 명령어를 사용하며 spec 의 replica 를 3 > 4 로 수정한다.

$ kubectl edit deployment nginx-deployment
apiVersion: apps/v1
kind: Deployment
...
spec:
  progressDeadlineSeconds: 600
  replicas: 4
...
status:
  availableReplicas: 3
  conditions:
...
:wq!
deployment.apps/nginx-deployment edited

수정 완료 하면 아래와 같이 파드가 4개 조회 된다.

$ kubectl get pods
NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-64779c7579-2bvvs   1/1     Running   0          3m18s
nginx-deployment-64779c7579-fsn9q   1/1     Running   0          16m
nginx-deployment-64779c7579-gg856   1/1     Running   0          16m
nginx-deployment-64779c7579-m7f8w   1/1     Running   0          13m

그러나 이는 문서화 되지 않기 때문에 yaml 을 직접 replica를 4 > 5 로 수정 하도록 한다.

$ kubectl apply -f 06_deployment.yaml
deployment.apps/nginx-deployment configured

파드 조회시 5개가 나오며 diff 로 확인하면 파일과 현재 상태가 다른 부분이 없기에 아무 텍스트도 나오지 않는것을 확인 할 수 있다.

$ kubectl get pods
NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-64779c7579-2bvvs   1/1     Running   0          4m57s
nginx-deployment-64779c7579-cv8d7   1/1     Running   0          19s
nginx-deployment-64779c7579-fsn9q   1/1     Running   0          18m
nginx-deployment-64779c7579-gg856   1/1     Running   0          18m
nginx-deployment-64779c7579-m7f8w   1/1     Running   0          15m
$ kubectl diff -f 06_deployment.yaml
$

9. 로컬 포드를 파드에서 실행중인 컨테이너 포트로 포워딩을 해보도록 하자!

우선 우리가 실행한 파드명 하나를 복사한뒤, 아래와 같이 로컬 포트 8080을 nginx 컨테이너 포트인 80포트로 연결하도록 한다.

$ kubectl port-forward pod/nginx-deployment-64779c7579-2bvvs 8080:80
Forwarding from 127.0.0.1:8080 -> 80
Forwarding from [::1]:8080 -> 80

콘솔 하나 더 띄워서 curl을 통해 nginx 호출을 해보면 정상적으로 연결 됨을 확인 할 수 있으며 이는 영구적인 부분이 아니라 위 창을 닫거나 ctrl+c 로 나갈시 연결이 해제 되므로 테스트 할 때 용이하게 쓰인다.

$ curl localhost:8080
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

 

10. 이제 실행중인 파드 로그 확인 해보도록 하자!

우선 로그 확인할 파드의 명을 복사한뒤 pod/<pod 명> 을 입력하여 로그 확인 가능한 상태로 둔다.

$ kubectl logs pod/nginx-deployment-64779c7579-2bvvs -f

포트포워딩 한 상태로 호출하면

$ curl localhost:8080

아래와 같이 로그 확인 가능하다. (-f 는 실시간이다.)

$ kubectl logs pod/nginx-deployment-64779c7579-2bvvs -f
2023/05/06 14:24:49 [error] 7#7: *20 open() "/usr/share/nginx/html/verssion" failed (2: No such file or directory), client: 127.0.0.1, server: localhost, request: "GET /verssion HTTP/1.1", host: "localhost:8080"
127.0.0.1 - - [06/May/2023:14:24:49 +0000] "GET /verssion HTTP/1.1" 404 169 "-" "curl/7.64.1" "-"

끝!