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는 배포에서 관리하는 모든 리소스, 특히 실행 중인 포드를 삭제합니다.

Kubernetes의 작동 방식을 파악하기 위한 선행 개념

1. Kubernetes 객체 모델
   1. Kubernetes가 관리하는 각 항목은 객체로 표시되며 이러한 객체의 속성과 상태를 확인하고 변경할 수 있습니다.
   2. Kubernetes 객체는 클러스터에서 실행 중인 항목의 상태 (원하는 상태 및 현재 상태)를 나타내는 영구 항목으로 정의됩니다.
   3. 다양한 종류의 객체는 컨테이너화 된 애플리케이션 사용 가능한 리소스, 해당 동작에 영향을 미치는 정책을 나타냅니다.
2. 선언적 관리 원칙
   1. Kubernetes를 사용한다면 관리되고 있는 객체에 대해 원하는 상태를 지정해야 합니다.
   2. Kubernetes가 객체를 해당 상태로 전환하여 유지하게 됩니다.(감시 루프 사용)

Kubernetes 객체의 두 가지 중요한 요소

1. 만들려는 각 객체에 대해 '객체 사양'을 Kubernetes에 제공합니다 이 사양에 원하는 특성을 제공하여 객체의 원하는 상태를 정의합니다.
   1. '객체 상태'는 Kubernetes 제어 영역에서 제공하는 객체의 현재 상태입니다.
   2. 각 객체는 Kubernetes가 호출하는 특정 유형 또는 종류입니다.
2. 'Kubernetes 제어 영역'이란 여러 시스템 프로세스를 가리키며 이 프로세스들의 상호작용을 통해 Kubernetes 클러스터가 작동합니다.

포드란?

1. 포드는 표준 Kubernetes 모듈의 기본 구성 요소이며 배포 가능한 가장 작은 Kubernetes 객체입니다. Kubernetes 시스템에서 실행 중인 모든 컨테이너가 포드입니다.
2. 포드는 컨테이너가 위치한 환경을 구현하며 해당 환경은 하나 이상의 컨테이너를 수용할 수 있습니다.
3. 포드에 컨테이너가 두 개 이상 있는 경우 긴밀하게 결합되어 네트워킹 및 스토리지를 포함한 리소스를 공유합니다.
4. Kubernetes는 각 포드에 고유한 IP 주소를 할당합니다. 포드 내의 모든 컨테이너는 네트워크 네임스페이스를 공유하며 여기에는 IP 주소 및 네트워크 포트가 포함됩니다.
5. 동일한 포드 내의 컨테이너는 로컬 호스트 127.0.0.1을 통해 통신할 수 있습니다.
6. 포드는 컨테이너 간에 공유할 스토리지 볼륨 모음을 지정할 수 있습니다.

https://kubernetes.io/ko/docs/concepts/workloads/pods/

포드의 간단한 예

1. nginx 웹 서버 인스턴스 3개가 각각 컨테이너에서 항상 실행 중인 상태로 필요하다고 가정한다.
2. Kubernetes는 선언적 관리 원칙을 구현합니다. 객체를 선언하여 nginx 컨테이너에 이러한 객체를 나타냅니다. 어떤 종류의 객체일까요? 바로 포드입니다. 이제 Kubernetes가 이러한 포드를 실행하고 유지하는 작업을 맡습니다. 하지만 포드는 자가 복구되지 않는다는 점에 주의하세요 모든 nginx 웹 서버를 유지하는 동시에 하나의 팀으로 함께 작동하기를 원한다면 더 정교한 종류의 객체를 사용하도록 요청할 수 있습니다.
3. Kubernetes에 원하는 상태, 즉 항상 실행 중인 3개의 nginx로 구성된 상태를 지정했다고 가정합시다.
4. 해당 상태를 나타내는 하나 이상의 객체를 만들고 유지하도록 Kubernetes에 지시하여 이 작업을 실행했습니다 그러면 Kubernetes는 원하는 상태를 현재 상태와 비교합니다 3개의 nginx 컨테이너에 대한 선언이 완전히 새로운 선언이라고 가정하면 현재 상태가 원하는 상태와 일치하지 않으므로 Kubernetes, 정확히 말하면 Kubernetes의 제어 영역이 상황을 해결할 것입니다 선언한 객체에서는 실행 중이어야 하는 포드의 수가 3개인데 현재 0개가 실행 중이므로 3개가 되도록 시작합니다 또한 Kubernetes 제어 영역은 클러스터의 상태를 지속적으로 모니터링하여 선언된 상태와 현재를 끊임없이 비교하고 필요에 따라 상태를 수정합니다.

Kubernetes 클러스터

• 클러스터에는 컴퓨터가 필요합니다. 요즘 클러스터를 구성하는 컴퓨터는 일반적으로 가상 머신입니다.
• 한 컴퓨터를 '제어 영역'이라고 하고 다른 컴퓨터를 간단히 '노드'라고 합니다. 노드의 역할은 포드를 실행하는 것이며 제어 영역의 역할은 전체 클러스터를 조정하는 것입니다.
• 몇 가지 중요한 Kubernetes 구성요소가 제어 영역에서 실행됩니다.
• 사용자가 직접 상호작용하는 단일 구성요소는 kube-APIserver이며 이 구성요소의 역할은 클러스터의 상태를 보거나 변경하는 명령어를 수락하는 것으로 여기에는 포드 실행이 포함됩니다.

kube-APIserver

kubectl 명령어

이 명령어의 역할은 kube-APIserver에 연결하고 Kubernetes API를 사용하여 통신하는 것입니다 kube-APIserver는 또한 수신된 요청을 인증하고 요청의 승인 여부와 유효성을 확인하며 허용 제어를 관리합니다.

etcd

실제로 클러스터 상태에 대한 모든 쿼리 또는 변경은 kube-APIserver로 보내져야 합니다.

etcd는 클러스터의 데이터베이스입니다 이는 클러스터의 상태를 안정적으로 저장하는 역할을 합니다 여기에는 모든 클러스터 구성 데이터와 많은 동적 정보(클러스터의 일부인 노드, 실행해야 하는 포드, 실행 위치)가 포함됩니다 사용자는 etcd와 직접 상호작용하지 않습니다. kube-APIserver가 시스템의 나머지 부분을 대신하여 데이터베이스와 상호작용합니다.

kube-scheduler

포드를 노드에 예약하는 역할을 합니다 이를 위해 각 개별 포드의 요구사항을 평가하고 가장 적합한 노드를 선택합니다.

노드에서 포드를 시작하는 작업

하지만 실제로 노드에서 포드를 시작하는 작업은 수행하지 않습니다. 대신 노드에 아직 할당되지 않은 포드 객체를 발견할 때마다 노드를 선택하고 해당 노드의 이름을 포드 객체에 작성합니다. 그러면 시스템의 또 다른 구성요소가 포드를 시작하는 역할을 합니다.

kube-scheduler는 포드 실행 위치를 어떻게 결정할까요?

• kube-scheduler는 모든 노드의 상태를 파악하고 하드웨어, 소프트웨어, 정책을 기반으로 포드가 실행될 수 있는 위치에 대해 여러분이 정의한 제약조건도 준수합니다.
• 예를 들어 특정 포드에 대해 메모리 용량이 일정 수준인 노드에서만 실행되도록 지정할 수 있습니다 또한 어피니티 사양을 정의하여 포드 그룹이 동일한 노드에서 실행되도록 할 수도 있고 안티 어피니티 사양으로 포드가 동일한 노드에서 실행되지 않게 할 수도 있습니다.

kube-controller-manager

• kube-APIserver를 통해 클러스터 상태를 지속적으로 모니터링합니다 클러스터의 현재 상태가 원하는 상태와 일치하지 않을 때마다 kube-controller-manager는 원하는 상태를 달성하기 위해 변경을 시도합니다 이를 '컨트롤러 관리자'라고도 하는데 많은 Kubernetes 객체가 컨트롤러라는 코드 루프에 의해 관리되기 때문입니다 이러한 코드 루프는 해결 프로세스를 처리합니다.
• 다른 종류의 컨트롤러에는 시스템 수준의 책임이 있습니다 예를 들어 노드 컨트롤러의 역할은 노드가 오프라인 상태일 때 모니터링하고 응답하는 것입니다.

kube-cloud-manager

• 기본 클라우드 제공업체와 상호작용하는 컨트롤러를 관리합니다.
• 예를 들어 Kubernetes 클러스터를 Google Compute Engine에서 수동으로 시작하면 kube-cloud-manager는 필요할 때 부하 분산기 및 스토리지 볼륨과 같은 Google Cloud 기능을 가져오는 역할을 합니다.
• 각 노드는 제어 영역 구성요소의 작은 그룹도 실행합니다.
• 예를 들어 각 노드는 Kubelet을 실행합니다. Kubelet은 각 노드에 있는 Kubernetes의 에이전트와 같습니다. kube-APIserver가 노드에서 포드를 시작하려고 하면 해당 노드의 Kubelet에 연결됩니다. Kubelet은 컨테이너 런타임을 사용하여 포드를 시작하고 준비 프로브 및 활성 프로브를 포함한 수명 주기를 모니터링하고 Kube-APIserver에 다시 보고합니다.
• 컨테이너 런타임은 컨테이너 이미지에서 컨테이너를 시작하는 방법을 아는 소프트웨어입니다.

Google Kubernetes Engine 관련 개념

• Kubernetes 클러스터를 직접 설정하는 작업은 아주 복잡합니다. 다행히 오픈소스 명령어 kubeadm으로 클러스터 초기 설정의 대부분을 자동화할 수 있습니다. 그러나 노드가 실패하거나 노드 유지보수가 필요한 경우 관리자가 수동으로 응답해야 합니다.
• 사용자의 관점에서 보면 훨씬 더 간단합니다. GKE는 사용자를 대신하여 모든 제어 영역 구성요소를 관리합니다. GKE는 IP 주소를 노출하고 그 주소로 모든 Kubernetes API 요청을 사용자가 보내지만 GKE가 사용자를 대신하여 모든 제어 영역 인프라를 프로비저닝하고 관리합니다. 또한 별도의 제어 영역을 추상화합니다.

노드

• 모든 Kubernetes 환경에서 노드는 Kubernetes 자체가 아닌 클러스터 관리자가 외부에서 만듭니다.
• GKE는 이 프로세스도 자동화합니다 Compute Engine 가상 머신 인스턴스를 시작하고 노드로 등록합니다. Cloud Console에서 바로 노드 설정을 관리할 수 있습니다.
• 노드에 설정된 시간당 요금이 부과됩니다.(제어 영역 제외) 노드는 Compute Engine에서 실행되므로 클러스터를 만들 때 노드 머신 유형을 선택할 수 있습니다.

https://kubernetes.io/ko/docs/concepts/architecture/nodes/

노드 머신

• 기본적으로 노드 머신 유형은 n1-standard-1이며 가상 CPU 1개와 3.75GB의 메모리를 제공합니다.
• 일반적으로 최대 96개의 가상 CPU 코어를 사용할 수 있으며 이는 가상 머신으로서는 다소 큰 편에 속합니다 노드의 코어 수와 메모리 용량은 맞춤 설정할 수 있으며 CPU 플랫폼을 선택할 수 있습니다 노드 또는 노드 풀에 대한 기본 최소 CPU 플랫폼을 선택할 수 있으므로 노드 성능을 개선할 수 있습니다 GKE는 절대로 사용자가 지정한 것보다 오래된 CPU 플랫폼을 사용하지 않고 더 최신 플랫폼을 선택하는 경우 비용은 지정된 플랫폼과 동일합니다.

노드 풀

• 여러 노드 머신 유형을 선택하려면 여러 노드 풀을 만들면 됩니다. 노드 풀은 클러스터 내 노드의 하위집합으로 메모리 용량 또는 CPU 세대와 같은 구성을 공유합니다. 또한 노드 풀을 통해 손쉽게 워크로드가 클러스터 내의 올바른 하드웨어에서 실행되도록 할 수 있습니다. 원하는 노드 풀로 워크로드의 레이블을 지정하기만 하면 됩니다. 노드 풀은 Kubernetes 기능이 아니라 GKE 기능입니다.
• 오픈소스 Kubernetes 내에서 유사한 메커니즘을 구축할 수 있지만 이 경우 직접 유지 관리해야 합니다 이 노드 풀 수준에서 자동 노드 생성, 자동 노드 복구 클러스터 자동 확장을 사용 설정할 수 있습니다.
• 여기에는 주의할 점이 있습니다 각 노드의 CPU 및 메모리 일부는 노드가 클러스터의 일부로 작동하게 하는 GKE와 Kubernetes 구성요소를 실행하는 데 필요합니다 예를 들어 15GB의 메모리가 있는 노드를 할당하면 15GB 모두를 포드에서 사용할 수는 없습니다.

