Kubernetes-Masterclass | Application Deploy Concept & AWS RDS

Kubernetes Application Deploy 개념 개요

• Kubernetes Secrets
• 목적: 민감한 데이터를 암호화된 형식으로 저장 및 관리.
• 사용 사례: DB 비밀번호, API 키 등.
• 실습: Secrets를 생성하고 이를 배포에 환경 변수로 적용하여 MySQL 루트 비밀번호 설정.

• 초기화 컨테이너 (Init Containers)
• 목적: 메인 애플리케이션 컨테이너가 시작되기 전에 필요한 설정이나 준비 작업을 수행.
• 사용 사례: MySQL 서비스가 준비될 때까지 대기.
• 실습: 초기화 컨테이너를 구현하여 MySQL이 완전히 시작된 후 애플리케이션이 실행되도록 설정.

• 라이브니스 및 리드니스 프로브 (Liveness and Readiness Probes)
• 목적: 컨테이너의 상태를 체크하여, 문제 발생 시 재시작하거나 트래픽을 제어.
• 사용 사례: 애플리케이션의 상태를 지속적으로 모니터링.
• 실습: 라이브니스 및 리드니스 프로브를 설정하여 트래픽이 정상적으로 동작하는 컨테이너에만 전달되도록 설정.

• 요청 및 제한 (Requests and Limits)
• 목적: Kubernetes 클러스터 내 리소스 사용을 관리 및 제어.
• 사용 사례: 각 애플리케이션 포트가 사용할 CPU 및 메모리 양을 설정.
• 실습: 요청(requests) 및 제한(limits)을 설정하여 리소스 사용을 최적화.

• 네임스페이스 (Namespaces)
• 목적: Kubernetes 클러스터 내 리소스를 논리적으로 분리하여 관리.
• 사용 사례: 개발(dev), QA, 스테이징(staging) 환경을 분리하여 관리.
• 실습: 네임스페이스를 생성하고, 각각의 네임스페이스에 동일한 애플리케이션의 다른 버전을 배포하여 환경을 분리.

Kubernets Secrets

• "secret"이고 apiVersion은 "core/v1"

• metadata에는 이름과 레이블

• spec 대신 data를 사용하며, data는 키-값 쌍으로 구성된다.

apiVersion: v1
kind: Secret
metadata:
  name: mysql-db-password
data:
  db-password: ZGJwYXNzd29yZDEx
  db-username: 
  db-host: 
type: Opaque

Kubernetes Init Containers

• Init containers는 일반 애플리케이션 컨테이너가 실행되기 전에 Pod 내부에서 실행되는 특별한 컨테이너

• 앱 컨테이너가 시작되기 전에 필요한 초기 설정이나 유틸리티 작업을 수행

• 특징:
• 여러 개의 init containers를 순서대로 설정할 수 있다.
• 각 init container는 성공적으로 완료되어야만 다음 init container가 실행된다.
• 모든 init containers가 완료되면 주 애플리케이션 컨테이너가 시작된다.
• init container가 실패하면, Kubernetes는 이 컨테이너가 성공할 때까지 Pod를 재시작한다. 단, Pod의 재시작 정책이 "never"로 설정된 경우 재시작하지 않는다.

• 사용 사례
• 유틸리티나 설정 스크립트가 포함된 컨테이너.
• 애플리케이션 컨테이너가 실행되기 전에 필요한 준비 작업 수행.

spec:
      initContainers:
        - name: init-db
          image: busybox:1.31
          command: ['sh', '-c', 'echo -e "Checking for the availability of MySQL Server deployment"; while ! nc -z mysql 3306; do sleep 1; printf "-"; done; echo -e "  >> MySQL DB Server has started";']  

# kubectl apply 했을 때 Init:0/1로 시작
usermgmt-microservice-7956c79978-mwjqh   0/1     Init:0/1   0          29s

# Init db 커맨드 실행 후
usermgmt-microservice-7956c79978-mwjqh   1/1     Running   0          81s

