[GCP] Foundations - Kubernetes 아키텍처

Kubernetes

• Kubernetes
  • 컨테이너 관리 및 조정 솔루션
  • Open source
  • Automation
  • Container management
  • Declarative configuration
  • Imperative configuration
• Kubernetes features
  • Supports both stateful and stateless applications
    • stateful
      • 애플리케이션과 사용자 및 세션 데이터를 영구적으로 저장
    • stateless
      • Nginx 또는 Apache 웹 서버
  • Autoscaling
  • Resource limits
  • Extensibility
  • Portability

 

Google Kubernetes Engine (GKE)

• GKE
  • GKE를 통해 Kubernetes 워크로드를 클라우드로 쉽게 가져올 수 있음
    • 노드에서 워크로드 실행
  • Fully managed
  • Container-optimized OS
  • Auto upgrade
  • Auto repair
  • Cluster scaling
  • Seamless integration
  • Identity and access management
  • Integrated logging and monitoring
  • Integrated networking
  • Cloud Console

 

Computing options

• Compute Engine
• App Engine
• Google Kubernetes Engine
• Cloud Run
• Cloud Funtions

 

Kubernetes 개념

• Kuberenets 객체 모델과 선언적 관리의 원칙을 이해해야 함
• Kubernetes Object
  • Object spec
  • Object status

• Pod
  • Kubernetes 모듈의 기본 구성 요소
  • 배포 가능한 가장 작은 Kubernetes 객체
  • Kubernetes 시스템에서 실행중인 모든 컨테이너는 Pod다. Pod는 컨테이너가 있는 환경을 구현하며 이 환경은 하나 이상의 컨테이너를 수용할 수 ㅣㅇㅆ다.
  • Pod 안 컨테이너는 긴밀하게 결합하며 네트워킹과 스토리지 등의 리소스를 공유한다.
  • 각 Pod에 고유한 IP 주소를 할당한다. 

• Nginx 웹 서버 인스턴스 3개가 자체 Container에 있는 경고 항상 실행되기를 바람
  • Kubernetes는 선언적 관리의 원칙을 구현한다.
  • Pod 선언
  • Pod는 자가 복구가 되지 않음을 유의해야 한다. 

• Desired state compared to current state
  • Kubernetes Control Plane
    • Kubernetes 제어 영역은 클러스터의 상태를 지속적으로 모니터링하여 선언된 것과 실제 상태를 끊임없이 비교하고 필요에 따라 상태를 수정함

 

Kubernetes 제어 영역

• Cooperating processes make a Kubernetes
  • Node의 역할은 Pod를 실행하는 것
  • Conrol Plane의 역할은 전체 클러스터를 조정하는 것
• kube-API server
  • 사용자와 직접 상호작용
  • pod 시작을 포함하여 클러스터의 상태를 보거나 변경하는 명령어를 수락
  • 예시로 kubectl 명령어 사용
  • 클러스터 상태에 대한 모든 쿼리나 변경사항이 kube-APIserver에 전달되어야 함
• etcd
• 클러스터 데이터베이스
• 클러스터의 상태를 안정적으로 저장
• 클러스터의 구성 데이터 포함. 어떤 노드가 클러스터의 일부인지, 어떤 포드가 실행되어야 하는지 어디서 실행되어야 하는지와 같은 보다 동적인 정보도 포함.
• kube-scheduler
  • node에 pod 예약
  • 각 포드의 요구사항을 평가하고 가장 적합한 노드를 선택
  • 실제로 노드에서 포드를 실행하는 작업을 수행하지는 않음
    • 대신 노드에 아직 할당되지 않은 포드 객체를 발견할 때마다 노드를 선택하고 해당 노드의 이름을 포드 객체에 쓰는 작업을 수행
  • 포드를 실행할 위치를 어떻게 결정할까요?
    • 모든 노드의 상태를 알고 있으며 하드웨어, 소프트웨어, 정책을 바탕으로 포드가 실행될 수 있는 위치에 대해서도 사용자가 정의한 제약조건을 따른다.
• kube-controller-manager
  • KubeAPIserver를 통해 지속적으로 클러스터의 상태를 모니터링
    • 클러스터의 현재 상태와 원하는 상태가 일치하지 않을 때마다 kube-controller-manager는 원하는 상태를 이루고자 변경을 시도함
  • 많은 Kubernetes 객체가 컨트롤러라는 코드 루프로 관리됨
    • 이 코드 루프는 해결 작업을 처리함
• kube-cloud-manager
  • 필요할 때 부하 분산기나 스토리지 볼륨과 같은 Google Cloud 기능을 가져오는 역할을 함
