고민의 흔적

Kubernetes 네트워킹 모델

1. IP 주소에 크게 의존합니다.
2. 서비스, pod, 컨테이너, 노드는 IP 주소와 포트를 사용하여 통신합니다.
3. Kubernetes는 트래픽을 올바른 pod로 전달하기 위해 여러 유형의 부하 분산을 제공합니다.

pod 네트워킹

1. pod는 공유 스토리지와 네트워킹이 포함된 컨테이너 그룹입니다.
2. Kubernetes의 'pod별 IP' 모델을 기반으로 한다. 이 모델에서는 각 pod에 단일 IP 주소가 할당되고 pod 내의 컨테이너는 해당 IP 주소를 포함하여 동일한 네트워크 네임스페이스를 공유합니다.

pod 네트워킹의 예

• 기존 애플리케이션에서 클라이언트 액세스를 위해 nginx를 역방향 프록시로 사용하고 있을 수 있습니다.
• nginx 컨테이너는 TCP 포트 80에서 실행되고 기존 애플리케이션은 TCP 포트 8000에서 실행됩니다.
• 두 컨테이너 모두 동일한 네트워킹 네임스페이스를 공유하기 때문에 두 컨테이너는 동일한 머신에 설치된 것처럼 보입니다.
• nginx 컨테이너는 TCP 포트 8000에서 localhost에 대한 연결을 설정하여 기존 애플리케이션에 연결합니다.
• 단일 pod에서는 이것이 효과적이지만 워크로드는 단일 pod에서 실행되지 않습니다.
• 워크로드는 서로 통신해야 하는 다양한 애플리케이션으로 구성됩니다.

pod는 서로 어떻게 통신할까

1. 각 pod에는 고유한 IP 주소가 있습니다 네트워크에 있는 호스트처럼
2. 노드에서 pod는 노드의 루트 네트워크 네임스페이스를 통해 서로 연결되며 이를 통해 해당 VM에서 pod가 서로를 찾고 연결할 수 있습니다.
3. 루트 네트워크 네임스페이스는 노드의 기본 NIC에 연결되어 있습니다.
4. 노드의 VM NIC를 사용하여 루트 네트워크 네임스페이스는 해당 노드에서 트래픽을 전달할 수 있습니다. 즉, pod의 IP 주소를 노드가 연결된 네트워크에서 라우팅 할 수 있어야 한다는 뜻입니다.

노드는 해당 pod의 IP 주소를 어디에서 얻을까

1. GKE에서 노드는 Virtual Private Cloud 즉, VPC에 할당된 주소 범위에서 pod IP 주소를 가져옵니다.

VPC

1. VPC는 GCP 내에서 배포하는 리소스에 대한 연결을 제공하는 논리적으로 격리된 네트워크입니다.
2. VPC는 전 세계 모든 리전의 다양한 IP 서브넷으로 구성될 수 있습니다.
3. GKE를 배포할 때 리전 또는 영역과 함께 VPC를 선택할 수 있습니다.
4. 기본적으로 VPC에는 전 세계의 각 GCP 리전에 미리 할당된 IP 서브넷이 있습니다. 서브넷의 IP 주소는 해당 리전에 배포하는 컴퓨팅 인스턴스에 할당됩니다.

Kubernetes의 스토리지 추상화

1. 볼륨
2. PersistentVolume

볼륨

1. 볼륨은 스토리지를 pod에 연결하는 수단입니다.
2. 어떤 볼륨은 임시적입니다. pod에 연결된 시간 동안에만 유지된다는 뜻
3. 어떤 볼륨은 영구적입니다 pod보다도 오래 유지될 수 있다는 뜻
4. 유형에 상관없이 모든 볼륨은 컨테이너가 아닌 pod에 연결됩니다.
5. pod가 더 이상 노드에 매핑되지 않으면 볼륨도 매핑되지 않습니다.
6. 영구적인 스토리지를 제공하는 데 활용 가능한 다른 볼륨 유형도 있습니다
   1. 이러한 유형(??)은 개별 pod의 수명보다 오래 지속되어야 하는 데이터에 사용할 수 있습니다.
   2. Kubernetes 클러스터에서는 이러한 볼륨 유형이 NFS 볼륨, Windows 공유 또는 기본 클라우드 제공업체의 영구 디스크에서 지원되는 경우가 많습니다.
   3. 이러한 유형의 볼륨은 블록 스토리지를 포함하거나 네트워크 파일 시스템을 사용합니다.
7. 장애가 발생한 pod에서는 볼륨이 마운트 해제됩니다.
8. 이러한 볼륨 중 일부는 pod 생성 이전에 이미 존재할 수 있으며 클레임이나 마운트할 수도 있습니다.
9. 중요한 것은 볼륨이 pod의 컨테이너에 액세스 가능한 디렉터리라는 것입니다.
   1. 이 디렉터리의 생성 방식과 디렉터리와 그 안의 콘텐츠를 지원하는 매체는 사용된 특정한 볼륨에 의해 결정됩니다.

 10. 볼륨을 컨테이너에 표시하려면 컨테이너의 volumeMounts 필드에 볼륨 이름과 마운트 경로를 지정해야 합니다.