클러스터

• 클러스터는 단일 Google Cloud 컴퓨팅 영역에서 시작되며 하나의 노드 풀에 3개의 동일한 노드가 있습니다 노드 수는 클러스터 생성 중 또는 생성 후에 변경할 수 있습니다.
• 더 많은 노드를 추가하고 애플리케이션의 여러 복제본을 배포하면 애플리케이션의 가용성이 일정 수준까지는 향상됩니다.

GKE 리전 클러스터

• 전체 컴퓨팅 영역이 다운됬을 때 GKE 리전 클러스터를 사용하면 이 문제를 해결할 수 있습니다.
• 리전 클러스터에는 클러스터에 대한 단일 API 엔드포인트가 있습니다. 그러나 제어 영역과 노드는 한 리전 내의 여러 Compute Engine 영역에 분산되어 있습니다. 리전 클러스터는 애플리케이션의 가용성이 단일 리전 내의 여러 영역에서 유지되도록 합니다.
• 또한 제어 영역의 가용성도 유지되므로 애플리케이션과 관리 기능 모두가 몇몇 영역이 손실되어도 유지됩니다. (전체 영역 손실 시 유지되지 않습니다)
• 기본적으로 리전 클러스터는 3개의 영역에 분산되어 있고 각 영역에는 제어 영역 1개와 노드 3개가 있습니다. 이 수는 늘리거나 줄일 수 있습니다.
• 영역 클러스터를 빌드한 후에는 리전 클러스터로 변환할 수 없으며 그 반대의 경우도 마찬가지입니다.
• 리전 별 또는 영역별 GKE 클러스터를 비공개 클러스터로도 설정할 수 있습니다. 전체 클러스터, 즉 제어 영역 및 해당 노드는 공개 인터넷에서 숨김 처리됩니다.

Kubernetes 객체 관리

• 모든 Kubernetes 객체는 고유한 이름과 고유 식별자로 구분됩니다.
• Kubernetes가 만들고 유지할 객체를 매니페스트 파일을 사용하여 정의했습니다.

매니페스트 파일

이는 일반 텍스트 파일입니다. YAML 또는 JSON 형식으로 작성할 수도 있습니다. YAML은 사람이 읽기 쉽고 수정이 덜 번거롭다. 이 YAML 파일은 포드에 대한 원하는 상태 즉 이름과 실행할 특정 컨테이너 이미지를 정의합니다.

매니페스트 파일의 특정 필수 필드

• apiVersion은 객체를 만드는 데 사용되는 Kubernetes API 버전을 나타냅니다 Kubernetes 프로토콜은 이전 버전과의 호환성을 유지할 수 있도록 버전이 지정됩니다.
• kind는 원하는 객체를 정의합니다.
• metadata는 객체를 식별할 수 있도록 이름, 고유 ID, 네임스페이스(선택사항)를 사용합니다. 동일한 YAML 파일에 여러 관련 객체를 정의할 수 있으며 권장사항이기도 합니다. 하나의 파일이 여러 파일보다 관리하기가 쉽다.
• YAML 파일은 버전 관리 저장소에 저장해야 합니다. 이 방법을 사용하면 변경사항을 쉽게 추적 및 관리하고 필요할 때 해당 변경사항을 취소할 수 있습니다. 이는 클러스터를 다시 만들거나 복원해야 하는 경우에도 큰 도움이 됩니다.
• Kubernetes 객체를 만들 때 이름을 문자열로 지정합니다. 이름은 고유해야 합니다. 특정 종류의 객체 하나만 한 Kubernetes 네임스페이스에서 특정 이름을 가질 수 있습니다. 그러나 객체가 삭제되면 이름을 다시 사용할 수 있습니다. 이름에는 영숫자 문자, 하이픈, 마침표를 사용할 수 있으며 최대 문자 길이는 253자입니다.
• 클러스터의 수명 주기 중에 만든 모든 객체에는 Kubernetes에서 생성된 고유 ID(UID)가 할당됩니다 즉, 클러스터의 수명 주기 중에는 두 객체에 한 UID가 할당되지 않습니다.
• 라벨은 키-값 쌍이며, 이를 사용하여 생성 중이나 생성 후에 객체를 태그 합니다 라벨은 객체와 객체의 하위 집합을 식별하고 구성하는 데 도움이 됩니다. 예를 들어 'app'이라는 라벨을 만들고 이 객체가 속한 애플리케이션을 값으로 지정할 수 있습니다.
• 라벨에 특정 값이 있는 모든 리소스 또는 특정 값이 없는 모든 리소스 또는 사용자가 제공하는 집합에 값이 있는 모든 리소스를 요청할 수 있습니다.
• 200개 이상의 YAML 섹션을 관리하는 것은 매우 어렵겠죠 또 다른 문제가 있습니다. 포드는 스스로 복구되지 않고 영원히 실행되도록 설계된 것도 아닙니다. 포드는 일회성, 임시적 용도로 설계되었습니다. 이러한 이유로 Kubernetes에서 실행하는 항목을 관리하는 데에는 개별 포드를 지정하는 것보다 더 효과적인 방법이 있습니다. 이와 같은 설정을 통해 애플리케이션의 고가용성을 수평적 확장과 함께 유지할 수 있습니다. 그보다는 컨트롤러 객체를 선언하여 포드의 상태를 관리하게 할 수 있습니다.

https://kubernetes.io/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/

배포

• 배포는 웹 서버와 같이 수명이 긴 소프트웨어 구성요소에 적합하며 특히 구성요소를 그룹으로 관리하려는 경우에 더욱 적합합니다.
• 이 예시에서 kube-scheduler가 배포용 포드를 예약할 때 kube-APIserver에 알립니다.
• 이러한 변경사항은 컨트롤러 특히 배포 컨트롤러가 지속적으로 모니터링합니다. 배포 컨트롤러가 nginx 포드 3개를 모니터링하고 유지합니다. 이 포드 중 하나가 실패하면 배포 컨트롤러는 현재 상태와 원하는 상태의 차이를 인식하고 새 포드를 시작하여 문제를 해결하려고 합니다. 각 포드에 여러 YAML 매니페스트 또는 파일을 사용하는 대신 단일 배포 YAML을 사용하여 동일한 컨테이너의 복제본 3개를 시작했습니다. 배포는 정의된 포드 집합이 지정된 시간에 실행되도록 합니다. 객체 사양 내에서 원하는 복제본 포드의 개수 포드 실행 방법 이러한 포드 내에서 실행할 컨테이너, 마운트 할 볼륨을 지정하게 됩니다. 이러한 템플릿을 기반으로 컨트롤러는 클러스터 내에서 원하는 포드 상태를 유지합니다.

프로젝트

• 작업을 하다 보면 아마 여러 프로젝트에 단일 클러스터를 사용하게 될 것입니다 동시에 프로젝트 또는 팀을 기반으로 리소스 할당량을 유지하는 것이 중요합니다.
• 각 Kubernetes 클러스터는 하나의 GCP 프로젝트에 연결되어 있는데 이 프로젝트는 공식적 의미의 프로젝트입니다 이를 통해 IAM 정책이 적용되고 비용이 청구되는 것입니다.

네임스페이스

• 어떻게 클러스터의 모든 작업을 체계적으로 정리할 수 있을까요? Kubernetes를 사용하면 단일 물리적 클러스터를 '네임스페이스'라고 하는 여러 가상 클러스터로 추상화할 수 있습니다.
• 네임스페이스는 포드, 배포, 컨트롤러 등 리소스 이름 지정 범위를 제공합니다.
• 동일한 네임스페이스에는 중복된 객체 이름을 사용할 수 없습니다 동일한 이름(nginx)으로 포드 3개를 만들 수 있지만 동일한 네임스페이스를 공유하지 않는 경우에만 가능합니다.
• 네임스페이스 'Test'에서 동일한 이름('nginx Pod')으로 포드를 하나 더 만드는 것은 허용되지 않습니다.
• 객체 이름은 모든 네임스페이스가 아닌 한 네임스페이스 내에서만 고유하면 됩니다. 네임스페이스를 사용하면 클러스터 전체에 리소스 할당량을 적용할 수도 있습니다. 이러한 할당량은 네임스페이스 내의 리소스 사용량 한도를 정의합니다.
• 배포 사본을 빠르게 테스트해 보기 위해 사용한다고 가정해 봅시다 새 네임스페이스에서 이름 충돌 없이 테스트를 간단하게 수행할 수 있습니다 .
• 워크로드 리소스는 기본적으로 이 네임스페이스를 사용합니다.
• 네임스페이스를 만들 때 네임스페이스에 리소스를 적용하려면 명령줄 네임스페이스 플래그를 사용하거나 리소스에 대한 YAML 파일에 네임스페이스를 지정할 수 있습니다.

Kube-system 네임스페이스

• Kubernetes 시스템 자체에서 만든 객체를 포함합니다.
• kubectl 명령어를 사용하면 기본적으로 Kube-system 네임스페이스의 항목이 제외되지만 콘텐츠를 확인하도록 명시적으로 선택할 수 있습니다.
• Kube-public 네임스페이스는 모든 사용자가 읽을 수 있도록 공개된 객체를 포함합니다. Kube-public은 클러스터에서 실행되는 모든 객체에 정보를 배포하기 위한 도구입니다. 반드시 사용할 필요는 없지만 클러스터에서 실행되는 모든 객체가 동일한 목표와 관련이 있고 공통 정보가 필요한 경우 특히 유용할 수 있습니다.

서비스

서비스는 지정된 포드에 대한 로드 밸런싱 액세스를 제공합니다. 다음의 세 가지 주요 유형이 있다.

1. 클러스터IP: 이 내에서만 액세스 할 수 있는 IP 주소에 서비스를 노출합니다.
2. NodePort: 클러스터에 있는 각 노드의 IP 주소에 서비스를 표시합니다.
3. 로드 밸런서: 다음에서 제공하는 로드 밸런싱 서비스를 사용하여 서비스를 외부에 노출합니다.

Google Kubernetes Engine에서 로드 밸런서는 지역 네트워크 로드에 대한 액세스를 제공합니다.

기본적으로 구성 균형을 조정합니다. 전역 HTTP(S) 부하 분산에 접근하려면 구성, 수신 개체를 사용할 수 있습니다.

컨트롤러 개체 간의 관계

1. ReplicaSets
2. Deployments
3. Replication Controllers
4. StatefulSets
5. DaemonSets
6. Jobs

ReplicaSet 컨트롤러는 모든 Pods의 모집단이 서로 동일하도록 보장한다. 배포를 통해 ReplicaSet 및 Pods에 대한 선언적 업데이트를 수행할 수 있습니다. 실제로 Deployments는 선언적 목표를 달성하기 위해 자체 ReplicaSet을 관리합니다. 가장 일반적으로 Deployments 개체로 작업할 수 있도록 을 지정합니다. Deployments 기능을 사용하면 필요에 따라 ReplicaSet을 사용하여 Pod를 생성, 업데이트, 롤백 및 확장할 수 있습니다. 예를 들어 Deployments의 롤링 업그레이드를 수행할 때 두 번째 ReplicaSet을 만든 다음 새 ReplicaSet의 포드 수를 늘립니다. 원본 ReplicaSet의 포드 수를 줄입니다. 복제 컨트롤러는 ReplicaSets 및 Deployments는 하지만 더 이상 사용하지 않는 것이 좋습니다. Deployments는 유용한 기능을 제공하기 때문입니다. 로컬 상태를 유지하는 애플리케이션을 배포해야 하는 경우 StatefulSet이 더 나은 옵션입니다. StatefulSet은 포드가 동일한 컨테이너 사양을 사용한다는 점에서 배포와 유사합니다. 배포를 통해 생성된 ID에는 영구 ID가 부여되지 않습니다. 대조적으로 Pods는 StatefulSet을 사용하여 생성된 것은 안정적인 네트워크 ID와 함께 고유한 영구 ID를 가지고 있다. 클러스터 내의 모든 노드 또는 선택한 노드에서 특정 팟을 실행해야 하는 경우는 DaemonSets. DaemonSet은 특정 Pod가 항상 모든 부분 집합 또는 일부 부분 집합에서 실행되도록 보장합니다. 새 노드가 추가되면 DaemonSet이 자동으로 해당 노드에 Pods를 설정합니다. 다른 프로세스에 유용한 서비스를 제공하는 무중단 프로세스입니다. Kubernetes cluster는 DaemonSet을 사용하여 fluentd와 같은 로깅 에이전트가 의 모든 노드에서 실행되도록 할 수 있습니다. 작업 컨트롤러는 태스크를 실행하는 데 필요한 하나 이상의 포드를 생성합니다. 작업이 완료되면, 그러면 Job이 모든 팟을 종료합니다. 관련 컨트롤러는 CronJob으로, 팟을 실행한다.