• 각 노드는 작은 제어 영역 구성요소 집합도 실행함
  • 예를 들어 각 노드는 kubelet을 실행
    • kubelet은 각 노드에서 Kubernetes의 에이전트 역할을 함
  • kube-APIserver가 노드에서 포드를 실행하려고 하면 해당 노드의 kubelet으로 연결
  • kubelet은 컨테이너 런타임을 사용하여 포드를 시작하고 준비 및 활성 프로브를 포함한 수명 주기를 모니터링하며 kube-APIserver에 다시 보고함
• Kubernetes 환경에서는 여러 컨테이너 런타임 옵션을 제공함
  • 컨테이너 런타임 = 컨테이너 이미지에서 컨테이너를 실행하는 방법을 알고 있는 소프트웨어
  • GKE에서 노드에 사용하는 Linux 배포는 Docker의 런타임 구성요소인 containerd를 사용하여 컨테이너를 실행
• kube-proxy
  • 클러스터의 포드 간 네트워크 연결을 유지관리
  • 오픈소스 Kubernetes에서 kube-proxy는 Linux 커널에 내장된 IP 테이블의 방화벽 기능을 사용하여 이를 수행

 

 

Google Kubernetes Engine 개념

• Kubernetes 제어 영역 다이어그램에는 구성요소가 아주 많이 있다.
  • Kubernetes 클러스터를 일일이 설정하려면 할 일이 많다.
  • 다행히 클러스터의 초기 설정 대부분을 자동화할 수 있는 kubeadm이라는 오픈소스 명령어가 있음
  • 그러나  노드가 실패하거나 노드에 유지보수가 필요하면 관리자가 수동으로 대응해야 함
  • 그렇기 때문에 많은 사람이 Kubernetes용 관리형 서비스를 선호
• GKE: More about nodes
  • Kubernetes doesn't create nodes.
    • Cluster admins create nodes and add them to Kubernetes
  • GKE managers this by deploying and registering Compute Engine instances as nodes 
  • 사용자를 위해 모든 제어 영역 구성요소를 관리
  • 모든 Kubernetes API 요청을 보내는 IP 주소를 노출하지만 GKE는 그 뒤에 있는 모든 제어 영역 인프라를 프로비저닝하고 관리
  • GKE는 Compute Engine 가상 머신 인스턴스를 실행하고 이를 노드로 등록
  • Compute Engine에서 실행되므로 사용자가 클러스터를 만들 때 노드 머신 유형을 선택
    • 기본적으로 노드 머신 유형은 vCPU 2개와 4GB의 메모리를 제공하는 e2-medium
    • 노드의 코어 수와 메모리 용량을 맞춤설정할 수 있습니다 CPU 플랫폼을 선택
    • Node Pool을 만들어 여러 노드 머신 유형을 선택할 수도 있다.
      • Node Pool은 메모리 양이나 CPU 세대와 같은 구성을 공유하는 클러스터 내 노드의 하위 집합
      • GKE 기능
      • 주의사항으로, 각 노드의 CPU 및 메모리 중 일부는 클러스터의 일부로 작동하도록 하는 GEK 및 Kubernetes 구성요소를 실행하는 데 필요
  • 기본적으로 클러스터는 3개의 같은 노드가 있는 단일 Google Cloud 컴퓨팅 영역에서 시작되며 이는 모두 하나의 노드 풀에 있다.
    • 노드 수는 클러스터 생성 중 또는 생성 후에 변경될 수 있다.
    • 무한대로 늘리는 것이 가능한 것은 아님.

• GKE 리전 클러스터로 문제 해결 가능. (영역에 중단이 발생하더라도 클러스터의 애플리케이션이 계속 실행될 수 있음)
  • 클러스터에 대해 단일 API 엔드포인트가 있다.
  • 그 제어 영역과 노드는 리전 내 여러 Compute Engine 영역에 분산됨.
  • 애플리케이션의 가용성이 단일 리전의 여러 영역에서 유지관리되도록 함
  •  각 영역은 1개의 제어 영역 및 3개의 노드를 포함하고 있다

•  전체 클러스터(즉, 제어 영역과 해당 노드)는 공개 인터넷에서 숨겨진다.
  • 클러스터 제어 영역은 내부 IP 주소를 통해 Cloud Logging이나 Cloud Monitoring과 같은 Google Cloud 제품에서 액세스할 수 있다.
  • 외부 IP 주소를 통해 승인된 네트워크에서도 액세스할 수 있다.
  • 노드에는 비공개 Google 액세스를 통한 제한된 아웃바운드 액세스가 있을 수 있으며 이를 통해 다른 Google Cloud 서비스와 통신할 수 있다.
    • 예를 들어 노드는 외부 IP 주소 없이도 Google Container Registry에서 컨테이너 이미지를 가져올 수 있다.

 