1. pod 생성 중에 볼륨이 만들어집니다. 볼륨이 만들어지면 컨테이너를 온라인으로 가져오기 전에 pod의 모든 컨테이너에서 사용 가능합니다. 볼륨이 컨테이너에 연결된 후 볼륨의 데이터는 컨테이너 파일 시스템에 마운트 됩니다.
2. 볼륨은 pod가 실행될 때 마운트 볼륨 디렉터리에 연결됩니다 그런 다음 nginx 컨테이너는 /mnt/vol 디렉터리를 보고 여기에서 데이터를 가져올 수 있습니다.

 11. pod가 삭제되면 함께 지워지는 emptyDir 볼륨의 콘텐츠와 다르게 NFS 볼륨에 저장된 데이터는 pod가 삭제되어도 유지됩니다.

1. pod가 삭제되면 NFS 볼륨도 삭제되지만 데이터는 지워지지 않습니다.
2. 마운트 해제되는 것뿐이며 필요하면 새 pod에 다시 마운트 할 수 있습니다.

Kubernetes PersistentVolume 객체

1. 스토리지 사용을 토대로 스토리지 프로비저닝을 추상화합니다.
2. Kubernetes 덕분에 마이크로 서비스 아키텍처에서 애플리케이션을 쉽게 확장할 수 있는 구성요소로 분리할 수 있는 것입니다.
3. 영구 스토리지를 사용하면 장애에 대처하고 데이터 손실 없이 구성요소 예약을 동적으로 변경할 수 있습니다.

애플리케이션 구성요소를 위해 분리된 볼륨을 만들고 유지 관리하는 작업이 애플리케이션 개발자의 몫이어야 할까? 또한 개발자가 애플리케이션의 pod 매니페스트를 수정하지 않고 프로덕션에 배포하기 전에 애플리케이션을 어떻게 테스트할까?

1. 테스트에서 프로덕션 단계로 나아가기 위해 구성을 변경해야 할 때마다 오류의 위험이 있습니다.
2. Kubernetes의 PersistentVolume 추상화는 이러한 문제를 모두 해결합니다.
3. PersistentVolume을 사용하여 클러스터 관리자는 다양한 볼륨 유형을 프로비저닝 할 수 있습니다.
4. 클러스터 관리자는 사용에 대해 신경 쓰지 않고 스토리지를 프로비저닝 하면 됩니다.
5. 또한 애플리케이션 개발자는 PersistentVolumeClaim을 사용하여 스토리지 볼륨을 직접 만들거나 유지 관리하지 않고도 프로비저닝 된 스토리지를 쉽게 클레임하고 사용할 수 있습니다.

역할의 분리

PersistentVolume을 사용할 수 있도록 만드는 것은 관리자의 몫이고 애플리케이션에서 이러한 볼륨을 사용하는 것은 개발자의 몫입니다. 이 두 작업 역할은 서로 독립적으로 이루어질 수 있습니다.

애플리케이션 개발자는 PersistentVolumeClaim을 사용할 때 애플리케이션 실행 위치를 신경 쓸 필요가 없습니다. 프로비저닝된 스토리지 용량은 애플리케이션에 의해 클레임 될 수 있는데 실행 위치가 로컬 사이트나 Google Cloud 혹은 다른 클라우드 제공업체든 상관없죠

애플리케이션 소유자가 Compute Engine 영구 디스크 스토리지를 사용하려면 무엇이 필요한가?

1. pod 수준의 볼륨을 사용하는 경우
2. pod 매니페스트에서 클러스터 수준의 PersistentVolume과 PersistentVolumeClaim을 사용하는 경우
   1. 두 번째 방법이 관리하기 쉽다.
   2. 클라우드 구현을 책임지는 운영팀에서는 PersistentVolume을 사용하기 위해 스토리지 클래스를 정의하고 PersistentVolume의 실제 구현을 관리합니다.
   3. 개발자와 애플리케이션 소유자는 PersistentVolumeClaim을 사용하여 스토리지의 양과 스토리지 클래스를 요청하고 그에 따라 스토리지 유형이 결정됩니다.
   4. 운영팀은 사용하려는 클라우드 서비스를 관리할 수 있으며 애플리케이션 소유자는 특정 구현의 세부사항보다는 애플리케이션이 필요로 하는 것에 집중할 수 있습니다.
   5. Kubernetes 엔진은 PersistentVolume에 대해 이와 동일한 기술을 사용한다.
   6. Google Cloud의 Compute Engine 서비스는 가상 머신 디스크에 영구 디스크를 사용합니다.

영구 디스크