Migrate for Anthos

• Google Cloud의 컨테이너화 된 배포로 가져오기 위한 도구입니다.
• 프로세스가 자동화되어 있다 워크로드는 온프레미스이거나 다른 클라우드 제공업체에 있을 수 있습니다. 앞서 말씀드렸듯이 Migrate for Anthos는 자동화되어 있으며 속도도 매우 빠릅니다. 대부분의 마이그레이션은 10분 이내에 완료되며 한 번에 애플리케이션 데이터를 마이그레이션 하거나 또는 애플리케이션이 활성화될 때까지 클라우드로 스트리밍 하는 방식 중에서 선택할 수 있습니다.

Introduction to Containers and Kubernetes

기본 배포 방식 vs 가상화

기본 배포 방식

1. 애플리케이션을 배포하는 기본 방식은 실제 컴퓨터에 배포하는 것이었다.
2. 앱을 설치하려면 물리적 공간, 전원 냉각 장치, 네트워크 연결을 준비한 후 운영체제를 깔고 소프트웨어 종속 항목을 먼저 설치해야 한다.

기본 배포 방식의 문제점

1. 리소스 낭비가 크고 대규모 배포와 유지보수에 많은 시간이 소요된다.
2. 이동하기가 매우 어렵다.
3. 애플리케이션은 특정 운영체제에 맞게 빌드되었고 특정 하드웨어에 맞춰 빌드되는 경우도 있다.

가상화 이점

1. 가상화를 통해 여러 가상 서버와 운영체제를 동일한 물리적 컴퓨터에서 실행할 수 있다.
2. 하이퍼바이저는 소프트웨어 레이어로서 기본 하드웨어에서 운영체제의 종속성을 해소하여 여러 가상 머신이 하드웨어 하나를 공유할 수 있다.
3. 새 서버를 빠르게 배포할 수 있습니다.
4. 새 솔루션 배포 시간이 짧아집니다.
5. 가상 머신은 이미지를 만들어 이동할 수 있기 때문에 사용하는 물리적 컴퓨터의 리소스 낭비가 줄어들고 이동성이 향상된다.

VM의 문제점

1. 애플리케이션, 모든 종속 항목과 운영체제는 여전히 번들로 묶여 있습니다.
2. VM을 하이퍼바이저 제품 간에 이동하는 것은 쉽지 않다.
3. VM을 시작할 때마다 운영체제를 부팅하는 시간이 소요됩니다.
4. 단일 VM에서 여러 애플리케이션을 실행 시 문제점
   1. 종속 항목을 공유하는 애플리케이션이 서로 격리되지 않는 문제가 있다.
   2. 특정 애플리케이션의 리소스 요구사항 때문에 다른 애플리케이션에서 필요한 리소스를 확보하지 못할 수 있다.
   3. 특정 애플리케이션의 종속 항목 업그레이드로 인해 다른 애플리케이션이 실행 중지될 수 있습니다.
5. 위와 같은 문제를 엄격한 소프트웨어 엔지니어링 정책으로 문제 해결을 할 수 있다.
   1. 종속 항목은 종종 업그레이드가 필요하다.
   2. 애플리케이션 작동을 확인하는 통합 테스트를 추가할 수 있다.
   3. 종속 항목 문제가 새 장애를 일으키고 해결이 어려울 수도 있다.
   4. 애플리케이션 환경의 기본 무결성을 확인하기 위해 통합 테스트를 이용해야 하는 경우 개발 속도가 크게 저하된다.
6. 종속 항목을 잠그고 어느 애플리케이션에서도 이를 변경할 수 없도록 할 수 있지만 새 문제가 생깁니다.

VM 중심으로 이 문제를 해결하는 방법

1. 애플리케이션마다 전용 가상 머신을 실행하는 것 수십만 개 애플리케이션으로 확장하면 문제가 발생한다.
   1. 대규모 시스템의 경우 전용 VM은 중복적이며 낭비입니다.
   2. 전체 운영체제를 부팅해야 하기 때문에 VM은 시작하는 속도가 비교적 느리다.
2. 각 애플리케이션에서 고유 종속 항목을 유지 관리하고 커널이 격리되어 있으므로 애플리케이션끼리 성능에 영향을 미치지 않습니다.
3. 종속 항목 문제를 더 효율적으로 해결하려면 애플리케이션과 종속 항목 수준에서 추상화를 구현한다.
4. 전체 머신 또는 전체 운영체제가 아니라 사용자 공간만 가상화하면 됩니다.

컨테이너란?

• 사용자 공간은 커널 위에 있는 모든 코드이며 애플리케이션과 종속 항목을 포함합니다. 이것이 컨테이너를 만든다는 의미이다.
• 컨테이너는 단일 애플리케이션 코드를 실행하는 격리된 사용자 공간이다.

컨테이너의 장점

1. 운영체제 전체를 실행하지 않으므로 가볍다.
2. 기본 시스템 위에서 예약하고 패키징 하므로 매우 효율적이다.
3. 컨테이너는 아주 빠르게 만들고 종료할 수 있다.
4. 애플리케이션을 구성하는 프로세스만 시작 또는 중지하고 전체 VM을 부팅하거나 각 애플리케이션의 운영체제를 초기화하지 않기 때문입니다.
5. 시스템의 나머지는 신경 쓰지 않아도 된다.
   1. VM에서 최종 코드를 실행할 때 소프트웨어 종속 항목 즉 애플리케이션 런타임, 시스템 도구 시스템 라이브러리, 기타 설정에 신경 쓰지 않아도 됩니다
6. 가볍고 독립적이고 리소스 효율이 높으며 이동성이 우수한 실행 패키지이다.

개발자 관점 컨테이너 이점

1. 애플리케이션 중심으로 확장성 높은 고성능 애플리케이션을 제공하기 때문이다.
2. 컨테이너를 사용하면 개발자가 기본 하드웨어와 소프트웨어를 전제로 작업할 수 있다.
3. 모든 환경에서 동일한 컨테이너가 동일하게 실행된다.
4. 개발 프로세스가 빨라진다.
   1. 프로덕션 이미지를 기반으로 컨테이너를 점진적으로 변경하고 파일 복사 한 번으로 이를 빠르게 배포할 수 있습니다.
5. 컨테이너는 애플리케이션을 쉽게 빌드할 수 있다.
   1. 애플리케이션은 마이크로 서비스 설계 패턴 즉, 느슨하게 결합되고 세분화된 구성요소를 사용합니다.
   2. 이 모듈식 설계 패턴은 운영체제를 확장하고 애플리케이션의 구성요소를 업그레이드하면서도 전체 애플리케이션에는 영향을 주지 않습니다

컨테이너 설명

애플리케이션과 종속 항목을 '이미지'라고 합니다. 간단히 말해 컨테이너는 실행 중인 이미지 인스턴스입니다.

1. 컨테이너는 Linux 네임스페이스를 사용하여 애플리케이션에 제공할 항목인 프로세스 ID 번호, 디렉터리 트리, IP 주소 등을 제어합니다.
2. 컨테이너는 Linux cgroup으로 애플리케이션이 사용할 수 있는 CPU 시간, 메모리, I/O 대역폭 기타 리소스의 최대 사용량을 제어합니다.
3. 컨테이너는 유니온 파일 시스템을 사용하여 애플리케이션과 종속 항목을 간결한 최소 레이어 모음으로 효율적으로 캡슐화합니다.
4. 컨테이너 이미지는 여러 레이어로 구조화됩니다.

컨테이너 빌드

• 이미지 빌드에 사용하는 도구는 '컨테이너 매니페스트'라는 파일에서 안내를 읽어옵니다.
• Docker 형식의 컨테이너 이미지의 경우 이를 Dockerfile이라고 합니다.
• Dockerfile의 안내에 따라 컨테이너 이미지 내부 레이어가 지정됩니다. 각 레이어는 읽기 전용입니다. 이 이미지에서 컨테이너를 실행하는 경우 쓰기 가능한 임시 최상위 레이어도 생성됩니다.
• Dockerfile의 명령어 4개는 각각 하나의 레이어를 생성합니다.

Dockerfile 명령어

• FROM 문으로 기본 레이어를 공개 저장소에서 가져와 생성합니다.
• COPY 명령어로 새 레이어를 추가한다.
• RUN 명령어는 make 명령어를 사용하여 애플리케이션을 빌드하고 빌드 결과를 세 번째 레이어에 배치합니다.
• 마지막 레이어는 실행 시 컨테이너 내에 실행할 명령어를 지정합니다.
• Dockerfile을 작성할 때는 변경할 가능성이 가장 낮은 레이어에서 변경할 가능성이 가장 높은 레이어로 구성해야 합니다.
• 요즘은 배포 및 실행하는 컨테이너에 애플리케이션을 빌드하는 것은 권장하지 않습니다.
• 요즘은 애플리케이션 패키징에 다단계 빌드 프로세스를 이용하는데 이 경우 한 컨테이너에서 최종 실행 가능한 이미지를 빌드하고 다른 컨테이너에는 애플리케이션 실행에 필요한 항목만 포함합니다.

컨테이너 레이어

• 이미지에서 새 컨테이너를 만들면 컨테이너 런타임에서는 쓰기 가능한 레이어를 기본 레이어 위에 추가합니다. 이 레이어를 보통 '컨테이너 레이어'라고 합니다.
• 실행 중인 컨테이너에 대한 새 파일 쓰기, 기존 파일 수정 및 파일 삭제와 같은 모든 변경사항은 쓰기 가능하고 얇은 컨테이너 레이어에 기록됩니다. 각 컨테이너에는 쓰기 가능한 고유의 컨테이너 레이어가 있고 모든 변경사항이 이 레이어에 저장되므로 여러 컨테이너가 동일한 기본 이미지에 액세스 권한을 공유하면서도 자체 데이터 상태를 보유합니다.
• 이는 모두 임시 변경사항이므로 컨테이너가 삭제되면 이 레이어의 내용도 영구 삭제됩니다. 기본 컨테이너 이미지 자체는 변경되지 않은 상태로 유지됩니다. 애플리케이션을 설계할 때 이러한 컨테이너의 특징을 고려해야 합니다. 데이터를 영구적으로 저장하고 싶다면 실행 중인 컨테이너 이미지가 아닌 다른 곳에서 작업해야 합니다.
• 컨테이너를 실행하면 컨테이너 런타임에서 필요한 레이어를 가져옵니다. 업데이트할 때는 차이가 나는 항목만 복사하면 됩니다. 이렇게 하면 새 가상 머신을 실행하는 것보다 훨씬 빠릅니다.

Kubernetes란?