# kubectl describe pod
Events:
  Type    Reason     Age    From               Message
  ----    ------     ----   ----               -------
  Normal  Scheduled  2m17s  default-scheduler  Successfully assigned default/usermgmt-microservice-7956c79978-mwjqh to ip-192-168-2-91.ap-northeast-2.compute.internal
  Normal  Pulling    2m17s  kubelet            Pulling image "busybox:1.31"
  Normal  Pulled     2m13s  kubelet            Successfully pulled image "busybox:1.31" in 3.758s (3.758s including waiting). Image size: 764556 bytes.
  Normal  Created    2m13s  kubelet            Created container init-db
  Normal  Started    2m13s  kubelet            Started container init-db
  Normal  Pulled     102s   kubelet            Container image "stacksimplify/kube-usermanagement-microservice:1.0.0" already present on machine
  Normal  Created    102s   kubelet            Created container usermgmt-restapp
  Normal  Started    102s   kubelet            Started container usermgmt-restapp

Kubernetes Liveness & Readiness Probes

1. Liveness Probe
• 목적: 컨테이너가 정상적으로 실행되고 있는지 확인한다.
• 사용 사례: 애플리케이션이 데드락 상태에 빠졌거나, 정상적인 동작을 하지 않는 경우, 컨테이너를 자동으로 재시작하여 문제를 해결한다.
• 동작: liveness probe가 실패하면 Kubernetes는 해당 컨테이너를 재시작한다.

2. Readiness Probe
• 목적: 컨테이너가 트래픽을 수용할 준비가 되었는지 확인한다.
• 사용 사례: 애플리케이션이 완전히 시작되기 전에 트래픽을 받지 않도록 하며, readiness probe가 성공하면 컨테이너가 서비스 로드 밸런서에 추가되어 트래픽을 받을 수 있다.
• 동작: readiness probe가 실패하면 컨테이너는 서비스 로드 밸런서에서 제거된다.

3. Startup Probe
• 목적: 컨테이너 애플리케이션이 시작되었는지 확인한다.
• 사용 사례: 느리게 시작되는 컨테이너에 대해 liveness 및 readiness probe의 간섭을 방지하고, 컨테이너가 실행되기 전에 종료되지 않도록 한다.
• 동작: startup probe가 성공할 때까지 liveness 및 readiness probes는 비활성화된다.

• Probe 정의 옵션
• 명령어 (Command): 쉘 명령어를 사용하여 상태를 체크한다. 예: netcat -z localhost 8095.
• HTTP GET 요청: 애플리케이션의 헬스 체크 페이지를 HTTP GET 요청으로 확인한다.
• TCP 소켓 연결: 특정 포트가 열려 있는지 확인한다. 예: 포트 8095.

Create Kubernetes Liveness & Readiness Probes

sh -c "ncat -z localhost 8095

• 일반적으로 initailDelaySeconds는 컨테이너가 시작된 후 liveness 또는 readiness probes가 시작되기 전까지의 시간이다. 컨테이너가 시작된 후 readiness 또는 liveness probes가 트리거되기까지의 시간 차이다. 이는 컨테이너가 애플리케이션을 정리할 시간을 주기 위해 설정된다. 일반적으로 10초, 30초, 50초 또는 60초를 설정한다. 기본값은 0초이며, 최소값도 0초다.

• 하지만 실패하지 않도록 10초에서 30초 사이로 설정하는 것이 좋다.

• 실습에서는 60초로 설정하여 60초가 완료될 때까지 파드가 준비 상태로 보이지 않도록 하겠다.

 				livenessProbe:
            exec:
              command: 
                - /bin/sh
                - -c 
                - nc -z localhost 8095
            initialDelaySeconds: 60
            periodSeconds: 10
          readinessProbe:
            httpGet:
              path: /usermgmt/health-status
              port: 8095
            initialDelaySeconds: 60
            periodSeconds: 10

Configure Liveness, Readiness and Startup Probes

This page shows how to configure liveness, readiness and startup probes for containers. For more information about probes, see Liveness, Readiness and Startup Probes The kubelet uses liveness probes to know when to restart a container. For example, liveness probes could catch a deadlock, where an application is running, but unable to make progress. Restarting a container in such a state can help to make the application more available despite bugs.

https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