1. 영구 디스크는 오래 지속되는 스토리지를 제공할 수 있는 네트워크 기반 블록 스토리지입니다.

영구 볼륨 추상화의 두 가지 구성요소

1. PersistentVolume
2. PersistentVolumeClaim

영구 볼륨

1. 클러스터 수준에서 관리되는 내구성이 뛰어난 영구 스토리지 리소스입니다.
2. 클러스터 리소스는 pod의 수명 주기와 무관하지만 pod는 수명 주기 동안 이러한 리소스를 사용할 수 있습니다. 하지만 pod가 삭제되더라도 영구 볼륨과 해당 데이터는 계속 존재합니다. 볼륨은 Kubernetes에서 관리하며 수동으로 또는 동적으로 프로비저닝 할 수 있습니다.

PersistentVolumenClaim

1. PersistentVolume을 사용하도록 pod가 만든 요청 및 클레임입니다.
2. PersistentVolumeClaim 객체 내에서 볼륨 크기, 액세스 모드 및 스토리지 클래스를 정의합니다.
3. pod는 PersistentVolumeClaim을 사용하여 영구 볼륨을 요청합니다.
4. 영구 볼륨이 영구 볼륨 신청에 정의된 모든 요구사항과 일치하는 경우 영구 볼륨 신청은 해당 영구 볼륨에 바인딩됩니다. 이제 pod는 이 영구 볼륨에서 스토리지를 사용할 수 있습니다.

스토리지 클래스

• 이름을 지정한 스토리지 특성의 세트입니다.

스토리지용으로 pod 수준 볼륨을 사용하는 것과 클러스터 수준 영구 볼륨을 사용하는 것의 중요한 차이점은 무엇일까?

1. 영구 볼륨은 애플리케이션 구성에서 스토리지 관리를 분리할 수 있는 추상화 수준을 제공합니다.
2. 영구 볼륨의 스토리지는 영구 볼륨 신청과 바인딩되어야 pod에서 액세스 할 수 있습니다.
3. 이것은 같은 스토리지에 대한 영구 볼륨 매니페스트를 생성하는 방법입니다.

pod의 스토리지 구성을 더 쉽게 관리하기 위해 이것이 어떻게 사용되는가?

1. 먼저 볼륨 용량을 지정하고 StorageClassName을 지정합니다.
2. 스토리지 클래스는 영구 볼륨을 구현하는 데 사용되는 리소스입니다.
3. pod에서 PVC를 정의할 때 PVC는 스토리지 클래스 이름을 사용합니다. 클레임이 성공하려면 PV StorageClassName과 일치해야 합니다.

SSD 영구 디스크를 사용하려는 경우

1. 이름이 'ssd'인 이 예처럼 새 스토리지 클래스를 생성할 수 있습니다.
2. ssd라는 이 새로운 스토리지 클래스를 사용하는 PVC는 ssd라는 스토리지 클래스가 있는 PV만 사용합니다. 이 경우 SSD 영구 디스크를 사용합니다.

현대적이고 관리하기 쉬운 방법은 영구 볼륨 추상화를 사용하는 것입니다.

이상으로 2022 Cloud Study Jam 쿠버네티스 중급반 과정을 수료하였습니다.

kubectl 명령어

• kubectl은 관리자가 Kubernetes 클러스터를 제어하는 데 사용하는 유틸리티입니다. 이를 사용해 제어 영역에 있는 Kube API 서버와 통신할 수 있습니다. kubectl은 명령줄 입력 내용을 API 호출로 전환한 후 선택한 Kubernetes 클러스터 내 Kube API 서버로 전송합니다. kubectl이 작업을 수행하려면 Kubernetes 클러스터의 위치와 사용자 인증 정보에 대한 구성 작업이 필요합니다. 
• 예를 들어 관리자가 클러스터의 pod 목록을 확인하려 한다고 가정
  1. 적절한 사용자 인증 정보를 사용하여 kubectl을 클러스터에 연결한 후 kubectl get pods 명령어를 실행하면 됩니다.
  2. kubectl은 이 명령어를 API 호출로 전환하고 클러스터 제어 영역 서버에서 HTTPS를 통해 Kube API 서버로 보냅니다.
  3. Kube API 서버는 etcd 쿼리를 통해 요청을 처리합니다.
  4. Kube API 서버는 HTTPS를 통해 kubectl에 결과를 반환합니다.
  5. kubectl은 API 응답을 해석하여 명령 프롬프트에서 관리자에게 결과를 표시합니다.
• kubectl을 사용하여 클러스터를 구성하려면 먼저 kubectl을 구성해야 합니다.
  1. kubectl은 .kube라는 이름의 숨겨진 폴더에 있는 홈 디렉터리의 파일에 구성을 저장합니다.
  2. 구성 파일에는 클러스터 목록과 각 클러스터에 연결하는 데 사용할 사용자 인증 정보가 포함되어 있습니다.