1. Kubernetes는 오픈소스 플랫폼으로서 컨테이너 인프라를 온프레미스 또는 클라우드에서 조정, 관리할 수 있습니다.
2. Kubernetes는 컨테이너 중심의 관리 환경이다.
3. Kubernetes는 컨테이너화 된 애플리케이션의 배포, 확장, 부하 분산, 로깅, 모니터링, 기타 관리 기능을 자동화합니다. 이러한 기능은 전형적인 Platform as a Service 솔루션 특징입니다.
4. Kubernetes는 Infrastructure as a Service 기능도 지원합니다. 예를 들어 다양한 사용자 환경설정과 구성 유연성을 지원합니다.
5. Kubernetes는 선언적 구성을 지원합니다 인프라를 선언적으로 관리하는 경우 일련의 명령어를 실행하는 게 아니라 달성하려는 상태를 설명하여 원하는 상태를 달성합니다.
6. Kubernetes는 배포된 시스템을 원하는 상태로 만들고 장애가 발생해도 상태를 유지합니다. 선언적 구성은 작업 부담을 덜어줍니다. 원하는 시스템 상태가 항상 문서화되어 있기 때문에 오류의 위험도 줄어듭니다.
7. Kubernetes는 명령형 구성도 지원하며 이 경우 명령어를 실행하여 시스템 상태를 변경합니다.
8. Kubernetes의 주요 장점 중 하나가 선언한 시스템 상태를 자동으로 유지할 수 있다는 점입니다.

Kubernetes의 기능

1. Kubernetes는 다양한 워크로드 유형을 지원합니다. Nginx, Apache 웹 서버 같은 스테이트리스(Stateless) 애플리케이션과 사용자 및 세션 데이터를 영구 저장할 수 있는 스테이트풀(Stateful) 애플리케이션을 지원하고 일괄 작업 및 데몬 태스크도 지원합니다.
2. Kubernetes는 리소스 사용률에 따라 컨테이너화 된 애플리케이션을 자동으로 수평 확장 및 축소할 수 있습니다.
3. 워크로드의 리소스 요청 수준과 리소스 한도를 지정하면 Kubernetes가 그대로 준수합니다.
4. Kubernetes는 이처럼 리소스를 제어하여 클러스터 내의 전반적인 워크로드 성능을 개선합니다.
5. 개발자는 Kubernetes를 통해 플러그인, 부가기능을 확장할 수 있습니다.
6. Kubernetes 선언적 관리 모델을 관리가 필요한 매우 다양한 다른 작업에 적용하고 있습니다.
7. Kubernetes는 오픈소스이므로 온프레미스 또는 GCP를 비롯한 여러 클라우드 서비스 제공업체 간 워크로드 이동성도 지원합니다.  따라서 Kubernetes를 어디든 배포할 수 있으며 공급업체의 제약 없이 워크로드를 자유롭게 이동할 수 있습니다.

Google Kubernetes Engine

1. GKE를 사용하면 GCP에서 컨테이너화된 애플리케이션을 위해 Kubernetes 환경을 배포, 관리, 확장할 수 있습니다. 구체적으로 GKE는 GCP 컴퓨팅 기능의 구성 요소이며 이를 통해 Kubernetes 워크로드를 클라우드에 손쉽게 배포할 수 있습니다.
2. GKE는 완전 관리형 서비스로 기본 리소스를 프로비저닝 할 필요가 없습니다. GKE는 컨테이너 최적화 운영체제를 사용합니다. Google이 관리하는 이 운영체제는 빠른 확장에 최적화되어 있으며 리소스 사용은 최소화합니다.
3. GKE를 사용하면 먼저 Kubernetes 시스템을 인스턴스 화하는데 이러한 시스템을 '클러스터'라고 합니다 GKE의 자동 업그레이드 기능을 사용 설정하면 클러스터가 자동으로 업그레이드되어 항상 최신 버전의 Kubernetes로 유지됩니다.
4. Identity and Access Management와도 통합되므로 계정 및 역할 권한을 사용해 액세스를 제어할 수 있습니다.
5. GKE는 Stackdriver Monitoring과 통합되어 애플리케이션 성능을 파악할 수 있게 해 줍니다.
   • Stackdriver는 Google Cloud 시스템으로 서비스, 컨테이너, 애플리케이션, 인프라를 모니터링하고 관리합니다.
6. GKE는 virtual private cloud 즉 VPC와 통합되며 GCP의 네트워킹 기능을 사용합니다.
7. GCP Console은 GKE 클러스터와 리소스에 대한 정보를 제공하며 여기에서 클러스터의 리소스를 확인, 검사, 삭제할 수 있습니다.
8. Kubernetes에는 대시보드가 포함되어 있지만 안전하게 설정하려면 상당한 노력이 필요합니다 하지만 GCP Console은 관리할 필요가 없는 GKE 클러스터 및 워크로드의 대시보드로 Kubernetes 대시보드보다 성능이 훨씬 우수합니다.

노드

1. GKE 클러스터 내에서 컨테이너를 호스팅 하는 가상 머신을 '노드'라고 합니다.
2. GKE의 자동 복구 기능을 사용 설정하면 서비스가 비정상 노드를 자동으로 복구합니다.
3. 각 클러스터 노드에서 정기적으로 상태를 확인합니다. 노드가 비정상 상태로 확인되어 복구가 필요하다면 GKE에서 노드를 드레이닝 즉, 워크로드를 정상적으로 종료하고 노드를 다시 생성합니다.

Compute Engine

1. GCP에서 실행되는 가상 머신을 제공합니다.
2. 사전 정의된 VM 구성을 선택할 수 있습니다. 이 과정이 개발된 시점을 기준으로 이러한 가상 머신의 크기는 3 테라바이트 이상의 메모리를 갖춘 최대 160개의 vCPU에 이릅니다 또한 성능 및 비용 요구사항과 정확히 일치하도록 맞춤 설정된 구성을 생성할 수도 있습니다.
3. 영구 디스크와 로컬 SSD라는 두 가지 주요 옵션을 제공합니다. 초당 입출력 작업 수가 매우 높은 로컬 SSD를 선택할 수도 있습니다. 영구 디스크는 최대 64 테라바이트까지 수직 확장할 수 있는 네트워크 스토리지를 제공하며 백업 및 이동성을 위해 영구 디스크의 스냅샷을 쉽게 만들 수 있습니다.
4. 자동 확장을 지원하는 전역 부하 분산기 뒤에 Compute Engine 워크로드를 배치할 수 있습니다.
5. Compute Engine은 관리형 인스턴스 그룹이라는 기능을 제공합니다.
   • 이 기능을 사용하여 수요를 충족하기 위해 자동으로 배포되는 리소스를 정의할 수 있습니다.
6. GCP는 초당 청구를 제공하여 Compute Engine 리소스 비용을 세부적으로 제어할 수 있습니다. 이러한 세부적인 제어 덕분에 일괄 처리 작업과 같이 짧은 기간에 컴퓨팅 리소스를 배포할 때 비용을 절감할 수 있습니다.
7. Compute Engine은 안전하게 중단될 수 있는 워크로드에 대해 가격이 훨씬 저렴한 선점형 가상 머신을 제공합니다.
8. Compute Engine을 사용하면 인프라를 완전히 제어할 수 있습니다
   • 운영체제를 맞춤 설정하고 여러 운영체제를 사용하는 애플리케이션을 실행할 수도 있습니다.
   • 애플리케이션을 다시 작성하거나 아무것도 변경하지 않아도 온프레미스 워크로드를 GCP로 쉽게 리프트 앤 시프트 할 수 있습니다.
9. 다른 컴퓨팅 옵션이 애플리케이션이나 요구사항을 지원하지 않을 때 선택할 수 있는 가장 좋은 옵션입니다.

App Engine

1. App Engine은 완전 관리형 애플리케이션 플랫폼입니다.
2. App Engine을 사용한다는 것은 실버 관리 및 구성 배포가 필요 없음을 뜻합니다. 개발자라면 배포에 대해 크게 걱정하지 않고 애플리케이션 빌드에 집중할 수 있습니다. 단순히 코드를 사용하기만 하면 App Engine에서 필요한 인프라를 배포합니다.
3. App Engine은 Java, Node.js, Python, PHP, C#, .Net, Ruby, Go 등 많이 사용되는 언어를 지원합니다. 컨테이너 워크로드를 실행할 수도 있습니다.
4. Stackdriver Monitoring, Logging, 디버깅 및 Error Reporting과 같은 진단도 App Engine과 긴밀하게 통합됩니다. Stackdriver를 실시간 디버깅 기능으로 사용하여 소스 코드를 분석하고 디버깅할 수 있습니다. Stackdriver는 Cloud SDK, Cloud Source Repositories, Intelligent, Visual Studio, PowerShell과 같은 도구와 통합됩니다.
5. App Engine은 또한 버전 제어 및 트래픽 분할도 지원합니다.
6. RESTful API는 개발자가 쉽게 작업하고 확장할 수 있으며 App Engine을 사용하면 쉽게 운영할 수 있습니다.

Google Kubernetes Engine

1. Kubernetes는 배포, 확장, 부하 분산, 로깅, 모니터링, 기타 관리 기능을 자동화합니다. Google Kubernetes Engine은 기능을 추가하고 다른 GCP 서비스와 자동으로 통합하여 GCP에서의 Kubernetes 관리를 확장합니다.
2. GKE는 클러스터 확장, 영구 디스크, 최신 버전의 Kubernetes로 자동 업데이트, 비정상 노드에 대한 자동 복구를 지원합니다.
3. GKE는 Cloud Build, Container Registry, Stackdriver Monitoring, Stackdriver Logging과의 통합 기능이 내장되어 있습니다. 온프레미스 클러스터로 실행되는 기존 워크로드는 GCP로 쉽게 이동할 수 있습니다 공급업체에 종속되지 않습니다.
4. GKE는 컨테이너화 된 애플리케이션, 클라우드 기반 분산 시스템, 하이브리드 애플리케이션에 매우 적합합니다.

Cloud Run

1. Cloud Run은 웹 요청 또는 Cloud Pub/Sub 이벤트를 통해 스테이트리스(Stateless) 컨테이너를 실행할 수 있는 관리형 컴퓨팅 플랫폼입니다.
2. Cloud Run은 서버리스입니다 모든 인프라 관리를 추상화하므로 애플리케이션 개발에만 집중할 수 있습니다.
3. Cloud Run을 사용하면 완전 관리형 또는 자체 GKE 클러스터에서 컨테이너를 실행할 수 있습니다.
4. Cloud Run을 사용하면 서버에 대해 걱정할 필요 없이 요청 또는 이벤트 기반 스테이트리스(Stateless) 워크로드를 실행할 수 있습니다.
5. 트래픽에 따라 거의 즉시 0에서 자동으로 확장 및 축소되므로 확장 구성을 걱정할 필요가 없습니다.
6. Cloud Run은 100밀리 초 단위로 계산하여 사용하는 리소스에 대해서만 비용을 청구합니다. 따라서 초과 프로비저닝 된 리소스의 비용을 지불할 필요가 없습니다.
7. Cloud Run은 100밀리 초 단위로 계산하여 사용하는 리소스에 대해서만 비용을 청구합니다 따라서 초과 프로비저닝 된 리소스의 비용을 지불할 필요가 없습니다.
8. HTTP 요청을 통해 전달되는 요청이나 이벤트를 수신 대기하는 스테이트리스(Stateless) 컨테이너를 배포할 수 있습니다.
9. Cloud Run을 사용하면 원하는 프레임워크와 도구를 사용하여 모든 언어로 애플리케이션을 빌드하고 해당 서버 인프라를 관리 및 유지할 필요 없이 단 몇 초 만에 배포할 수 있습니다.

GCP 클라우드 컴퓨팅 기본 속성

1. 컴퓨팅 리소스가 주문형 및 셀프서비스 방식으로 제공됩니다.
2. 클라우드 컴퓨팅 고객은 자동 인터페이스를 사용하므로 사람의 개입 없이 필요한 처리 능력, 스토리지 네트워크를 확보할 수 있습니다.
3. 어디서나 네트워크를 통해 리소스에 액세스 할 수 있습니다. 제공업체에서 대규모 풀의 리소스를 고객에게 할당하므로 고객은 규모의 경제가 주는 이점을 얻습니다.
4. 고객은 이러한 리소스의 정확한 물리적 위치를 파악하거나 신경 쓸 필요가 없습니다. 리소스는 탄력적으로 공급됩니다. 리소스가 추가로 필요하면 신속히 확보할 수 있고 적게 필요하면 축소할 수 있습니다.
5. 마지막으로 고객은 사용하거나 예약하는 만큼만 지불하면 됩니다 리소스 사용을 중단하면 지불도 중단됩니다.

GKE는 Google이 관리하는 클라우드 환경에서 컨테이너화 된 애플리케이션을 실행하며 사용자에게 관리 권한을 부여합니다.

