ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • Kubernetes (K8S): Object Config File(구성파일: yaml)
    공부합시다!/Kubernetes 2022. 6. 21. 06:32
    728x90

    최근 들어 Infra를 Code 형태로 관리하는 IaC(Infrastructure As Code)가 각광을 받고 있다.

    Infra를 Source 코드화 해서 사용을 하면 대량 배포 시 멱등성을 확보할 수 있고 배포 후 변경관리가 용이하다는 장점을 갖기 때문이다.

    K8S에서는 Object를 배포, 삭제, 변경하거나 Object의 정보확인 시 개별 명령어를 각각 입력할 필요없이 설정 파일을 명령으로 실행하면 대단히 편리하다.

    K8S 역시 명령어보다는 설정 파일의 형태로 관리하는 것을 적극 권장한다.

    https://github.com/kubernetes/examples/tree/master/guestbook/all-in-one

    참조할 예제 파일들이 존재

     

    1. Field

     1.1. apiVersion

       1.1.1. Object를 생성하기 위해서 사용하는 Kubernete API 버젼

       1.1.2. Pod(po): v1

       1.1.3. Service(svc): v1

       1.1.4. Deployment(deploy): apps/v1

       1.1.5. Namespace: v1

       1.1.6. ReplicaSet(rs): apps/v1

       # kubectl api-resources 확인 가능

     

     1.2. kind: 생성하려는 Object 종류

      1.2.1. object: Namespace, Pod, Service, Deployment, DaemonSet, Label, ReplicaSet 등

       1.2.1.1. 클러스터의 상태를 나타내는 단위(entities)입니다.

       1.2.1.2.  “의도를 담은 레코드”입니다. 생성된 클러스터는 그 의도대로 존재할 수 있도록 최선을 다함.

       1.2.1.3. 이를 클러스터의 “의도한 상태(desired state)“ 지칭.

       1.2.1.4. 쿠버네티스는 항상 오브젝트의 “현재 상태”를 “의도한 상태”와 동일하게 만들게끔 작동.

       1.2.1.5. 이때 의도한 상태란 다음과 같습니다.

    • 어떤 파드(컨테이너)들이 어느 노드에서 동작(running) 중인지
    • 컨테이너들의 논리 그룹과 매핑된 IP 엔드포인트
    • 동작 중인 컨테이너 레플리카(replicas)의 개수

     1.3. metadata

      1.3.1. Object를 유일하게 구분할 수 있는 Data

      1.3.2. 이름 문자열, UID, 선택적인 Namespace

     

     1.4. spec

      1.4.1. Object에 대해서 의도한 상태

     

     1.5. 동작구조

      1.5.1. 구성 파일은 Cluster에 적용되기 전 Version Controller에 저장

      1.5.2. 구성 파일을 저장함으로서 필요시 구성의 변경사항 Rollback 가능

      1.5.3. Cluster의 재생성 및 복원에 사용

     

    2. Test

     2.1. 테스트 구성파일 작성

    # vi nginx.yml
    
    apiVersion: v1
    kind: Service
    metadata:
      name: nginx-svc
      labels:
        app: web
        tier: frontend
        role: master
    spec:
    #  type: NodePort
      ports:
      - port: 80
        targetPort: 80
    #    nodePort: 31000
      selector:
        app: web
        tier: frontend
        role: master
    ---
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: nginx-dep
    spec:
      selector:
        matchLabels:
          app: web
          tire: frontend
          role: master
      replicas: 1
      template:
        metadata:
          labels:
            app: web
            tire: frontend
            role: master
        spec:
          containers:
          - name: master
            image: nginx
            resources:
              requests:
                cpu: 100m
                memory: 100Mi
            ports:
            - containerPort: 80

     

     2.2. 적용 및 svc, deployment 확인

    # kubectl apply -f nginx.yml
    # kubectl get svc
    # kubectl get deploy
    # kubectl get pod

     

     2.3. service type을 NodePort로 변경, nodePort: 31000으로 수정

      2.3.1. 쿠버네티스 컨트롤 플레인은 포트 범위에서 할당한다(기본값: 30000-32767)

     

     2.4. 적용 전 diff 명령어를 이용하여 Version 관리가 되고 있음을 확인합니다.

    # kubectl diff -f nginx.yml

     

     2.5. 적용 후 변경 사항을 확인 합니다.

      2.5.1. service port type과 port가 변경된 것 이외에는 아무런 변경사항이 없음을 확인합니다.

     

    3. yml 파일을 통한 구성 확인

     3.1. 생성되는 Object 정보 조회

    # kubectl get -f nginx.yml
    # kubectl describe -f nginx.yml

     

    3.2. 생성되는 Object에 대한 자세한 정보 조회

     

    여러분들은 replicas도 변경해서 테스트 해보시기 바랍니다.

     

    Have a nice day!

    728x90
Designed by Tistory.