• initialDelaySeconds: 컨테이너가 시작된 후, 스타트업, 라이브니스 또는 레디니스 프로브가 시작되기 전에 대기할 초 수입니다. 스타트업 프로브가 정의된 경우, 라이브니스 및 레디니스 프로브의 지연 시간은 스타트업 프로브가 성공할 때까지 시작되지 않습니다. periodSeconds의 값이 initialDelaySeconds보다 크면 initialDelaySeconds는 무시됩니다. 기본값은 0초입니다. 최소값은 0입니다.

• periodSeconds: 프로브를 수행할 주기(초)입니다. 기본값은 10초입니다. 최소값은 1초입니다.

• timeoutSeconds: 프로브가 타임아웃되는 초 수입니다. 기본값은 1초입니다. 최소값은 1초입니다.

• successThreshold: 프로브가 실패한 후 성공으로 간주되기 위해 필요한 최소 연속 성공 횟수입니다. 기본값은 1입니다. 라이브니스 및 스타트업 프로브의 경우 1이어야 합니다. 최소값은 1입니다.

• failureThreshold: 프로브가 연속으로 failureThreshold 횟수만큼 실패하면 Kubernetes는 전체 체크가 실패했다고 간주합니다: 컨테이너가 준비되지 않았거나 건강하지 않거나 라이브하지 않다고 판단합니다. 기본값은 3입니다. 최소값은 1입니다. 스타트업 또는 라이브니스 프로브의 경우, failureThreshold 횟수 이상 실패한 경우 Kubernetes는 해당 컨테이너를 비정상으로 간주하고 해당 컨테이너를 재시작합니다. kubelet은 terminationGracePeriodSeconds의 설정을 해당 컨테이너에 대해 준수합니다. 레디니스 프로브가 실패한 경우, kubelet은 해당 체크가 실패했음에도 불구하고 컨테이너를 계속 실행하며, 추가 프로브를 계속 수행합니다. 체크가 실패했기 때문에 kubelet은 Pod의 Ready 상태를 false로 설정합니다.

• terminationGracePeriodSeconds: 실패한 컨테이너의 종료를 트리거한 후, 컨테이너 런타임이 해당 컨테이너를 강제로 중지하기까지 kubelet이 기다릴 유예 기간을 설정합니다. 기본값은 Pod 레벨의 terminationGracePeriodSeconds 값을 상속받으며(지정하지 않으면 30초), 최소값은 1초입니다. 자세한 사항은 프로브 레벨의 terminationGracePeriodSeconds를 참조하세요.

kubectl apply -f ../

# -w는 watch
kubectl get pods -w

mysql-64864d79c7-bdbhx                  1/1     Running    0          15s
usermgmt-microservice-fc67b4fbc-bnbmc   0/1     Init:0/1   0          15s
usermgmt-microservice-fc67b4fbc-bnbmc   0/1     PodInitializing   0          23s
usermgmt-microservice-fc67b4fbc-bnbmc   0/1     Running           0          24s
usermgmt-microservice-fc67b4fbc-bnbmc   1/1     Running           0          88s

# MySQL 컨테이너가 생성될 때까지 기다리고, init 컨테이너가 성공하면 사용자 관리 마이크로서비스 컨테이너가 시작된다.
# readiness probe가 60초 대기 후 컨테이너가 준비 상태로 변경되는지 확인 한다. 여기서는 24s였다.
# 그리고 마지막으로 88초뒤에 애플리케이션이 정상 작동하는 것을 확인했다. readiness probe가 정상적으로 작동하고 있다.

Kubernetes Resources - Requests & Limits

• 요청 (Requests)
• 목적: 컨테이너가 정상적으로 실행되기 위해 필요한 자원의 최소량을 정의한다.
• 사용: Kubernetes 스케줄러는 요청된 자원을 기반으로 노드를 선택하여 포드를 배치한다. 즉, 컨테이너가 필요한 최소 자원을 보장한다.

• 제한 (Limits)
• 목적: 컨테이너가 사용할 수 있는 자원의 최대량을 설정.
• 사용: Kubelet은 설정된 자원 제한을 강제하여 컨테이너가 이 제한을 초과하지 않도록 한다. 이를 통해 자원 과다 사용을 방지한다.
• Kubernetes에서 실행되는 중요한 컨테이너는 항상 필요한 CPU와 메모리를 갖도록 설정해야한다.