컨테이너화는 이동성을 극대화하고 리소스를 효율적으로 사용할 수 있도록 코드를 패키지화하는 방식으로 Kubernetes는 컨테이너 내부에서 코드를 조정하는 방식으로 이해하면 됩니다.

GKE는 Compute Engine 기반 서비스이다.

Google Cloud Platform이 제공하는 서비스의 이면에는 다양한 리소스가 존재합니다.

1. 물리적 서버와 하드 드라이브 같은 물리적 애셋
2. 가상 머신이나 컨테이너 같은 가상 리소스

모두 Google의 글로벌 데이터 센터에서 관리됩니다.

Google Cloud는 멀티 리전, 리전, 영역을 통해 리소스를 제공합니다.

멀티 리전

1. 전 세계를 크게 세 지역으로 나눕니다. 아메리카, 유럽, 아시아 태평양

리전

1. 3개의 멀티 리전을 다시 나눈 것
2. 리전은 같은 대륙 내에서 독립된 지리적 위치입니다.
3. 리전 내에서는 네트워크 연결이 빠릅니다.
4. 일반적으로 95번째 백분위수에서 1밀리초 미만의 왕복 네트워크 지연 시간을 갖습니다.

영역

1. 리전은 최종적으로 영역으로 나뉩니다.
2. 영역이란 집중된 지리적 위치 내에 있는 GCP 리소스의 배포 위치를 뜻합니다.
3. 한 리전 내에 위치한 데이터 센터가 곧 영역이라고 볼 수 있습니다.
4. 하나의 영역이 반드시 하나의 데이터 센터인 것은 아닙니다.

Compute Engine 가상 머신 인스턴스는 특정 영역 내에 위치합니다. 

그 영역이 사용 불가 상태가 되면 가상 머신과 워크로드 또한 사용할 수 없게 됩니다.

GKE는 Compute Engine을 사용하므로 GKE 워크로드도 비슷한 영향을 받을 수 있습니다.

멀티 영역에 애플리케이션을 배포의 이점

1. 내결함성
2. 고가용성을 확보

세계 각지의 Google 데이터 센터는 Google 네트워크를 통해 연결됩니다.

Google 네트워크에 대한 설명

1. 사용자 앱을 포함한 모든 애플리케이션에 최대 처리량과 최소 지연 시간을 제공하도록 설계되었습니다.
2. Google 네트워크는 전 세계 90개 이상의 인터넷 교환 시설과 100개 이상의 접속 지점을 통해 공개 인터넷을 연결합니다.
3. 인터넷 사용자가 Google 리소스로 트래픽을 전송하면 Google은 지연 시간이 가장 낮은 에지 네트워크 위치에서 사용자의 요청에 응답합니다.
4. Google의 에지 캐싱 네트워크는 지연 시간을 최소화하도록 사용자 가까이에 콘텐츠를 배치합니다.
5. GKE를 비롯해 GCP에서 실행하는 애플리케이션도 이 에지 네트워크의 이점을 활용할 수 있습니다.

GCP와 리소스를 사용하면 리소스의 지리적 위치와 어느 수준에서 지정할지도 결정할 수 있습니다.

1. 영역 수준
   • 영역 리소스는 단일 영역 내에서 실행됩니다 따라서 해당 영역을 사용할 수 없게 되면 리소스 역시 사용할 수 없습니다. 간단한 예시로 Compute Engine 가상 머신 인스턴스와 영구 디스크를 들 수 있습니다. GKE의 구성요소의 하나인 '노드'도 영역 리소스에 해당합니다.
2. 리전 수준
   • 리전 리소스는 하나의 리전 내에 여러 영역에 걸쳐 실행됩니다. 리전 리소스를 사용하는 애플리케이션은 가용성을 높이기 위해 중복 배포될 수 있습니다. 이 전문 분야의 뒷부분에서 GKE를 사용하여 한 리전 내의 여러 영역에 리소스를 분산하는 방법을 알아보겠습니다. GCP 서비스인 Cloud Datastore도 이와 비슷하게 중복 방식을 통해 배포할 수 있습니다.
3. 멀티 리전 수준
   • 마지막으로 전역 리소스는 멀티 리전을 통해 관리할 수 있습니다. 전역 리소스는 애플리케이션의 가용성을 극대화합니다. 전역 리소스의 예시로는 HTTPS 부하 분산기와 virtual private cloud 즉 VPC 네트워크를 들 수 있으며 GKE 사용자도 이 리소스를 활용할 수 있습니다.

사용자가 사용하는 GCP 리소스는 위치와 상관없이 프로젝트에 속해야 합니다.

프로젝트란?

1. 항목을 구성하는 기본 수준으로 리소스 및 서비스를 생성, 사용할 때는 물론 결제, API, 권한 관리 시 기초가 됩니다.
2. 리전과 영역이 GCP 리소스를 물리적으로 구성한다면 프로젝트는 논리적으로 구성한다고 할 수 있습니다.
3. 프로젝트는 손쉽게 생성, 관리, 삭제가 가능하며 실수로 삭제할 경우 복구할 수도 있습니다.
4. 각 프로젝트는 고유한 프로젝트 ID와 프로젝트 번호로 식별됩니다.
5. 프로젝트 이름과 필터링을 위한 라벨을 정할 수 있습니다.
   • 라벨은 변경할 수 있지만 프로젝트 ID와 프로젝트 번호는 고정됩니다.
6. 프로젝트는 '폴더'라는 그룹으로 묶을 수 있습니다.
   1. 폴더를 사용하면 기업의 계층 구조를 반영하고 기업의 정책을 알맞은 수준에서 적용할 수 있습니다.
   2. 물론 폴더 내에 다른 폴더를 중첩할 수도 있습니다.
      1. 예를 들어 부서별 폴더를 만든 다음 각 부서의 폴더 내에 부서를 구성하는 팀별로 하위 폴더를 만들 수 있습니다.
      2. 각 팀의 프로젝트는 팀별 폴더에 속하게 됩니다. 모든 폴더는 하나의 조직에 포함됩니다.
      3. 조직은 GCP 리소스 계층 구조의 루트 노드입니다. 조직이 없더라도 GCP를 사용할 수는 있지만 조직은 무척 유용합니다.
      4. 조직을 이용해 기업 전반에 적용되는 정책을 설정할 수 있다. 또한 폴더를 사용하려면 조직이 필요합니다 GCP 고객이라면 이미 조직이 있을 것입니다. 그렇지 않다면 Google Cloud ID를 통해 무료로 만들 수 있습니다.
      5. 조직에는 고정 조직 ID와 변경할 수 있는 표시 이름이 있습니다. GCP 리소스 계층 구조는 조직 내 여러 부서와 팀의 리소스를 관리할 수 있도록 도와줍니다.
      6. 신뢰 경계와 리소스 격리를 구현하는 계층 구조를 정의할 수도 있습니다.
         1. 예를 들면 인사팀 직원에게 데이터베이스 서버 삭제 권한이 필요할까요? 엔지니어에게 직원 급여 데이터베이스를 삭제할 권한이 있어야 할까요? 둘 다 그렇지 않을 것입니다. Cloud IAM이라고도 하는 Cloud Identity and Access Management는 사용자가 사용하는 모든 GCP 리소스에 세부적인 액세스 제어를 가능케 합니다.
         2. IAM 정책을 정의하면 리소스의 사용자 액세스 제어가 가능합니다. 사용자가 선택한 수준에서 적용한 정책은 낮은 수준으로 상속됩니다. 예컨대 조직 수준에서 IAM 정책을 적용했다면 해당 조직 내의 폴더, 프로젝트 리소스까지 정책이 모두 적용됩니다.
         3. 계층 구조의 보다 낮은 수준에서 정책을 적용하면 추가 권한을 부여할 수 있습니다. 반면, 결제는 프로젝트 수준에서 누적됩니다. 대부분의 GCP 고객이 가진 리소스 계층 구조는 인사 조직도와 비슷하며 프로젝트 결제는 비용 센터 구조와 비슷합니다.
         4. 리소스 계층 구조가 중요한 이유는 GCP의 공유 보안 모델 때문입니다.
            1. 온프레미스 인프라에 애플리케이션을 구축할 경우 사용자가 스택 전체의 보안을 책임져야 합니다.
            2. 하드웨어와 하드웨어가 위치한 프레미스의 물리적 보안 디스크의 데이터 암호화 네트워크 무결성 애플리케이션에 저장된 콘텐츠 보호까지도 포함합니다.
            3. 하지만 애플리케이션을 GCP로 이전하면 Google에서 하위 레이어의 보안을 담당합니다. 하드웨어와 프레미스의 물리적 보안이나 디스크의 데이터 암호화 물리적 네트워크의 무결성 등이 포함되죠
            4. Google은 규모가 큰 만큼 대부분의 고객이 자체적으로 구현할 수 있는 것보다 안전하게 이러한 레이어를 보호할 수 있습니다. 데이터 보안을 비롯한 보안 스택의 상위 레이어는 여전히 사용자의 책임입니다.
            5. Google이 제공하는 도구는 사용자가 이러한 레이어에서 정의하는 정책을 구현하는 데 도움이 됩니다. 앞서 살펴본 리소스 계층 구조는 이러한 도구 중 하나이며 Cloud IAM 역시 마찬가지입니다.

GCP 결제

1. GCP 프로젝트 수준에서 설정합니다.
2. GCP 프로젝트를 정의할 때 결제 계정을 연결해야 합니다.
3. 결제 계정에서 사용자는 지불 옵션을 비롯한 모든 결제 정보를 설정합니다.
4. 결제 계정은 하나 이상의 프로젝트에 연결할 수 있습니다.
5. 결제 계정을 연결하지 않은 프로젝트는 무료 GCP 서비스만 사용 가능합니다.
6. 결제 계정은 매월 또는 기준액 도달 시 자동으로 청구 및 인보이스 되도록 설정할 수 있습니다.
7. 결제 하위 계정을 설정하면 프로젝트 결제를 분리할 수 있습니다.
8. GCP 서비스를 재판매하는 GCP 고객들은 재판매 고객별로 하위 계정을 사용하기도 합니다.

GCP 요금에 대한 걱정을 해결하는 세가지 유용한 도구

1. 예산 및 알림
   • 결제 계정 수준 또는 프로젝트 수준에서 예산을 정의할 수 있습니다.
   • 알림을 설정하면 비용이 예산 한도에 근접했을 때 알림을 받을 수 있습니다.
   • 예를 들면 예산 한도가 2만 달러이고 알림을 90%로 설정했다면 비용이 기준액이나 1만 8천 달러에 도달했을 때 알림을 받게 됩니다. 알림에 대한 응답으로 웹 훅이 호출되도록 설정할 수도 있으며 이 웹 훅을 사용하여 결제 알림을 기반으로 자동화를 제어할 수 있습니다. 예를 들어 결제 알림이 발생하면 리소스를 종료시키는 스크립트를 트리거하거나 웹 훅을 사용해 팀에 장애 신고를 제출할 수도 있습니다.
2. 결제 내보내기에서 보기
   • 외부 분석 검색이 손쉬운 곳에 결제 세부정보를 저장할 수 있습니다 BigQuery 데이터 세트나 Cloud Storage 버킷을 쓸 수 있다.
3. 보고서 보기
   • 보고서는 콘솔의 시각적 도구로 프로젝트 또는 서비스를 기준으로 지출을 모니터링할 수 있습니다.

GCP에 구현된 할당량은 예기치 못한 추가적인 결제 청구를 제한합니다.

할당량

1. 오류나 악성 공격으로 인해 리소스를 과소비하는 것을 방지하기 위해 설계되었다.
2. GCP 프로젝트 수준에서 적용됩니다.

할당량에는 두 가지 유형이 있다.

1. 비율 할당량
   • 특정 시점을 기준으로 재설정됩니다.
   • GKE 서비스는 기본적으로 GCP 프로젝트에서 API에 보내는 호출을 100초당 1천 건으로 제한하는 할당량을 구현하며 100초가 지나면 한도가 재설정됩니다.
   • 여기서 중요한 점은 GKE에서 실행되는 애플리케이션에서 받는 호출의 비율이 아닌 GKE 클러스터 자체에서 받는 호출을 제한하는 방식이라는 점입니다.
   • 일반적으로 그처럼 짧은 시간 안에 많은 호출을 보내는 일은 흔치 않으므로 할당량을 통해 오류성 행동을 차단하는 데 도움이 됩니다.