• 사용자 인증 정보는 어디서 얻을 수 있을까
  1. GKE의 경우 gcloud 명령어를 통해 서비스에서 사용자 인증 정보를 얻습니다.
• 구성을 보려면?
  1. 구성 파일을 열거나 kubectl 명령어인 config view를 사용하면 됩니다.
  2. kubectl config view는 kubectl 명령어 자체의 구성에 대해 알려줍니다.
  3. 클러스터 및 워크로드의 구성을 확인하려면 다른 kubectl 명령어를 사용해야 합니다.
  4. kubectl을 사용해 GKE 클러스터에 연결하려면 먼저 특정 클러스터의 사용자 인증 정보를 가져와야 합니다.
• 사용자 인증 정보를 가져오는 방법
  1. gcloud 명령줄 도구
  2. kubectl을 설치한 다른 환경에서 get credentials gcloud 명령어를 사용하는 것입니다.
• gcloud get credentials 명령어
  1. 기본적으로 $HOME 디렉터리의 .kube 디렉터리에 있는 구성 파일에 구성 정보를 씁니다.
  2. 다른 클러스터에서 이 명령어를 다시 실행하면 새 클러스터용 사용자 인증 정보가 구성 파일에 업데이트됩니다.
  3. 이 구성 프로세스는 Cloud Shell에서 클러스터당 한 번만 수행하면 됩니다.
  4. .kube 디렉터리와 그 안의 콘텐츠가 $HOME 디렉터리에 유지되기 때문입니다.
• gcloud 명령어
  1. 인증된 사용자가 명령줄에서 Google Cloud와 상호작용하는 방법입니다.
  2. 권한이 있는 경우 gcloud get-credentials 명령어는 GKE 클러스터에 연결하는 데 필요한 사용자 인증 정보를 제공합니다.
• kubectl
  • 일반적으로 kubectl은 기존 클러스터의 내부 상태를 관리하기 위한 도구입니다 하지만 kubectl으로는 새 클러스터를 만들거나 기존 클러스터의 형태를 변경할 수 없습니다. 이를 위해서는 gcloud 명령어와 Cloud Console이 인터페이스로 사용되는 GKE 제어 영역이 필요합니다.
  • kube 폴더의 구성 파일이 구성되면 kubectl 명령어가 자동으로 이 파일을 참조하고 사용자 인증 정보를 묻지 않은 채 기본 클러스터에 연결합니다.

kubectl 명령어를 사용하는 방법

명령어 

1. 수행하려는 작업을 지정합니다. get, describe, logs, exec 등
2. 정보를 표시하는 명령어도 있고 클러스터의 구성을 변경하는 명령어도 있습니다.

유형

1. 명령어가 적용되는 Kubernetes 객체를 정의합니다.
2. 예를 들어 pod, 배포, 노드 또는 기타 객체를 지정할 수도 있고 클러스터 자체를 지정할 수도 있습니다.
3. '명령어'와 함께 사용되어 어떤 작업을 어떤 유형의 객체에 수행하길 원하는지 kubectl에 알려줍니다.

이름

1. '유형'에 정의된 객체를 지정합니다.
2. '이름' 필드가 항상 필요한 것은 아닙니다 특히 정보를 나열하거나 표시하는 명령어를 사용하는 경우에는 그렇죠 예를 들어, 이름을 지정하지 않고 kubectl get pods 명령을 실행하면 모든 pod 목록이 반환됩니다. 이 목록을 필터링하려면 pod 이름을 지정해야 합니다 kubectl get pod my-test-app과 같이 이름을 지정하면 되죠 그러면 kubectl은 my-test-app이라는 이름의 pod에 대한 정보만 반환합니다

일부 명령어

1. 일부 명령어는 선택 가능한 플래그를 추가로 지원합니다 명령어 끝에 포함할 수 있죠
2. 출력 형식을 특정 방식으로 지정하는 것과 같은 특별 요청이라고 볼 수 있습니다.
3. pod의 상태를 보기 위해 사용하는 명령어는 kubectl get pod my-test-app -o=yaml입니다.
4. 참고로 kubectl에 YAML 형식으로 출력을 명령하는 것은 매우 유용합니다 다른 클러스터에서 다시 만들 수 있도록 Kubernetes 객체의 기존 상태를 YAML 파일로 캡처하려는 경우가 자주 있기 때문이죠
5. 또한 평소보다 더 많은 정보를 표시하려 할 때도 플래그를 사용할 수 있습니다 예를 들어 kubectl get pods -o=wide 명령어를 실행하면 pod 목록을 넓은 형식으로 표시할 수 있습니다 즉, 목록의 각 pod에서 추가 데이터 열을 볼 수 있습니다.

넓은 형식

• 넓은 형식에서 주목할 만한 추가 정보로는 각 pod가 실행되는 노드에 대한 정보입니다 kubectl 명령어로 할 수 있는 작업이 많이 있습니다 Kubernetes 객체 생성부터 객체 보기와 삭제 구성 파일 보기와 내보내기까지 가능하다.