• 자원 단위
• CPU:
• 1,000m는 1 VCPU
• 예: 500m는 0.5 VCPU.
• 메모리:
• 1,024Mi는 1GB
• 예: 128Mi는 약 135MB

• 스케일링 및 자원 관리
• 자동 스케일링: 클러스터가 자동으로 자원을 조정할 수 있지만, 작은 클러스터에서는 자원 소비를 신중히 고려해야 한다.
• 자원 계획: 클러스터의 자원 소비와 시스템 자원도 고려하여, 클러스터가 높은 부하 조건을 견딜 수 있도록 계획해야 한다.

Kubernetes Namespaces

• 네임스페이스는 Kubernetes 클러스터 내에서 가상 클러스터처럼 작동한다. 객체를 서로 격리된 경계 내에서 관리하여, 여러 팀이나 프로젝트가 독립적으로 자원을 사용할 수 있도록 한다.

• 여러 사용자나 팀이 클러스터를 공유할 때, 네임스페이스를 통해 격리된 환경을 제공하며, 자원 관리와 충돌을 방지한다.

• 리소스 격리: 네임스페이스를 사용하면 서로 다른 프로젝트나 팀의 자원을 격리하여 관리할 수 있다.

• 리소스 쿼터: 네임스페이스별로 CPU와 메모리와 같은 자원의 사용을 제한할 수 있다. 예를 들어, 네임스페이스에 CPU 2코어와 4GB 메모리의 쿼터를 설정할 수 있다.

• 기본 네임스페이스: 클러스터 생성 시 기본적으로 생성되는 네임스페이스로, 현재까지의 모든 작업이 이곳에 포함된다. 명시적으로 네임스페이스를 설정하지 않으면 기본 네임스페이스에 객체가 생성된다.

• kube-system: Kubernetes 시스템 관련 객체가 포함된 네임스페이스로, 클러스터 내부의 시스템 리소스와 서비스를 관리한다.
• ClusterIP를 가진 kube DNS Service
• AWS node
• core DNS
• EBS CSI Controller 등

• kube-public: 자동으로 생성되는 네임스페이스로, 모든 사용자, 심지어 인증되지 않은 사용자도 읽을 수 있는 자원을 포함한다.

• kube-node-lease: 클러스터가 확장될 때 노드의 성능을 향상시키기 위한 네임스페이스로, 각 노드와 관련된 리스 객체를 포함한다. 이 네임스페이스는 보통 자세히 다루지 않는다.

kubectl get namespace

kubectl get all --namespace <namespace>. # 특정 네임스페이스 내의 모든 객체를 확인

kubectl create namespace <name> # 네임스페이스 생성

Kubernetes Namespaces - Create Imperatively using kubectl

• kubectl apply -f <manifest-file> -n dev1 명령어를 사용하여 dev1 네임스페이스에 매니페스트를 배포

• kubectl get all -n dev1 명령어를 사용하여 dev1 네임스페이스에 배포된 모든 객체를 확인

NAME                                        READY   STATUS     RESTARTS   AGE
pod/mysql-64864d79c7-b5r7b                  1/1     Running    0          12s
pod/usermgmt-microservice-fc67b4fbc-pqtsv   0/1     Init:0/1   0          12s

NAME                               TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
service/mysql                      ClusterIP   None            <none>        3306/TCP         12s
service/usermgmt-restapp-service   NodePort    10.100.221.81   <none>        8095:31685/TCP   12s

NAME                                    READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/mysql                   1/1     1            1           12s
deployment.apps/usermgmt-microservice   0/1     1            0           12s

NAME                                              DESIRED   CURRENT   READY   AGE
replicaset.apps/mysql-64864d79c7                  1         1         1       12s
replicaset.apps/usermgmt-microservice-fc67b4fbc   1         1         0       12s

• 스토리지 클래스 및 PVC 확인
• 스토리지 클래스 및 PVC 확인
• PVC는 네임스페이스 수준의 객체로 dev1과 dev2에 각각 존재한다.

kubectl get pvc
No resources found in default namespace.