2. 배정 할당량
   1. 프로젝트 내에서 보유할 수 있는 리소스 수를 제어합니다.
   2. 배정 할당량은 시간이 지나도 재설정되지 않으므로 할당량이 넘지 않도록 리소스를 해제해야 합니다.
   3. 예를 들면 기본적으로 각 GCP 프로젝트는 VPC 네트워크 또는 virtual private cloud를 5개 이상 보유할 수 없도록 할당량이 적용됩니다.
   4. 할당량은 모든 프로젝트에 똑같이 적용되지 않습니다
      • 모든 프로젝트가 같은 할당량으로 시작되지만 Google Cloud 지원팀에 요청하면 일부 프로젝트의 할당량을 늘릴 수 있습니다.
      • 일부 할당량은 프로젝트 사용에 따라 자동으로 증가하기도 합니다.
      • GCP Console을 사용해 일부 프로젝트의 할당량을 줄일 수도 있습니다.
      • 모든 GCP 고객에게 고정되는 할당량도 일부 있습니다. 어떤 경우든 GCP 할당량은 고객에게 혜택을 주는 한편 예기치 않은 사용량 급증을 줄여 GCP 사용자 커뮤니티를 보호하는 역할을 합니다.

GCP와 상호작용하는 방법은 네 가지입니다

1. Google Cloud Platform Console
   • GCP Console은 웹 기반 그래픽 사용자 인터페이스로 GCP 리소스를 관리할 수 있습니다.
   • 간단한 마우스 클릭만으로 일반적인 작업을 수행할 수 있습니다.
   • 명령어를 외우거나 오타를 걱정할 필요가 없다.
   • GCP 프로젝트와 리소스를 가시적으로 파악하기도 용이합니다.
   • 웹브라우저로 console.cloud.google.com에 접속하여 GCP Console에 로그인하면 됩니다.
   • 왼쪽 상단의 탐색 메뉴 버튼을 통해 모든 GCP 서비스에 액세스 할 수 있습니다.
2. Cloud Shell
   • 사용 중인 머신에서 Cloud SDK 설치가 어려운 경우 사용한다.
   • Cloud Shell을 사용하면 브라우저에서 직접 명령줄을 통해 클라우드 리소스에 액세스 할 수 있습니다.
   • Cloud Shell을 사용하면 Cloud SDK 등의 도구를 로컬에 설치하지 않아도 손쉬운 프로젝트 및 리소스 관리가 가능합니다.
   • Cloud SDK, gcloud, kubectl 명령줄 도구와 그 외 유틸리티는 완전히 인증되어 있고 항상 최신 상태로 사용할 수 있습니다.
   • Cloud Shell은 어떻게 이것이 가능할까?
     • 비용이 없는 Compute Engine 가상 머신 인스턴스를 사용해 빌드되었기 때문입니다.
   • Cloud Shell 가상 머신은 단기적입니다. 사용자가 상호작용을 멈추면 작동을 중단하며 사용자가 Cloud Shell에 다시 진입하면 작동을 다시 시작합니다. 따라서 Cloud Shell에서 프로덕션 웹 서버를 실행하지 않는 것이 나을 수 있습니다.
   • 새 Cloud Shell 세션을 시작할 때마다 5GB의 영구 디스크 스토리지도 연결됩니다.
   • 또한 웹 미리보기 기능이 탑재되어 있으며 GKE 리소스를 비롯한 GCP Console 프로젝트 및 리소스에 대한 액세스 인증도 기본적으로 제공합니다.
   • Cloud Shell 코드 편집기는 웹브라우저에서 Cloud Shell 환경 내 파일을 실시간으로 편집하는 도구입니다.
   • Cloud Shell 명령 프롬프트에서 텍스트 편집기를 사용할 수도 있습니다.
   • 코드 우선 애플리케이션 또는 컨테이너 기반 워크로드를 작업할 때 무척 편리합니다. 변경사항을 다운로드, 업로드하지 않아도 간편하게 파일을 편집할 수 있기 때문이죠
3. Cloud SDK Cloud Console 모바일 앱
   • Google Cloud SDK를 다운로드하고 원하는 컴퓨터에 설치할 수도 있습니다.
   • Cloud SDK는 Google Cloud Platform용 명령줄 도구 집합을 포함하며 특히 이 과정에서 자주 사용할 gcloud 및 kubectl 명령어가 포함되어 있습니다.
   • gsutil 및 bq 유틸리티도 포함되어 있습니다.
   • 이러한 도구는 대화형으로나 자동화 스크립트에서 사용할 수도 있습니다.
   • Cloud SDK에는 다양한 프로그래밍 언어를 위한 클라이언트 라이브러리도 포함되어 있습니다
4. REST 기반 API
5. iOS와 Android에서 사용할 수 있는 Cloud Console 모바일 앱
   • 가상 머신 관리 가상 머신 로그 조회 프로젝트의 최신 결제 정보 확인 예산을 초과하는 프로젝트에 대해 결제 알림 받기
   • 커스텀 그래프를 설정하여 CPU 사용량과 네트워크 사용량 초당 요청 수, 서버 오류와 같은 주요 항목 표시 등이 있습니다

컴퓨팅 옵션

개요

Kubernetes 엔진에서 지속적 전달 파이프라인을 설정하는 방법

• Kubernetes Engine 클러스터에 Jenkins 애플리케이션 프로비저닝
• Helm 패키지 관리자를 사용하여 Jenkins 애플리케이션 설정
• Jenkins 애플리케이션의 기능 살펴보기
• Jenkins 파이프라인 생성 및 실행

젠킨스란?

Jenkins는 빌드, 테스트 및 배포 파이프라인을 유연하게 오케스트레이션 할 수 있는 오픈 소스 자동화 서버입니다. Jenkins를 사용하면 개발자가 지속적 배포에서 발생할 수 있는 오버헤드 문제에 대해 걱정하지 않고 프로젝트를 빠르게 배포할 수 있습니다.

1. Jenkins 프로비저닝

gcloud container clusters create jenkins-cd \
--num-nodes 2 \
--machine-type n1-standard-2 \
--scopes "https://www.googleapis.com/auth/source.read_write,cloud-platform"

Kubernetes 클러스터 만들기위한 명령어입니다.

gcloud container clusters list

클러스터가 실행 중인지 확인하는 명령어입니다.

gcloud container clusters get-credentials jenkins-cd

클러스터에 대한 자격 증명을 가져옵니다.

kubectl cluster-info

Kubernetes Engine은 이러한 자격 증명을 사용하여 새로 프로비저닝 된 클러스터에 액세스 합니다. 위의 명령어를 실행하여 클러스터에 연결할 수 있는지 확인합니다.

2. Setup Helm

Helm을 사용하여 Charts 리포지토리에서 Jenkins를 설치합니다. Helm은 Kubernetes 애플리케이션을 쉽게 구성하고 배포할 수 있게 해주는 패키지 관리자입니다. Jenkins가 설치되면 CI/CD 파이프라인을 설정할 수 있습니다.

helm repo add jenkins https://charts.jenkins.io
helm repo update

Helm의 차트 저장소 추가하는 명령어입니다.

3. Jenkins 구성 및 설치

Jenkins 설치 시 values파일을 템플릿으로 사용하여 설정에 필요한 값을 제공할 수 있습니다.

사용자 지정 values파일을 사용하여 Kubernetes 클라우드를 자동으로 구성하고 다음 필수 플러그인을 추가합니다.

• Kubernetes:1.29.4
• Workflow-multibranch:latest
• Git:4.7.1
• Configuration-as-code:1.51
• Google-oauth-plugin:latest
• Google-source-plugin:latest
• Google-storage-plugin:latest

이렇게 하면 Jenkins가 클러스터와 GCP 프로젝트에 연결할 수 있습니다.

gsutil cp gs://spls/gsp330/values.yaml jenkins/values.yaml
helm install cd jenkins/jenkins -f jenkins/values.yaml --wait

첫 번째 명령어는 values파일을 다운로드 하기 위한 명령어입니다.

두 번째 명령어는 Helm CLI를 사용하여 구성 설정으로 차트를 배포하는 명령어입니다.

kubectl get pods
kubectl create clusterrolebinding jenkins-deploy --clusterrole=cluster-admin --serviceaccount=default:cd-jenkins

클러스터에 배포할 수 있도록 Jenkins 서비스 계정을 구성합니다.

Jenkins 포드가 Running상태로 전환되고 컨테이너가 READY 상태인지 확인합니다.

export POD_NAME=$(kubectl get pods --namespace default -l "app.kubernetes.io/component=jenkins-master" -l "app.kubernetes.io/instance=cd" -o jsonpath="{.items[0].metadata.name}")
kubectl port-forward $POD_NAME 8080:8080 >> /dev/null &

위의 명령어를 실행하여 Cloud Shell에서 Jenkins UI로 포트 전달을 설정합니다.

kubectl get svc

Jenkins 서비스가 제대로 생성되었는지 확인합니다.

printf $(kubectl get secret cd-jenkins -o jsonpath="{.data.jenkins-admin-password}" | base64 --decode);echo

Jenkins 차트는 자동으로 관리자 암호를 생성합니다. 위의 명령어는 암호를 확인하기 위한 명령어입니다.

사용자 이름 admin과 자동 생성된 비밀번호로 로그인할 수 있습니다.

성공적으로 로그인이 된걸 확인할 수 있다.

6. 애플리케이션 배포

• 프로덕션 : 사용자가 액세스하는 라이브 사이트입니다.
• 카나리아 : 사용자 트래픽의 일정 비율만 수신하는 소규모 사이트입니다. 이 환경을 사용하여 모든 사용자에게 릴리스 되기 전에 라이브 트래픽으로 소프트웨어를 검증하십시오.

cd sample-app
kubectl create ns production
kubectl apply -f k8s/production -n production
kubectl apply -f k8s/canary -n production
kubectl apply -f k8s/services -n production

두 번째 명렁어로 배포를 논리적으로 격리하기 위해 Kubernetes 네임스페이스를 만듭니다.

kubectl apply 명령어를 사용하여 프로덕션 및 카나리아 배포와 서비스를 만듭니다.

기본적으로 프런트엔드의 복제본은 하나만 배포됩니다. 명령을 사용하여 kubectl scale항상 실행 중인 복제본이 4개 이상 있는지 확인합니다.

kubectl scale deployment gceme-frontend-production -n production --replicas 4
kubectl get pods -n production -l app=gceme -l role=frontend
kubectl get pods -n production -l app=gceme -l role=backend
kubectl get service gceme-frontend -n production

첫 번째 명령어를 실행하여 프로덕션 환경의 프런트엔드를 확장합니다.

이제 두 번째 명령어를 실행하여 프런트엔드용으로 5개의 포드, 프로덕션 트래픽용으로 4개, 카나리아 릴리스용으로 1개가 실행 중인지 확인합니다(카나리아 릴리스에 대한 변경 사항은 사용자 5명 중 1명(20%)에게만 영향을 미침).

세 번째 명령어를 실행하여 백엔드용 포드 2개(프로덕션용 1개, 카나리아용 1개)가 있는지 확인합니다.

네 번째 명령어는 프로덕션 서비스에 대한 외부 IP 검색하는 명령어입니다.

외부 IP 를 브라우저에 붙여 넣으면 카드에 표시된 정보 카드를 볼 수 있습니다.

export FRONTEND_SERVICE_IP=$(kubectl get -o jsonpath="{.status.loadBalancer.ingress[0].ip}" --namespace=production services gceme-frontend)
curl http://$FRONTEND_SERVICE_IP/version

첫 번째 명령어로 프런트엔드 서비스 로드 밸런서 IP를 나중에 사용할 수 있도록 환경 변수에 저장합니다.

브라우저에서 프런트엔드 외부 IP 주소를 열어 두 서비스가 모두 작동하는지 확인합니다.

curl 명령을 실행하여 서비스의 버전 출력을 확인합니다.

1.0.0 이 정상 출력되는 것을 확인하실 수 있습니다.

7. Jenkins 파이프라인 생성

git init
git config credential.helper gcloud.sh
git remote add origin https://source.developers.google.com/p/$DEVSHELL_PROJECT_ID/r/default
git config --global user.email "[EMAIL_ADDRESS]"
git config --global user.name "[USERNAME]"
git add .
git commit -m "Initial commit"
git push origin master