kubectl을 구성하거나 --kubeconfig 또는 --context 매개변수를 사용해야 입력한 명령이 의도한 클러스터에서 수행된다는 사실입니다.

• 배포
  • 배포는 원하는 pod 상태를 설명합니다.
• 선언적 전략
  • 선언적 전략은 Kubernetes가 이 구성이 클러스터에서 계속 실행되게 만드는 것을 의미합니다.
  • Kubernetes는 배포를 위한 다양한 업데이트 메커니즘도 지원합니다.
• 배포는 pod의 상태를 선언합니다. 
  
  • 예를 들어 새로운 컨테이너 이미지로 업데이트하는 것과 같이 pod 사양을 업데이트할 때마다 변경된 배포 버전과 일치하는 새 ReplicaSet가 생성됩니다.

이것이 배포가 제어된 방식으로 업데이트된 pod를 롤 아웃하는 방법입니다. 기존 pod는 이전 ReplicaSet에서 제거되고 새 ReplicaSet의 새로운 pod로 대체되죠

업데이트된 pod가 안정적이지 않은 경우 관리자는 pod를 이전 배포 버전으로 롤백할 수 있습니다.

배포 구성을 수정하여 수동으로 pod를 확장할 수 있습니다. 워크로드를 자동으로 관리하도록 배포를 구성할 수도 있다.

배포는 스테이트리스(Stateless) 애플리케이션용으로 설계되었습니다.

• 스테이트리스 애플리케이션은 데이터 또는 애플리케이션 상태를 클러스터나 영구 스토리지에 저장하지 않습니다.
• 스테이트리스 애플리케이션의 전형적인 예는 웹 프런트엔드입니다 일부 백엔드는 데이터가 오랫동안 저장되도록 하는 문제가 있어 이러한 백엔드를 관리하려면 배포가 아닌 Kubernetes 객체를 사용해야 합니다.

원하는 상태는 pod의 특성이 포함된 배포 YAML 파일에 설명되어 있으며 pod를 운영 가능하게 실행하고 수명 주기 이벤트를 처리하는 방법이 함께 제공됩니다.

이 파일을 Kubernetes 제어 영역에 제출하면 배포 컨트롤러가 생성되며 이 컨트롤러는 원하는 상태를 실현하고 계속해서 원하는 상태를 유지하는 역할을 합니다.

• 컨트롤러
  • 컨트롤러는 Kubernetes에 의해 생성된 루프 프로세스로 클러스터에서 실행되는 객체 또는 객체 집합의 원하는 상태가 관찰된 상태와 일치하도록 하기 위해 일상적인 작업을 처리합니다 이 과정에서 ReplicaSet가 생성됩니다 ReplicaSet는 주어진 시간에 특정 수의 pod 복제본이 실행되도록 하는 컨트롤러입니다.

배포는 상태를 선언하는 pod의 상위 수준 컨트롤러입니다

배포는 배포에 지정된 pod의 특정 버전을 인스턴스화하고 유지하기 위해 ReplicaSet 컨트롤러를 구성합니다 이것은 YAML 형식의 배포 객체 파일의 간단한 예입니다.

spec. template 섹션에서 pod 템플릿은 이 ReplicaSet에 있는 각 pod의 메타데이터와 사양을 정의합니다.

배포의 생명주기

1. 배포의 '처리 중' 상태
   1. 작업이 수행되고 있음을 나타냅니다.
   2. 여기서 작업은 새 ReplicaSet를 생성하거나 ReplicaSet를 확장 또는 축소하는 것입니다.
2. 배포의 '완료' 상태
   1. 모든 새 복제본이 최신 버전으로 업데이트되어 사용 가능하며 실행 중인 기존 복제본이 없다는 뜻입니다.
3. '실패' 상태
   1. 새로운 ReplicaSet 생성을 완료할 수 없을 때 발생합니다.
   2. Kubernetes가 새 pod에 대한 이미지를 가져오지 못한 것일 수 있습니다 또는 리소스 할당량이 작업을 완료하기에 충분하지 않은 것일 수도 있죠 아니면 작업을 시작한 사용자에게 권한이 없을 수도 있습니다.

배포 수정의 버전 관리

• 여러 롤아웃에 걸쳐 조금씩 여러 군데를 수정하게 되면 수정 버전이 많아지고 관리가 복잡해집니다.
• 따라서 문제가 발생했을 때 롤백할 버전을 파악하기 어려울 수 있습니다.
• 어떤 롤아웃에 어떤 작은 수정 사항이 적용되었는지 기억해야 하죠 소스 코드 저장소에 YAML 파일을 보관하는 것

배포를 만들 수 있는 방법