Kubernetes 객체 관리

• 모든 Kubernetes 객체는 고유한 이름과 고유한 식별자가 있다
• 상시 실행중인 3개 nginx 웹서버
  • 가장 간단한 방법은 pod 객체 3개를 선언하고 상태를 지정하는 것
  • 각 객체에 대해 pod가 생성되어야 하고 nginx 컨테이너 이미지가 사용되어야 한다.
• pod 객체를 선언하는 방법
  • 사용자는 Kubernetes가 생성하고 매니페스트 파일로 유지관리할 객체를 정의
  • YAML 파일은 pod의 원하는 상태를 정의
    • 이름과 실행할 특정 컨테이너 이미지를 정의
  • 필수 입력
    • apiVersion
    • kind
    • metadata
  • 같은 YAML 파일에 여러 관련 객체를 정의할 수 있는데 사실 그렇게 하는 것이 권장됨

• YAML 파일을 버전 제어 저장소에 저장해야 함
  • 클러스터를 다시 생성하거나 복원할 때 유용
  • Cloud Source Repositories

• Object names
  • Kubernetes 네임스페이스에서는 특정 종류의 객체 하나만 동시에 특정 이름을 가질 수 있다
    • 그러나 객체가 삭제되면 해당 이름을 다시 사용할 수 있다
• 모든 객체는 Kubernetes가 생성한 고유한 ID를 가지고 있다
• 라벨은 키-값 쌍으로 객체를 생성하는 동안이나 생성한 후 객체에 태그를 지정
  • 객체와 객체 하위 집합을 식별하고 구성하는 데 유용
  • EX) 애플리케이션, 객체의 환경, 객체가 구성하는 스택
  • 다양한 컨텍스트에 따라 라벨을 기준으로 Kubernetes 리소스를 선택

• node를 관리하는데 개별 pod를 지정
  • 수가 늘어나면 관리가 힘듦
  • pod는 영원히 실행되지 않고 임시적으로 실행됨 (run, broken, die)

• pod의 상태를 관리하는 작업을 담당하는 컨트롤러 객체를 선언
  • Ex) Deployment, StatefulSet, DaemonSet, Job
  • deployment controller가 단일 yaml 파일로 pod 생성

• 클러스터에서 모두의 작업을 정리하고 구성하려면 어떻게 해야 할까?
  • Kubernetes를 사용하면 물리적 단일 클러스터를 '네임스페이스'라고 하는 여러 가상 클러스터로 추상화할 수 있다
  • 네임스페이스는 포드, 배포, 컨트롤러와 같은 리소스에 이름을 지정할 수 있는 범위를 제공한다

• 서비스
  • 서비스는 지정된 포드에 대해 부하 분산된 액세스를 제공한다.
    • ClusterIP: 이 클러스터 내에서만 액세스 가능한 IP 주소에 있는 서비스를 노출. 기본 유형.
    • NodePort: 특정 포트 번호의 클러스터에서 각 노드 IP 주소에 있는 서비스를 노출
    • LoadBalancer: 클라우드 제공업체가 제공하는 부하 분산 서비스를 사용하여 서비스를 외부에 노출
  • Google Kubernetes Engine에서 LoadBalancer를 사용하면 리전 네트워크 부하 분산 구성에 기본적으로 액세스할 수 있다. 전역 HTTP(S) 부하 분산 구성에 액세스하기 위해서는 인그레스 객체를 사용하면 된다.
• 컨트롤러 객체
  • 종류
    • ReplicaSets
    • 배포
    • 복제 컨트롤러
    • StatefulSets
    • DaemonSets
    • 작업
  • ReplicaSet 컨트롤러는 서로 동일한 포드 항목이 모두 동시에 실행되도록 한다.
  • 배포는 사용자가 필요한 만큼의 ReplicaSet를 사용하여 포드를 생성, 업데이트, 롤백, 확장할 수 있도록 지원한다.
  • 복제 컨트롤러는 ReplicaSet와 배포를 조합한 것과 유사한 역할을 수행하지만, 이 객체의 사용은 더 이상 권장되지 않는다.
  • 로컬 상태를 유지하는 애플리케이션을 배포해야 하는 경우 StatefulSet가 더 나은 선택지이다.
    • 배포를 통해 생성된 포드에는 영구 ID가 주어지지 않지만, StatefulSet를 사용하여 생성된 포드는 고유한 영구 ID와 안정적인 네트워크 ID, 영구 디스크 스토리지를 갖는다.
  • 특정 포드를 클러스터 내의 모든 노드 또는 여러 노드에서 실행하려면 DaemonSet를 사용해라.
    • DaemonSet는 특정 포드가 모든 노드 또는 노드의 일부 하위 집합에서 항상 실행되도록 한다.
  • 작업 컨트롤러는 태스크 실행에 필요한 하나 이상의 포드를 생성한다.

 