Multibranch Pipeline 옵션을 선택하고 확인을 클릭 합니다.

Branch Sources에서 소스 추가 를 클릭하고 git 을 선택합니다.

https://source.developers.google.com/p/[PROJECT_ID]/r/default

Project Repository에 위에 URL을 복사해 붙여 넣습니다. 

Credentials에서 이전 단계에서 서비스 계정을 추가할 때 생성한 자격 증명의 이름을 선택합니다.

Scan Multibranch Pipeline Triggers 섹션에서,  Periodically if not otherwise run을 선택하고 Interval 값을 1분으로 설정합니다. 이 단계를 완료하면 이라는 작업이 Branch indexing 실행됩니다.이 메타 작업은 저장소의 분기를 식별하고 기존 분기에서 변경 사항이 발생하지 않았는지 확인합니다. 왼쪽 상단의 sample-app을 클릭하면 master작업이 표시됩니다. Jenkins 파이프라인을 성공적으로 생성했습니다.

vi Jenkinsfile

REPLACE_WITH_YOUR_PROJECT_ID를 자기 자신의 PROJECT_ID값으로 바꾸고 저장을 해준다.

vi html.go

<div class="card blue">의 값을 <div class="card oragne"> 값으로 변경합니다.

vi main.go

const version string = "1.0.0"을 const version string = "2.0.0"의 값으로 변경합니다.

밑에 카나리아 릴리스 배포, 프로덕션에 배포는 생략하였습니다. 

마지막 과정까지 완료하여서 쿠버네티스 구글 클라우드 과정을 수료하였습니다! 이 후에 쿠버네티스 구글 클라우드 과정의 후기와 느낀 점의 글을 작성하겠습니다!

개요

지속적인 배포, 블루-그린 배포, 카나리아 배포 등과 같은 애플리케이션 배포 시나리오를 관리하기 위해 정기적으로 여러 배포를 사용합니다. 이 실습에서는 여러 이기종 배포가 사용되는 이러한 일반적인 시나리오를 수행할 수 있도록 컨테이너 확장 및 관리에 대한 실습을 제공합니다.

배포 소개

이기종 배포에는 일반적으로 특정 기술 또는 운영 요구 사항을 해결하기 위해 둘 이상의 별개의 인프라 환경 또는 지역을 연결하는 작업이 포함됩니다. 이기종 배포는 배포의 세부 사항에 따라 하이브리드, 멀티 클라우드 또는 퍼블릭-프라이빗이라고 합니다. 이 실습의 목적에 따라 이기종 배포에는 단일 클라우드 환경, 여러 퍼블릭 클라우드 환경(멀티 클라우드) 또는 온프레미스와 퍼블릭 클라우드 환경의 조합(하이브리드 또는 퍼블릭-프라이빗) 내의 지역에 걸친 배포가 포함됩니다.

단일 환경 또는 지역으로 제한된 배포에서는 다양한 비즈니스 및 기술 문제가 발생할 수 있습니다.

• 최대 리소스 : 모든 단일 환경, 특히 온프레미스 환경에서는 프로덕션 요구 사항을 충족하는 컴퓨팅, 네트워킹 및 스토리지 리소스가 없을 수 있습니다.
• 제한된 지리적 범위 : 단일 환경에 배포하려면 지리적으로 멀리 떨어져 있는 사람들이 하나의 배포에 액세스해야 합니다. 트래픽은 전 세계의 중앙 위치로 이동할 수 있습니다.
• 제한된 가용성 : 웹 규모의 트래픽 패턴은 애플리케이션이 내결함성과 탄력성을 유지하도록 요구합니다.
• 공급업체 종속 : 공급업체 수준 플랫폼 및 인프라 추상화로 인해 애플리케이션을 이식할 수 없습니다.
• 유연하지 않은 리소스 : 리소스가 특정 컴퓨팅, 스토리지 또는 네트워킹 오퍼링 세트로 제한될 수 있습니다.

이기종 배포는 이러한 문제를 해결하는 데 도움이 될 수 있지만 프로그래밍 방식의 결정론적 프로세스와 절차를 사용하여 설계해야 합니다. 일회성 또는 임시 배포 절차로 인해 배포 또는 프로세스가 취약해지고 장애를 견딜 수 없게 될 수 있습니다. 임시 프로세스는 데이터를 손실하거나 트래픽을 삭제할 수 있습니다. 좋은 배포 프로세스는 반복 가능해야 하며 프로비저닝, 구성 및 유지 관리를 위해 입증된 접근 방식을 사용해야 합니다. 이기종 배포에 대한 세 가지 일반적인 시나리오는 다중 클라우드 배포, 온프레미스 데이터 프론팅 및 CI/CD(지속적 통합/지속적 전달) 프로세스입니다.

1. 배포

gcloud container clusters create bootcamp --num-nodes 5 --scopes "https://www.googleapis.com/auth/projecthosting,storage-rw"

5개의 노드가 있는 클러스터를 만듭니다.

kubectl explain deployment

deployment에 대한 설명을 보여주는 명령어입니다.

kubectl explain deployment --recursive

--recursive 옵션을 사용하면 모든 필드에 대한 doployment 내용을 확인할 수 있습니다.

deployments/auth.yaml구성 파일을 업데이트합니다.

spec:
  container:
	image: "kelseyhightower/auth:1.0.0"

"kelseyhightower/auth:2.0.0"을 "kelseyhightower/auth:1.0.0"으로 업데이트를 해줍니다.

kubectl create -f deployments/auth.yaml

kubectl create 인증 배포를 생성하기 위해 명령을 실행하면 배포 매니페스트의 데이터를 준수하는 하나의 포드가 생성됩니다. 이는 replicas필드에 지정된 수를 변경하여 Pod 수를 확장할 수 있음을 의미합니다.

kubectl get deployments

배포를 생성한 후에는 생성되었는지 확인할 수 있습니다.

kubectl get replicasets

배포가 생성되면 Kubernetes는 배포용 ReplicaSet을 생성합니다. 배포를 위해 ReplicaSet이 생성되었는지 확인할 수 있습니다.

kubectl get pods

마지막으로 배포의 일부로 생성된 파드를 볼 수 있습니다. ReplicaSet이 생성될 때 Kubernetes에 의해 단일 Pod가 생성됩니다.

kubectl create -f services/auth.yaml

이제 인증 배포를 위한 서비스를 만들 차례입니다. 위의 명령어를 사용해서 인증 서비스를 만듭니다.

kubectl create -f deployments/hello.yaml
kubectl create -f services/hello.yaml

hello Deployment를 만들고 expose 합니다.

kubectl create secret generic tls-certs --from-file tls/
kubectl create configmap nginx-frontend-conf --from-file=nginx/frontend.conf
kubectl create -f deployments/frontend.yaml
kubectl create -f services/frontend.yaml

frontend 배포를 만들고 노출합니다.

kubectl get services frontend

curl -ks https://<EXTERNAL-IP>

외부 IP에 curl 명령을 치면 Hello라고 잘 나오는 것을 확인하실 수 있습니다.

2. 확장

이제 배포가 생성되었으므로 확장할 수 있습니다. 

kubectl scale deployment hello --replicas=5

kubectl scale의 replicas 필드는 위의 명령어를 사용하여 쉽게 업데이트할 수 있습니다.

kubectl get pods | grep hello- | wc -l
kubectl scale deployment hello --replicas=3
kubectl get pods | grep hello- | wc -l

deployment가 업데이트되면 Kubernetes는 연결된 ReplicaSet을 자동으로 업데이트하고 새 Pod를 시작하여 총 Pod 수가 5가 되도록 한다. 이제 5개의 helloPod가 실행 중인지 확인합니다. 확인하는 명령어는 kubectl get pods | grep hello- | wc -l입니다. kubectl scale deployment hello --replicas=3은 애플리케이션의 replicas를 3으로 축소하는 명령어입니다.

롤링 업데이트

배포는 롤링 업데이트 메커니즘을 통해 이미지를 새 버전으로 업데이트하는 것을 지원합니다. Deployment가 새 버전으로 업데이트되면 새 ReplicaSet을 생성하고 이전 ReplicaSet의 복제본이 감소함에 따라 새 ReplicaSet의 복제본 수를 천천히 늘립니다.

deployments/auth.yaml구성 파일을 업데이트합니다.

spec:
  container:
	image: "kelseyhightower/auth:2.0.0"

"kelseyhightower/auth:1.0.0"을 "kelseyhightower/auth:2.0.0"으로 업데이트를 해줍니다.

편집기에서 저장하면 업데이트된 배포가 클러스터에 저장되고 Kubernetes가 롤링 업데이트를 시작합니다.

kubectl get replicaset
kubectl rollout history deployment/hello

실행 중인 롤아웃에서 문제가 감지되면 일시 중지하여 업데이트를 중지합니다.

kubectl rollout pause deployment/hello
kubectl rollout status deployment/hello
kubectl get pods -o jsonpath --template='{range .items[*]}{.metadata.name}{"\t"}{"\t"}{.spec.containers[0].image}{"\n"}{end}'

1번째 명령어는 중지시키는 명령어입니다. 2번째 명령어는 deployment의 상태를 확인하는 명령어입니다.

3번째 명령어는 Pod에서 확인하기 위한 명령어입니다.

kubectl rollout resume deployment/hello
kubectl rollout status deployment/hello

롤아웃이 일시 중지되어 일부 포드는 새 버전이고 일부 포드는 이전 버전입니다. resume명령 을 사용하여 롤아웃을 계속할 수 있습니다.

status롤아웃이 완료되면 위의 status 명령어를 실행할 때 "hello" 성공적으로 롤아웃이 되었습니다라고 출력되어야 합니다.

kubectl rollout undo deployment/hello
kubectl rollout history deployment/hello
kubectl get pods -o jsonpath --template='{range .items[*]}{.metadata.name}{"\t"}{"\t"}{.spec.containers[0].image}{"\n"}{end}'

새 버전에서 버그가 감지되었다고 가정합니다. 새 버전에는 문제가 있는 것으로 추정되므로 새 Pod에 연결된 모든 사용자는 이러한 문제를 겪을 것입니다.

조사한 다음 제대로 수정된 버전을 릴리스할 수 있도록 이전 버전으로 롤백하고 싶을 것입니다.

다음 명령을 사용 rollout하여 이전 버전으로 롤백합니다.

카나리아 배포

사용자의 하위 집합을 사용하여 프로덕션에서 새 배포를 테스트하려는 경우 카나리아 배포를 사용합니다. Canary 배포를 사용하면 소규모 사용자 하위 집합에 대한 변경 사항을 릴리스하여 새 릴리스와 관련된 위험을 완화할 수 있습니다.

카나리아 배포는 새 버전이 포함된 별도의 배포와 정상적인 안정적인 배포와 카나리아 배포를 모두 대상으로 하는 서비스로 구성됩니다.

kubectl create -f deployments/hello-canary.yaml
kubectl get deployments

Canary 배포가 생성된 후에는 hello 하고 hello-canary의 두 개의 배포가 있어야 한다.

curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

hello요청에 의해 제공되는 버전을 확인할 수 있습니다. 이것을 여러 번 실행하면 일부 요청이 hello 1.0.0에서 제공되고 작은 하위 집합(1/4 = 25%)이 2.0.0에서 제공되는 것을 볼 수 있습니다.

블루 - 그린 배포

롤링 업데이트는 오버헤드를 최소화하고 성능에 미치는 영향을 최소화하며 가동 중지 시간을 최소화하면서 애플리케이션을 천천히 배포할 수 있기 때문에 이상적입니다. 새 버전이 완전히 배포된 후에만 해당 새 버전을 가리키도록 로드 밸런서를 수정하는 것이 유리한 경우가 있습니다. 이 경우 블루-그린 배포가 올바른 방법입니다.

Kubernetes는 두 개의 개별 배포를 생성하여 이를 달성합니다. 하나는 이전 "파란색" 버전용이고 다른 하나는 새 "녹색" 버전용입니다. hello"파란색" 버전에 대해 기존 배포를 사용합니다. 배포는 라우터 역할을 하는 서비스를 통해 액세스 됩니다.새로운 "그린" 버전이 실행되고 나면 서비스를 업데이트하여 해당 버전을 사용하도록 전환합니다.