1. 방금 본 YAML 파일과 같은 매니페스트 파일과 kubectl apply 명령어를 사용하여 선언적으로 배포를 만들 수 있습니다.
2. 명령줄에서 매개변수를 지정하는 kubectl run 명령어를 사용하여 명령적으로 배포를 만드는 것입니다.
   1. 여기에서 이미지와 태그는 각각 이미지와 컨테이너에서 실행할 이미지 및 버전을 지정합니다.
   2. 라벨은 --key 및 --value 생성기를 사용하여 정의되며 사용할 API 버전을 지정하고 --save-config는 향후에 사용할 수 있도록 구성을 저장합니다.
3. GCP Console에서 GKE 워크로드 메뉴를 사용하는 것입니다.
   1. 여기에서 컨테이너, 이미지, 버전을 지정하거나 Container Registry에서 직접 선택할 수도 있습니다.
   2. 환경 변수 및 초기화 명령어를 지정할 수 있습니다. 또한 라벨과 함께 애플리케이션 이름과 네임스페이스를 추가할 수도 있습니다.
   3. 배포 마법사의 마지막 페이지에서 YAML 보기 버튼을 사용하여 해당 배포 사양을 YAML 형식으로 볼 수 있습니다.
   4. 배포로 생성된 ReplicaSet는 원하는 수의 포드가 실행되고 특정 시점에 항상 사용 가능하도록 보장합니다.
   5. 포드에 오류가 발생하거나 제거되면 ReplicaSet가 자동으로 새 포드를 시작합니다.

배포 상태와 세부 정보를 검사하는 명령어

1. kubectl get 및 describe 명령어를 사용하여 배포 상태와 세부정보를 검사할 수 있습니다.
2. kubectl get deployment 명령어를 사용하여 해당 기간과 함께 배포 내 모든 복제본의 필요, 현재, 최신, 사용 가능 상태를 확인할 수 있습니다.
   1. 필요는 배포 사양에서 원하는 복제본 수를 표시합니다.
   2. 현재는 현재 실행 중인 복제본 수입니다.
   3. 최신은 현재 배포 사양에 따라 완전히 최신 상태인 복제본 수를 표시합니다.
   4. 사용 가능은 사용자가 사용할 수 있는 복제본 수를 표시합니다.
3. 배포를 검사하는 또 다른 방법은 GCP Console을 사용하는 것입니다.
   1. 배포, 업데이트 기록, 포드 이벤트에 대한 자세한 정보를 확인할 수 있으며 YAML 형식의 라이브 구성도 볼 수 있습니다.

배포 확장

1. 수동 확장
   1. 복제본의 개수를 정의하여 kubectl 명령어 또는 GCP Console을 사용해 배포를 수동으로 확장할 수 있습니다.
   2. 매니페스트를 수동으로 변경해도 배포가 확장됩니다.
2. 자동 확장
   1. 원하는 최소 및 최대 pod 개수와 CPI 사용률 임계값을 지정하여 배포를 자동 확장할 수도 있습니다.
   2. kubectl 자동 확장 명령어를 사용하거나 GCP Console에서 바로 자동 확장을 수행할 수도 있습니다 그러면 수평형 pod 자동 확장 처리라는 Kubernetes 객체가 만들어집니다 이 객체는 자동 확장을 수행하여 대상 CPU 사용률에 일치시킵니다.

배포 업데이트

이미지 버전 변경과 같이 배포 포드 사양을 변경하면 자동 업데이트 출시가 발생합니다.

자동 업데이트는 포드 사양이 변경되는 경우에만 해당한다는 점에 유의합니다.

1. 업데이트된 배포 사양 파일과 함께 kubectl apply 명령어를 사용하는 것입니다.
   1. 이 방법을 사용하면 포드 템플릿 외부의 복제본 수와 같은 배포의 다른 사양을 업데이트할 수 있습니다.
2. kubectl set 명령어를 사용하는 것입니다.
   1. 이를 통해 이미지, 리소스 또는 선택기 값과 같은 배포의 포드 템플릿 사양을 변경할 수 있습니다.
3. kubectl edit 명령어를 사용하는 것입니다.
   1. Vim 편집기를 사용하여 사양 파일이 열리며 직접 사양을 변경할 수 있습니다.
   2. 파일을 종료하고 저장하면 kubectl이 업데이트된 파일을 자동으로 적용합니다.
4. GCP Console을 사용하는 것입니다.
   1. GCP Console에서 배포 매니페스트를 편집하고 이 추가 옵션과 함께 순차적 업데이트를 수행할 수 있습니다.

배포 업데이트 과정

1. 배포가 업데이트되면 새 복제본 세트를 시작하고 통제된 방식으로 새 포드 세트를 만듭니다.
2. 첫 번째 새 포드는 새 복제본 세트에서 시작됩니다.
3. 다음으로 모든 포드가 이전 ReplicaSet에서 삭제됩니다.
4. 위의 전략은 램프 전략이다. 램프 전략의 장단점
   1. 업데이트가 천천히 출시되어 애플리케이션의 가용성이 보장된다는 장점이 있습니다.
   2. 그러나 이 프로세스는 시간이 걸릴 수 있으며 트래픽이 이전 및 새 포드로 전달되는 방식을 제어할 수 없습니다.