Migrate for Anthos 소개

• Migrate for Anthos는 기존 애플리케이션을 Kubernetes 환경으로 마이그레이션
• 프로세스 자동화. 대부분 마이그레이션이 10분 이내로 완료.

• step
  • Configure processing cluster
  • Add migration source
  • Genenerate and review plan
  • Generate artifacts
    • 배포에 필요한 애플리케이션의 컨테이너 이미지와 YAML 파일을 만든다
  • Test
• Install
  • migctl setup install

 

Summary

• Kubernetes controllers keep the cluster state matching the desired state.
• Kubernetes consists of a family of control plane components, running on the control plane and the nodes.
• GKE abstracts away the control plane.
• Declare the state you want using manifest files.

 

Quiz

1. 여러분은 애플리케이션을 설계하고 있고, 지연 시간을 최소화하기 위해 컨테이너를 가능한 한 서로 가까이 위치시키고자 합니다. 이 요건을 충족하는 데 도움이 되는 설계 결정은 무엇인가요?

=> 컨테이너를 동일한 포드에 배치합니다.

 

2. 스테이트풀(Stateful) 애플리케이션용 스토리지를 구성할 때, 포드가 장애를 일으키거나 어떠한 이유로든 삭제되더라도 손실되거나 삭제되지 않는 애플리케이션 데이터를 위해 컨테이너 내 파일 시스템 스토리지를 제공하려면 어떤 단계를 수행해야 하나요?

=> 네트워크 기반 스토리지를 사용해 볼륨을 생성하여 포드에 원격으로 내구성 있는 스토리지를 제공하고 이를 포드에 지정해야 합니다.

 

3. 클러스터에서 작업을 수행하기 위해 kubectl 명령어가 연결하는 Kubernetes 구성요소는 무엇인가요?

=> kube-apiserver

 

4. 여러분은 애플리케이션의 여러 복사본을 배포하여 트래픽 부하를 분산하려고 합니다. 이 애플리케이션의 포드를 클러스터의 프로덕션 네임스페이스로 어떻게 배포해야 하나요?

=> 실행할 복제본 수를 지정하는 배포 매니페스트를 만듭니다.

 

5. 클러스터 내의 모든 노드에 배포해야 하는 새로운 로깅 및 감사 유틸리티가 있습니다. 이 작업을 처리하기 위해 어떤 유형의 컨트롤러를 사용해야 하나요?

=> Daemonset

 

6. 여러분은 Kubernetes 클러스터에서 실행되는 프로덕션 애플리케이션이 테스트 및 스테이징 배포의 영향을 받지 않도록 하려고 합니다. 프로덕션 애플리케이션의 리소스에 대해 우선순위를 지정할 수 있도록 구현 및 구성해야 하는 기능은 무엇인가요?

=> 테스트, 스테이징, 프로덕션용 네임스페이스를 구성하고 테스트 및 스테이징 네임스페이스 대상 특정 Kubernetes 리소스 할당량을 구성합니다.(리소스 할당량은 특정 네임스페이스의 사용량을 제한하는 데 사용되며, 모든 네임스페이스가 아닌 제한해야 하는 네임스페이스에 대해서만 구성하면 됩니다.)

 

7. 여러분은 첫 번째 영역의 기본 풀에 4개의 머신을 포함하고 있는 새로운 Google Kubernetes Engine 리전 클러스터를 배포하고, 영역 수를 기본값으로 두었습니다. 몇 개의 Compute Engine 머신이 배포되어 여러분의 계정에 청구되나요?

=> 12 (3개의 영역에 각각 4개의 노드가 배포됩니다. 제어 영역 노드는 각 영역에 배포되지만 계정에 대해 청구되지는 않습니다.) (GKE 리전 클러스터는 하나의 리전 안에 있는 여러 영역에 배포됩니다. Google은 또한 GKE 제어 영역 노드를 각 영역에 배포합니다.)