kubectl get pvc -n dev1
NAME                 STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   VOLUMEATTRIBUTESCLASS   AGE
ebs-mysql-pv-claim   Bound    pvc-ac9f6d5b-88a2-46f6-8bc4-7313be16f452   4Gi        RWO            ebs-sc         <unset>                 91s

• PV와 스토리지 클래스는 특정 네임스페이스에 국한되지 않는다.

Kubernetes Namespaces - Limit Range

1. 리소스 요청(Request) 및 제한(Limit)
• 컨테이너 배포 시 요청할 CPU와 메모리 양을 설정하고, 사용 가능한 최대 한도를 지정.
• 이전에는 수동으로 각 컨테이너마다 설정.

2. 제한 범위(Limit Range)의 이점
• 네임스페이스에 배포된 모든 컨테이너에 대해 기본 CPU와 메모리 제한을 자동으로 설정.
• 각 컨테이너에 명시적으로 리소스를 정의할 필요 없이 기본값을 적용.
• 제한 범위를 사용하면 네임스페이스 내의 모든 컨테이너에 대해 일관된 리소스 제한을 설정할 수 있어 관리가 용이.
• 기본 및 최소/최대 리소스 설정을 통해 클러스터 자원을 효율적으로 활용하고, 예기치 않은 리소스 과다 사용을 방지.

3. 제한 범위의 두 가지 방식
• 기본(Default) 옵션: 네임스페이스에 있는 모든 컨테이너에 대해 기본 CPU와 메모리를 설정.
• 최소 및 최대(Min and Max) 옵션: 컨테이너에 설정할 수 있는 최소 및 최대 리소스 값을 지정.

Kubernetes - Resource Quota

• 포드 수: 네임스페이스에 생성할 수 있는 포드의 최대 개수.

• CPU 요청: 네임스페이스 내에서 요청할 수 있는 총 CPU 자원의 양.

• 메모리 요청: 네임스페이스 내에서 요청할 수 있는 총 메모리 자원의 양.

• CPU 한도: 네임스페이스 내에서 설정할 수 있는 총 CPU 자원의 최대 양.

• 메모리 한도: 네임스페이스 내에서 설정할 수 있는 총 메모리 자원의 최대 양.

• ConfigMaps: 네임스페이스 내에서 생성할 수 있는 ConfigMap 객체의 최대 개수.

• PersistentVolumeClaims: 네임스페이스 내에서 생성할 수 있는 영구 볼륨 클레임(PVC)의 최대 개수.

• 서비스: 네임스페이스 내에서 생성할 수 있는 서비스 객체의 최대 개수.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: ns-resource-quota
  namespace: dev3
spec:
  hard:
    pods: "5"
    requests.cpu: "2"
    requests.memory: "2Gi"
    limits.cpu: "3"
    limits.memory: "4Gi"
    configmaps: "5"
    persistentvolumeclaims: "2"
    services: "5"

• 포드 수: 5

• 요청된 CPU: 2

• 요청된 메모리: 2Gi

• CPU 한도: 3

• 메모리 한도: 4Gi

• 설정 맵: 5

• 영구 볼륨 클레임: 2

• 서비스: 5

EKS AWS RDS- Relational Database Service

• MySQL 클러스터 사용의 문제점:
• 복잡한 설정: StatefulSet을 사용해 MySQL의 고가용성을 설정하려면 복잡한 작업이 필요.
• 제한된 EBS: EBS 볼륨은 가용 영역 수준에서 제공되며, 다수의 가용 영역을 사용하는 설정에서 문제를 일으킬 수 있다.
• 관리 어려움: 자동 백업, 복구, 업그레이드 등이 부족하고, MySQL 관리와 관련된 복잡한 설정이 필요하다.

• RDS 데이터베이스의 장점:
• 고가용성: RDS는 자동으로 높은 가용성을 제공하며, 읽기 전용 복제본 생성 및 자동 백업/복구 기능을 지원한다.
• 편리한 관리: 관리 콘솔에서 쉽게 설정할 수 있으며, 자동 업그레이드와 메트릭/모니터링 기능도 제공된다.
• 간단한 통합: Kubernetes 클러스터에서 RDS 엔드포인트 URL만 설정하면 쉽게 통합할 수 있다.