블루-그린 배포의 주요 단점은 애플리케이션을 호스팅 하는 데 필요한 클러스터에 최소 2배의 리소스가 필요하다는 것입니다. 한 번에 두 버전의 애플리케이션을 모두 배포하기 전에 클러스터에 충분한 리소스가 있는지 확인하십시오.

kubectl apply -f services/hello-blue.yaml

먼저 서비스를 업데이트합니다.

kubectl create -f deployments/hello-green.yaml
curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version
kubectl apply -f services/hello-green.yaml
curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

녹색 배포가 있고 제대로 시작되면 현재 버전 1.0.0이 여전히 사용 중인지 확인합니다. 이제 새 버전을 가리키도록 서비스를 업데이트합니다. 서비스가 업데이트되면 "그린" 배포가 즉시 사용됩니다. 이제 새 버전이 항상 사용 중인지 확인할 수 있습니다.

kubectl apply -f services/hello-blue.yaml
curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

필요한 경우 동일한 방식으로 이전 버전으로 롤백할 수 있습니다. "파란색" 배포가 계속 실행되는 동안 서비스를 이전 버전으로 다시 업데이트하기만 하면 됩니다. 서비스를 업데이트하면 롤백이 성공한 것입니다. 다시 한 번 올바른 버전이 사용 중인지 확인합니다.

개요

• Kubernetes Engine을 사용하여 완전한 Kubernetes 클러스터를 프로비저닝 합니다.
• 를 사용하여 Docker 컨테이너를 배포하고 관리 kubectl합니다.
• Kubernetes의 배포 및 서비스를 사용하여 애플리케이션을 마이크로 서비스로 나눕니다.

GitHub에서 샘플 코드를 가져와서 실습을 하셔야 됩니다.

1. Pods

kubectl create deployment nginx --image=nginx:1.10.0

Kubernetes는 deployment를 만들었습니다. deployment에 대한 자세한 내용은 나중에 설명한다고 합니다. 지금은 배포가 실행되는 노드에 오류가 발생하더라도 배포가 포드를 계속 실행 상태로 유지한다는 점만 알면 된다.

kubectl get pods

위의 명령어를 사용하여 현재 실행 중인 nginx 컨테이너를 볼 수 있다.

kubectl expose deployment nginx --port 80 --type LoadBalancer

Kubernetes는 공개 IP 주소가 연결된 외부 로드 밸런서를 생성했다. 해당 공용 IP 주소에 도달한 모든 클라이언트는 서비스 뒤의 포트로 라우팅 된다.

kubectl get services

Kubernetes의 현재 서비스 중인 목록을 볼 수 있다.

curl http://<External IP>:80

External IP를 이용하여 curl 명령어를 치면 Welcome to nginx 가 나오는 것을 확인하실 수 있습니다.

Kubernetes의 핵심은 Pod가 있다. Pod는 하나 이상의 컨테이너 컬렉션을 나타내고 보유한다. 일반적으로 서로에 대한 종속성이 강한 여러 컨테이너가 있는 경우 컨테이너를 단일 Pod 안에 패키징 한다. Pod에는 Volumes 도 있다.볼륨은 Pod가 살아있는 동안 지속되는 데이터 디스크이며 해당 포드의 컨테이너에서 사용할 수 있습니다. Pod는 콘텐츠에 대한 공유 네임스페이스를 제공합니다. 즉, 예제 Pod 내부의 두 컨테이너는 서로 통신할 수 있으며 연결된 볼륨도 공유할 수 있습니다. Pod는 또한 네트워크 네임스페이스를 공유한다. 이는 Pod 당 하나의 IP 주소가 있음을 의미합니다.

cat pods/monolith.yaml

위의 명령어는 모놀리스 포드 구성 파일을 확인하는 명령어이다.

• Pod는 하나의 컨테이너(모놀리스)로 구성됩니다.
• 컨테이너가 시작될 때 몇 가지 인수를 컨테이너에 전달합니다.

kubectl create -f pods/monolith.yaml

모놀리스 Pod를 만드는 명령어입니다.

모놀리스 컨테이너 이미지를 실행하려면 먼저 Docker Hub에서 가져와야 합니다.

kubectl describe pods monolith

kubectl describe 명령어를 사용하면 모노리스 Pod IP 주소 및 이벤트 로그를 포함하여 모놀리스 Pod에 대한 자세한 정보를 얻을 수 있다.

kubectl port-forward monolith 10080:80

기본적으로 Pod에는 사설 IP 주소가 할당되며 클러스터 외부에서 연결할 수 없습니다. kubectl port-forward 명령어를 사용하여 로컬 포트를 모놀리스 포드 내부의 포트에 매핑합니다.

curl http://127.0.0.1:10080

새로운 터미널을 열어서 curl 명령어를 치면 Hello라고 나오는 것을 확인하실 수 있습니다.

curl http://127.0.0.1:10080/secure

curl명령을 사용하여 보안 엔드포인트에 도달했을 때 인증 실패라고 나오는 것을 확인하실 수 있습니다.

curl -u user http://127.0.0.1:10080/login

로그인을 해서 JWT 토큰을 발급받습니다.

TOKEN=$(curl http://127.0.0.1:10080/login -u user|jq -r '.token')

Cloud Shell은 긴 문자열 복사를 잘 처리하지 못하므로 토큰에 대한 환경 변수를 만듭니다.

curl -H "Authorization: Bearer $TOKEN" http://127.0.0.1:10080/secure

다시 발급받은 토큰을 이용해서 접근을 하면 Hello 메시지가 정상 출력되는 것을 확인하실 수 있습니다.

kubectl logs monolith

위의 명령어는 log를 확인하는 명령어입니다.

kubectl logs -f monolith

-f는 실시간으로 발생하는 로그를 확인할 수 있는 명령어입니다.

kubectl exec monolith --stdin --tty -c monolith -- /bin/sh

위의 명령어는 Monolith Pod 내에서 대화형 셸을 실행합니다. 컨테이너 내에서 문제를 해결하려는 경우에 유용하게 사용할 수 있다.

ping -c 3 google.com

모놀리스 컨테이너에 셸이 있으면 ping명령을 사용하여 외부 연결을 테스트할 수 있습니다.

2. Services

포드는 영구적이지 않다. 여러 가지 이유로 중지되거나 다시 시작될 수 있으며 이로 인해 문제가 발생한다. Pod 집합과 다시 통신하려는 경우 다시 시작할 때 다른 IP 주소를 가질 수 있습니다. 이때 필요한 것이 서비스입니다. 서비스는 Pod에 안정적인 엔드포인트를 제공합니다.

서비스는 레이블을 사용하여 작동하는 Pod를 결정합니다. Pod에 올바른 레이블이 있으면 자동으로 선택되어 서비스에 노출된다.

서비스가 Pod에 제공하는 액세스 수준은 서비스 유형에 따라 다르다. 이에는 세 가지 유형이 있습니다.

• ClusterIP(내부) 기본 유형은 이 서비스가 클러스터 내부에서만 볼 수 있음을 의미합니다.
• NodePort클러스터의 각 노드에 외부에서 액세스 할 수 있는 IP를 제공하고
• LoadBalancer서비스에서 서비스 내의 노드로 트래픽을 전달하는 클라우드 공급자의 로드 밸런서를 추가합니다.

cat pods/secure-monolith.yaml

서비스를 생성하기 전에 먼저 https 트래픽을 처리할 수 있는 보안 포드를 생성한다.

kubectl create secret generic tls-certs --from-file tls/
kubectl create configmap nginx-proxy-conf --from-file nginx/proxy.conf
kubectl create -f pods/secure-monolith.yaml

보안 모노리스 Pod와 해당 구성 데이터를 작성하는 명령어입니다.

이제 보안 Pod가 생성되었으므로 보안 모놀리스 Pod를 외부에 노출해야 된다. 외부에 노출하려면 Kubernetes 서비스를 생성해야 된다.

• app: monolith 및 레이블이 있는 모든 포드를 자동으로 찾고 노출하는 데 사용되게  하는 secure: enabled이 있다.
• 이제 포트 31000번에서 nginx포트 443으로 외부 트래픽을 전달해야 되므로 노드 포트를 expose 해야 한다.

kubectl create -f services/monolith.yaml

모놀리식 서비스를 만드는 명령어이다.

gcloud compute firewall-rules create allow-monolith-nodeport --allow=tcp:31000

위의 명령어는 노출된 노드 포트에서 모놀리식 서비스에 대한 트래픽을 허용하는 명령어입니다.

gcloud compute instances list

리스트에 대한 정보를 볼 수 있는 명령어입니다. 노드 중 하나에 대한 외부 IP 주소를 가져옵니다.

curl -k https://<EXTERNAL_IP>:31000

curl 명령어를 치면 실패하는 것을 확인하실 수 있습니다.

현재 모놀리스 서비스에는 endpoint가 없습니다. 이와 같은 문제를 해결하는 한 가지 방법은 kubectl get pods레이블 쿼리와 함께 명령어를 사용하는 것입니다.

kubectl label pods secure-monolith 'secure=enabled'
kubectl get pods secure-monolith --show-labels

 Pod에 kubectl label에 누락된 레이블 secure=enabled 추가합니다.

kubectl describe services monolith | grep Endpoints

올바르게 레이블이 지정되었으므로 모놀리스 서비스에서 엔드포인트 목록을 확인하면 올바르게 나오는 것을 확인할 수 있다.

curl -k https://<EXTERNAL_IP>:31000

curl 명령어를 실행시키면 Hello라고 잘 나오는 것을 확인하실 수 있습니다.

3. Deployment

Deployment는 실행 중인 Pod 수가 사용자가 지정한 원하는 Pod 수와 동일하도록 만드는 방법입니다.

Deployment의 주요 이점은 Pod 관리의 낮은 수준 세부 정보를 추상화한다는 것입니다. Deployment는 복제본 세트를 사용하여 Pod 시작 및 중지를 관리합니다. Pod를 업데이트하거나 확장해야 하는 경우나 어떤 이유로 인해 중단된 경우, 다시 시작해야 하는 경우 Deployment에서 처리합니다.

Pod는 생성된 노드의 수명과 연결됩니다. 위의 예에서 Node3이 다운되었습니다(Pod와 함께 사용). 새 Pod를 수동으로 생성하고 이에 대한 노드를 찾는 대신 Deployment에서 새 Pod를 생성하고 Node 2에서 시작했습니다.

이제 Pod 및 서비스에 대해 배운 모든 것을 결합하여 Deployment를 사용하여 모놀리식 애플리케이션을 더 작은 서비스로 분할해봅시다.

모놀리스 앱을 세 개의 개별 조각으로 나눕니다.

• auth - 인증된 사용자에 대한 JWT 토큰을 생성합니다.
• hello - 인증된 사용자를 환영합니다.
• frontend - auth 및 hello 서비스로 트래픽을 라우팅 합니다.

각 서비스에 대해 하나씩 배포를 만들 준비가 되었습니다. 그런 다음 auth 및 hello 배포를 위한 내부 서비스와 frontend 배포를 위한 외부 서비스를 정의합니다. 완료되면 Monolith와 마찬가지로 마이크로 서비스와 상호 작용할 수 있습니다. 이제 각 부분을 독립적으로 확장하고 배포할 수 있습니다.

cat deployments/auth.yaml

Replicas 필드에 지정된 수를 변경하여 Pod 수를 확장할 수 있습니다.

kubectl create -f deployments/auth.yaml

deployments 개체를 만드는 명령어입니다.

kubectl create -f services/auth.yaml

인증 deployment를 위한 서비스를 만드는 명령어입니다.

kubectl create -f deployments/hello.yaml
kubectl create -f services/hello.yaml

hello deployment와 서비스를 만들고 expose 합니다.

kubectl create configmap nginx-frontend-conf --from-file=nginx/frontend.conf
kubectl create -f deployments/frontend.yaml
kubectl create -f services/frontend.yaml

frontend deployment를 만들고 expose 합니다.

kubectl get services frontend

위의 명령어를 이용해 외부 IP 주소를 확인합니다.

curl -k https://<EXTERNAL-IP>

curl 명령어로 EXTERNAL-IP로 요청을 보내면 Hello라는 메시지가 잘 나오는 것을 확인하실 수 있습니다.