블루/그린 배포 전략

1. 애플리케이션의 새 버전을 배포하고 배포가 업데이트되는 동안 애플리케이션 서비스가 사용 가능한 상태로 유지되도록 하는 데 유용합니다.
2. 블루/그린 업데이트 전략을 사용하면 애플리케이션의 새로운 버전과 함께 완전히 새로운 배포가 만들어집니다.
3. 새 배포의 pod가 준비되면 트래픽을 이전의 블루 버전에서 새로운 그린 버전으로 전환할 수 있습니다.

이전의 블루 버전에서 새로운 그린 버전으로 전환하는 방법

• Kubernetes 서비스가 사용됩니다.
• 서비스를 이용하면 선택한 pod를 통해 네트워크 트래픽 흐름을 관리할 수 있습니다.
• pod 집합은 라벨 선택기를 사용하여 선택됩니다

블루/그린 배포 장단점

1. 장점은 즉각적인 롤아웃이 가능하고 최신 버전을 전체 사용자층에 출시하기 전에 내부에서 테스트할 수 있다는 것입니다.
   1. 예를 들어, 테스트 사용자 액세스용 별도의 서비스 정의를 사용하는 것이죠
2. 단점은 배포 프로세스 중에 연구 사용량이 두 배로 늘어난다는 것입니다.

카나리아 배포

• 카나리아 메서드는 블루-그린 메서드를 기반으로 한 또 다른 업데이트 전략으로 트래픽이 새 버전으로 점진적으로 이동합니다.
• 카나리아 배포 사용의 주요 이점은 업데이트 중에 초과 리소스 사용량을 최소화할 수 있다는 것입니다.
• 로터는 점진적이기 때문에 애플리케이션의 모든 인스턴스에 영향을 미치기 전에 문제를 식별할 수 있습니다.
• 새 버전의 안정성이 확인되면 트래픽의 100%가 새 버전으로 라우팅 됩니다.

새 버전의 안전성이 확인되면 새 버전으로 라우팅 되는데 어떻게 가능한가?

• 트래픽은 서비스에 정의된 버전을 실행하는 포드로만 전송됩니다.
• 카나리아 업데이트 전략에서 서비스 선택기는 애플리케이션 라벨을 기준으로 하며 버전을 지정하지 않습니다.
• 서비스의 이 카나리아 업데이트 전략 버전에서는 버전 라벨과 관계없이 트래픽이 모든 포드로 전송됩니다 이 설정을 사용하면 서비스가 두 배포 모두에서 트래픽을 선택하고 해당 부분으로 보낼 수 있습니다 처음에 새 버전의 배포는 실행되는 복제본 0개로 시작하나 시간 경과에 따라 새 버전이 수직 확장되면서 이전 버전의 배포는 축소되어 결국 삭제될 수 있습니다.

카나리아 업데이트 전략

• kubectl rollout undo 명령어를 사용하여 롤백합니다.
• 간단한 rollout undo 명령어는 배포를 이전 버전으로 되돌립니다.
• 버전 번호를 지정하여 특정 버전으로 롤백할 수 있습니다.
• 변경사항이 확실하지 않은 경우 kubectl rollout history 명령어를 사용하여 출시 기록을 검사할 수 있습니다.
• Cloud Console에는 직접 롤백 기능이 없습니다 그러나 Console에서 Cloud Shell을 시작하고 이러한 명령어를 사용할 수 있습니다.
• Cloud Console에는 요약 및 생성 일과 함께 버전 목록도 표시됩니다 기본적으로 이전 복제본 세트 10개에 대한 세부 정보는 롤백할 수 있도록 유지됩니다 배포 사양에서 업데이트 기록 한도를 지정하여 기본값을 변경할 수 있습니다.

배포 관리

• 배포를 편집하면 이 작업이 일반적으로 자동 출시를 트리거하는데 사소한 수정사항이 자주 출시되는 환경인 경우 많은 출시가 발생하게 됩니다. 이와 같은 상황에서는 문제와 특정 출시를 연결 짓는 것이 더욱 어렵습니다.
• kubectl rollouts pause 명령어를 사용하여 일시적으로 출시를 중단하는 게 도움이 됩니다.
  • 일시중지 전 배포의 초기 상태는 기능을 계속하지만 배포에 적합한 새 업데이트는 출시가 전달되는 동안 영향을 미치지 않으며 출시가 재개된 후에만 변경사항이 구현됩니다.
• 출시를 재개하면 모든 새로운 변경사항이 단일 버전으로 출시됩니다.
• kubectl delete 명령어를 사용하여 쉽게 삭제할 수 있으며 GCP Console에서 삭제할 수도 있습니다.
• kubectl rollout status 명령어를 사용하여 출시 상태를 모니터링할 수도 있습니다.
• Kubernetes는 배포에서 관리하는 모든 리소스, 특히 실행 중인 포드를 삭제합니다.