• AWS 아키텍처 구성:
• VPC와 서브넷: EKS 클러스터는 VPC 내에서 자동으로 생성되며, RDS 데이터베이스는 프라이빗 서브넷에 배치된다.
• 클러스터와 데이터베이스: EKS 클러스터의 제어 평면은 퍼블릭 및 프라이빗 서브넷을 포함하며, 데이터베이스는 프라이빗 서브넷에 위치한다.

• RDS 보안 그룹 생성:
• RDS 데이터베이스에 접근할 수 있도록 포트 3306을 허용하는 보안 그룹을 EC2에서 생성
• MySQL의 기본 포트 3306을 열어 모든 네트워크에서 접근할 수 있도록 설정

• Inbound Rules
• Type: MySQL/Aurora
• Protocol: TPC
• Port: 3306
• Source: Anywhere (0.0.0.0/0)
• Description: Allow access for RDS Database on Port 3306

• Outbound Rules
• Leave to defaults

• DB 서브넷 그룹 생성:
• RDS에서 DB 서브넷 그룹을 생성하여 US East 1A와 1B의 프라이빗 서브넷을 포함
• Name: eks-rds-db-subnetgroup
• Description: EKS RDS DB Subnet Group
• VPC: eksctl-eksdemo1-cluster/VPC
• Availability Zones: ap-southeast-2a, ap-southeast-2c
• Subnets: 2 subnets in 2 AZs

• RDS 데이터베이스 생성:
• 생성 방식: 표준 생성 방식을 사용하여 MySQL 데이터베이스를 생성
• 버전 및 티어: 무료 티어를 선택하고, MySQL의 최신 버전을 사용
• DB 인스턴스 설정: 인스턴스 식별자를 'user MGMT db'로 설정하고, 마스터 사용자 이름을 'DB admin', 비밀번호를 'DB password 11'로 설정
• 인스턴스 크기: T2 micro를 선택하고, 저장소를 20GB로 설정
• VPC 및 서브넷 그룹: EKS CTL VPC와 EKS RDS DB 서브넷 그룹을 선택하여 프라이빗 서브넷에 배치
• 보안 그룹: 이전에 생성한 DB 보안 그룹을 사용
• 기본 보안 그룹 제거: 기본 보안 그룹을 제거하고, EKS RDS DB 보안 그룹만 선택
• 데이터베이스 스키마: 초기 데이터베이스 스키마를 'user MGMT'로 설정

Create Kubernetes ExternalName Service & Other Manifests, Deploy & Test

1. RDS 보안 그룹 확인:
• RDS 데이터베이스의 보안 그룹에서 모든 네트워크에서의 접근이 허용되어 있는지 확인했다. 포트 3306이 열려 있어야 한다.

2. Kubernetes 외부 이름 서비스 매니페스트 생성 및 배포:
• external name 타입의 서비스를 생성하여 RDS 데이터베이스에 연결할 수 있는 매니페스트를 작성했다.
• 매니페스트의 외부 이름 값은 RDS 데이터베이스 엔드포인트에서 가져왔다.
• 다음 명령어로 배포:

kubectl apply -f kube-manifests/S01-mySQL-external-name-service.yaml

• 서비스 생성 확인 명령어:

kubectl get svc

kubectl run -it --rm --image=mysql:latest --restart=Never mysql-client -- mysql -h {rds endpoint} -u dbadmin -pdbpassword11

mysql> show schemas;
mysql> create database usermgmt;
mysql> show schemas;
mysql> exit

3. MySQL 클라이언트로 데이터베이스 연결:
• kubectl 클라이언트를 사용하여 MySQL 데이터베이스에 연결하고, 사용자 MGMT 스키마를 생성.
• 스키마 확인 명령어:

SHOW SCHEMAS;

4. 배포 파일 업데이트:
• 사용자 이름을 'root'에서 'DB admin'으로 변경하고, 비밀번호를 'DB password 11'로 설정했다.
• Kubernetes 비밀에 대한 비밀번호는 변경하지 않았다.

5. 상태 확인 및 테스트:
• 다음 명령어로 포드와 노드 상태를 확인:

kubectl get pods
kubectl get nodes -o wide

• 퍼블릭 IP를 확인하여 웹 브라우저에서 서비스가 정상적으로 실행되고 있는지 검토.