개요

Google Kubernetes Engine (GKE)은 Google 인프라를 사용하여 컨테이너화 된 애플리케이션을 배포, 관리 및 확장하기 위한 관리형 환경을 제공한다. Kubernetes Engine 환경은 컨테이너 클러스터 를 형성하기 위해 그룹화된 여러 머신(특히 Compute Engine 인스턴스)으로 구성된다. 이 실습에서는 GKE를 사용하여 컨테이너 생성 및 애플리케이션 배포를 실습한다.

Google Kubernetes Engine을 사용한 클러스터 오케스트레이션

Kubernetes는 인기 있는 Google 서비스를 실행하고 애플리케이션 컨테이너에 대한 자동 관리, 모니터링, 자동 확장, 롤링 업데이트 등 동일한 이점을 제공하는 동일한 설계 원칙을 사용한다.

GKE 클러스터의 이점

• Compute Engine 인스턴스의 부하 분산
• 추가 유연성을 위해 클러스터 내에서 노드의 하위 집합을 지정하는 노드 풀
• 클러스터의 노드 인스턴스 수 자동 조정
• 클러스터의 노드 소프트웨어에 대한 자동 업그레이드
• 노드 상태 및 가용성을 유지하기 위한 노드 자동 복구
• 클러스터에 대한 가시성을 위한 Cloud Monitoring으로 로깅 및 모니터링

GKE 명령어

gcloud container clusters create [CLUSTER-NAME]

클러스터는 하나 이상의 클러스터 마스터 시스템과 노드라고 하는 여러 작업공간으로 시스템으로 구성된다.

위의 명령어는 클러스터를 생성하는 명령어입니다. 또한 클러스터의 이름은 문자로 시작하고 영어 또는 숫자로 끝나야 하며 40자를 초과할 수 없다. 클러스터를 생성하는데 시간이 걸릴 수도 있습니다.

gcloud container clusters get-credentials [CLUSTER-NAME]

클러스터를 만든 후 클러스터와 상호 작용하려면 인증 자격 증명이 필요합니다. 클러스터를 인증을 진행하는 명령어입니다.

kubectl create deployment hello-server --image=gcr.io/google-samples/hello-app:1.0

--image배포할 컨테이너 이미지를 지정합니다.
 gcr.io/google-samples/hello-app:1.0가져올 특정 이미지 버전을 나타냅니다. 
 버전을 지정하지 않으면 최신 버전이 사용됩니다.

위의 명령어는 컨테이너 이미지에서 새 배포를 만들기 위한 명령어이다. 이제 컨테이너화된 애플리케이션을 클러스터에 배포할 수 있습니다. 이 실습에서는 hello-app클러스터에서 실행한다. GKE는 Kubernetes 객체를 사용하여 클러스터의 리소스를 만들고 관리한다. 또한 Kubernetes는 웹 서버와 같은 상태 비저장 애플리케이션을 배포하기 위한 Deployment 개체를 제공한다. 서비스 객체는 인터넷에서 애플리케이션에 액세스하기 위한 규칙과 로드 밸런싱을 정의합니다. 이 명령어는 hello-server의 Deployment 개체를 만듭니다. Container Registry 버킷에서 예시 이미지를 가져옵니다.

kubectl expose deployment hello-server --type=LoadBalancer --port 8080

--port컨테이너가 노출하는 포트를 지정합니다.
type="LoadBalancer"컨테이너에 대한 Compute Engine 부하 분산기를 만듭니다.

위의 명령어는 애플리케이션을 외부 트래픽에 노출할 수 있는 Kubernetes 서비스를 생성하는 명령어입니다.

kubectl get service

Kubernetes 서비스에 대한 정보와 쿠버네티스 서비스를 확인하는 명령어입니다.

kubectl get service

외부 IP 주소가 생성되는 데 시간이 조금 걸릴 수 있습니다. EXTERNAL-IP열 상태가 pending인 경우 위의 명령어를 다시 실행하면 EXTERNAL-IP 정상적으로 나오는 것을 확인하실 수 있습니다.

http://[EXTERNAL-IP]:8080

위에서 확인했던 EXTERNAL-IP와 :8080을 브라우저 주소창에 입력하면 위의 화면이 나오는 것을 확인하실 수 있습니다.

화면에 Hello, world! 메시지가 표시되고 버전 및 호스트 이름도 잘 나오는 것을 확인하실 수 있습니다.

gcloud container clusters delete [CLUSTER-NAME]

위의 명령어는 클러스터를 삭제하는 명령어이다.

1. 클러스터를 삭제 하려면 다음 명령어를 실행하세요.
2. 메시지가 표시되면 Y를 입력하여 확인합니다.

클러스터를 삭제하는 데 시간이 조금 걸릴 수 있습니다.