Orchestrating Google Cloud with Kubernetes

Orchestrating Google Cloud with Kubernetes

Google Cloud with Docker

Google Cloud with Kubernetes

Google Kubernetes Engine

Cloud Shell 환경에서 다음 명령을 입력하여 zone을 설정합니다.

$ gcloud config set compute/zone us-central1-f

zone을 설정하고 나서, cluster를 생성합니다.

$ gcloud container clusters create io

또는

$ gcloud container clusters create hello-world  \
              --num-nodes 3 \
              --machine-type f1-micro \
              --zone us-central1-f

Get the sample code

Cloud Shell 에서 Github repository 내용을 clone 합니다.

$ git clone https://github.com/googlecodelabs/orchestrate-with-kubernetes.git

$ cd orchestrate-with-kubernetes/kubernetes

kubernetes에 있는 파일들을 확인해봅시다.

$ ls -al

- deployments : Deployment manifests

- nginx : nginx 설정 파일

- pods : Pod manifests

- services : Services manifests

- tls : TLS certificates

- cleanup.sh : Cleanup script

자 이제, Kubernetes를 시험해봅시다!

Quick Kubernetes Demo

Kubernetes를 시작하는 가장 쉬운 방법은 kubectl run 명령을 사용하는 것입니다.

nginx container의 단일 instance를 시작해봅시다.

$ kubectl run nginx --image=nginx:1.10.0

Kubernetes는 deployment를 만들었습니다. deployment에 대한 자세한 내용은 나중에 나옵니다.

node가 실행에 실패하더라도 deployment는 pod를 계속 실행하는 것을 알아야 합니다.

Kubernetes에는 모든 container가 pod에서 실행됩니다. 실행중인 nginx container를 보려면 kubectl get pods 명령을 사용합니다.

$ kubectl get pods

nginx container가 실행되면 kubectl expose 명령을 사용하여 Kubernetes 외부에 노출시킬 수 있습니다.

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

Kubernetes는 공용 IP 주소가 지정된 외부 Load Balancer를 생성하였습니다.

공용 IP 주소에 도달한 모든 클라이언트(client)는 서비스 뒤에 있는 pod로 라우팅 됩니다. 이 경우에는 nginx pod가 해당됩니다.

kubectl get services 명령어를 사용해 service를 살펴봅시다.

$ kubectl get services

서비스를 위해 ExternalIP field가 생기기까지 몇 초가 걸릴 수 있습니다. 몇 초마다 kubectl get services 명령을 실행하거나, watch -n 1 kubectl get services를 실행해보세요

이 명령에 외부 ExternalIP를 추가하여 Nginx container를 원격으로 hit 해봅시다.

$ curl http://<External IP>:80

Kubernetes는 kubectl run 과 kubectl expose 명령어를 사용해 즉시 가능한 workflow를 지원합니다.

이제는 Kubernetes에 대해 간략히 살펴 보았으므로 각 구성 요소와 추상화에 대해 살펴봅시다.

Kubernetes Clusters

https://kubernetes.io/docs/tutorials/kubernetes-basics/cluster-intro/

Kubernetes는 단일 장치로 작동하도록 연결된 고가용성 클러스터를 조정합니다. Kubernetes의 추상화를 사용하면 container된 application을 개별 시스템에 특수하게 묶지 않고 cluster를 배포할 수 있습니다. 이 새로운 배포(deployment) 모델을 사용하려면 application을 개별 호스트에서 분리하는 방식으로 패키지, 즉 container로 변경해야 합니다. container application은 호스트에 깊이 통합된 패키지로 application을 직접 설치한 이전 배포 모델보다 유연성과 가용성이 뛰어납니다. Kubernetes는 클러스터 전체에서 application container의 분배(distribution)와 스케줄링(scheduling)을 효율적으로 자동화합니다. Kubernetes는 오픈 소스 플랫폼으로 production 환경에 적합합니다.

Kubernetes 클러스터는 두 가지 유형의 자원(resource)로 구성됩니다.

- Master가 클러스터를 조정합니다.

- Node는 application을 실행하는 Worker 입니다.

Master는 클러스터 관리를 담당합니다. Master는 application 스케줄링(scheduling), application이 원하는 상태 유지, application의 scaling과 새로운 업데이트에 대한 rolling out도 관여합니다.

Node는 Worker로서, 실제 physical computer거나 VM입니다. 밑에서 Node에 대한 설명을 하겠습니다.

트래픽을 처리하는 Kubernetes 클러스터는 최소 3개의 Node가 있어야 합니다.

Kubernetes에서 application을 배포할 때 application container를 시작하도록 Master에게 지시합니다. Master는 클러스터의 node에게 실행할 container를 예약합니다.

Node는 Master가 사용하는 Kubernetes API로 통신합니다. 최종 사용자도 Kubernetes API를 직접 사용하여 클러스터와 상호 작용할 수 있습니다.

Deployment

Kubernetes 클러스터가 실행되면 container application을 그 위에 배포할 수 있습니다.

https://kubernetes.io/docs/tutorials/kubernetes-basics/deploy-intro/

이렇게 하려면 Kubernetes Deployment의 설정(configuration)을 생성해야 합니다. Deployment는 Kubernetes에게 application의 instance를 만들고 업데이트하는 방법을 알려줍니다. Deployment를 만들었으면, Kubernetes Master는 언급된 application instance를 클러스터의 개별 Node에 추가해 Scheduling 합니다.

Application instance가 생성되면 Kubernetes Deployment Controller는 해당 instance를 지속적으로 모니터링합니다. instance를 호스팅하는 node가 중지되거나 삭제되면, Deployment controller가 이를 대체합니다. 이것은 self-healing 메커니즘(mechanism)으로 machine failure 또는 유지 보수를 해결하기 위함입니다.

이전의 orchestration world에서는 설치 스크립트가 종종 application을 시작하는데 사용되지만, machine failure 부터의 복구(recovery)는 허용되지 않았습니다. Kubernetes Deployment는 application instance를 생성하고 Node간에 실행되도록 유지함으로써 application 관리에 근본적으로 다른 접근 방식을 제공합니다.

Kubernetes의 명령 인터페이스인 kubectl을 사용하여 Deployment를 생성하고 관리할 수 있습니다. kubectl은 Kubernetes API를 사용하여 클러스터와 상호 작용합니다. Deployment를 생성할 때, application의 container image와 실행할 replicas(복제본)의 수를 지정해야 합니다. 나중에 정보를 변경하여 Deployment를 업데이트할 수 있습니다.

Pods

Kubernetes의 핵심은 Pod입니다.

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

Pod는 하나 이상의 container의 collection을 나타내고 보유합니다. 일반적으로 서로에 대해 크게 의존하는 여러 container가 있는 경우, container는 단일 Pod안에 패키지 됩니다.

Pod는 하나 이상의 container(ex Docker Containers)의 그룹이며, 공유 저장 장치/네트워크 그리고 container 실행 방법에 대한 사양을 포함합니다. Pod의 내용은 항상 같은 위치에 있고, 공동으로 스케줄(schedule)되며, 공유 컨텍스트(context)에서 실행됩니다. Pod는 application 별 “logical host”를 모델링합니다. 즉, 비교적 밀접하게 결합된 하나 이상의 application이 하나의 Pod에 포함된 것을 말하는 것입니다. 이것은 사전 container 환경에서 물리적(physical) 또는 가상 머신(virtual machine)에 서 실행되었을 것입니다.

Kubernetes는 Docker보다 많은 container runtime을 지원하지만, Docker는 가장 일반적으로 알려진 runtime이며, Docker 용어로 Pod를 설명하는데 도움이 됩니다.

Pod의 공유 컨테스트(shared context)는 Docker가 container를 격리하는 것과 동일한 Linux의 namespace, cgroup 및 잠재적으로 격리(isolation)된 영역의 집합입니다. Pod의 context 내에서 개별 application에 하위 분리가 추가로 적용될 수 있습니다.

Pod 내의 container는 IP 주소와 port 공간을 공유하면서 localhost를 통해 서로를 찾을 수 있습니다. 또한 SystemV의 세마포어(semaphore) 또는 POSIX 공유 메모리와 같은 표준 프로세스간 통신을 사용하여 서로 통신할 수 있습니다. 다른 Pod의 container에는 고유한 IP 주소가 있고, 특별한 구성없이는 IPC(Inter-Process Communication) 통신을 할 수 없습니다. 이러한 container는 일반적으로 Pod IP 주소를 통해서 서로 통신합니다.

* IPC 통신(Inter-Process Communication) : 프로세스들 사이에 서로 데이터를 주고받는 행위 또는 그에 대한 방법이나 경로

또한 Pod 내의 application은 Pod의 일부로 정의되고, 각 application의 파일시스템(filesystem)에 마운트(mount)할 수 있도록 만들어진 공유 볼륨(Volume)에 액세스할 수 있습니다.

Docker와 관련하여 Pod는 공유 네임스페이스(namespaces)와 공유 볼륨(Volume)이 있는 Docker container group으로 모델링됩니다.

Pod는 Kubernetes 플랫폼의 원자 단위입니다.

https://kubernetes.io/docs/tutorials/kubernetes-basics/explore-intro/

Kubernetes에서 Deployment를 만들면 해당 배치는 container가 있는 pod를 만듭니다. (직접 container를 만드는 것과는 반대) 각 pod는 node가 예정된 node에 연결되어 종료될 때(재시작 정책에 따라)까지 남아있거나, 삭제됩니다. 노드 장애(node failure)가 발생하면 클러스터의 다른 사용 가능한 node에서 동일한 pod가 예약됩니다.

Nodes

pod는 항상 Node에서 실행됩니다. Node는 Kubernetes의 작업자 머신(Worker Machine)이며, 클러스터에 따라 Physical Machine이거나 VM 일 수 있습니다. 각 Node는 Master가 관리합니다. Node는 여러 개의 pod를 가질 수 있으며, Kubernetes Master는 클러스터의 Node에서 Pod 스케줄링(Scheduling)을 자동으로 처리합니다. Master의 자동 스케줄링은 각 Node에서 사용 가능한 자원(resource)를 고려합니다.

모든 Kubernetes Node는 적어도 다음과 같이 실행됩니다.

- Kubernetes Master와 Node 사이의 통신을 담당하는 프로세스인 Kubelet이 실행중인 Pod와 machine에서 실행 중인 container를 관리합니다.

- Container Runtime(ex Docker, rkt)가 Registry에서 container image를 pull로 가져오고, container를 unpacking하고, application을 실행합니다.

다시 돌아와서 여기 예제에서는 monolith와 ngix container가 포함된 pod가 있습니다.

Pod는 또한 Volume을 가지고 있습니다.

https://kubernetes.io/docs/concepts/storage/volumes/

Volume은 Pod가 살아 있는한 계속 살아있는 data 디스크(disk)이며, 해당 pod의 container에서 사용할 수 있습니다. pod는 내용에 대한 공유 namespace를 제공합니다. 즉 Pod의 두 개의 container가 서로 통신할 수 있으며, 연결된 Volume도 공유한다는 것을 의미합니다.

또한 Pod는 Network namespace를 공유합니다. 이것은 Pod당 하나의 IP 주소가 있음을 의미합니다.

Creating Pods

Pod는 pod 설정(configuration) 파일을 사용해 생성할 수 있습니다. monolith pod configuration 파일을 살펴봅시다.

$ cat pods/monolith.yaml

여기서 주목해야할 몇 가지 사항이 있습니다.

- pod는 container(monolith)로 구성됩니다.

- 시작할 때 container에게 인수(argument)를 전달합니다.

- http 트래픽(traffic)을 위해 port 80을 개방합니다.

kubectl create 명령어를 통해 monolith pod를 생성합니다.

$ kubectl create -f pods/monolith.yaml

kubectl get pods 명령을 사용하여 기본(default) namespace에서 실행 중인 모든 pod를 나열합니다.

$ kubectl get pods

pod가 실행되면, kubectl describe 명령을 사용하여 monolith pod에 대한 자세한 정보를 얻을 수 있습니다.

$ kubectl describe pods monolith

pod의 IP 주소와 이벤트 로그를 포함하여 monolith pod에 대한 많은 정보를 볼 수 있습니다. 이 정보는 문제를 해결할 때 유용할 것입니다.

Kubernetes를 사용하면 설정(configuration) 파일에 설명을 작성하고, 실행 중일때 정보를 볼 수 있으므로 pod를 쉽게 만들 수 있습니다.

Interacting with Pods

Pod에는 기본적으로 private IP 주소가 할당되며, 클러스터 외부에서는 도달할 수 없습니다. kubectl port-forward 명령을 사용하여 local port를 monolith pod의 port에 맵핑해봅시다.

두 개의 터미널을 열어, 하나는 kubectl port-forward 명령을 실행하고, 다른 터미널은 curl 명령을 실행합니다.

$ kubectl port-forward monolith 10080:80

첫 번째 터미널을 열어 curl을 사용해 pod와 통신합니다.

$ curl http://127.0.0.1:10080

container에서 “hello”라는 메시지를 받을 수 있습니다.

자 이번에는 curl 명령을 사용해 secure이라는 보안된 엔드포인트(endpoint)에 도달했을 때 어떤 일이 생기는지 살펴볼까요?

$ curl http://127.0.0.1:10080/secure

monolith에 인증 토큰(auth token)을 받으려면 로그인해야 합니다

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

로그인 프롬프트(prompt)에서 super-secret 비밀번호인 password를 사용해 로그인합니다…

로그인하면 JWT 토큰(token)이 인쇄됩니다.

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

토큰(token)을 복사하고 그것을 사용하여 curl을 이용해 secure로 hit 해봅시다.

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

Cloud shell은 긴 문자열 복사를 제대로 처리하지 않으므로 이전 단계의 환경 변수에 복사됩니다.

이 시점에서 우리는 application에 응답(response)를 얻을 수 있습니다.

monolith pod에 대한 로그(log)를 보려면 kubectl logs 명령을 사용합니다.

$ kubectl logs monolith

세 번째 터미널을 열고 -f 플래그를 사용하여 실시간으로 일어나는 log stream을 가져옵니다.

$ kubectl logs -f monolith

두 번째 터미널에서 curl을 사용하여 monolith와 상호 작용하면 log를 업데이트할 수 있습니다.

$ curl http://127.0.0.1:10080

monolith pod에서 대화형 셸(interactive shell)을 실행하려면 kubectl exec 명령을 사용합니다. 이는 container 내에서 문제를 해결할 때 유용할 수 있습니다.

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

예를 들어 monolith container에 shell이 있으면 ping 명령을 사용하여 외부 연결을 테스트할 수 있습니다.

# ping -c 3 google.com

interactive shell에서 작업을 완료하면 log out을 합니다.

# exit

보다시피 pod와 상호 작용하는 것은 kubectl 명령을 사용하는 것만큼 쉽습니다. container를 원격으로 접속하거나, login shell을 사용해야 하는 경우, Kubernetes에서 모든 것을 제공합니다.

Services

Pod는 지속성이 있는 것은 아닙니다. 여러 가지 이유(준비상태 점검)로 중지되거나 시작될 수 있으며 이로 인해 문제가 발생합니다.

Pod와 통신하고 싶다면 어떻게 될까요? 다시 시작할 때 IP 주소가 다를 수 있습니다. Service가 들어오는 지점입니다. Service는 Pod에 안정적인 엔드포인트(endpoint)를 제공합니다.

https://kubernetes.io/docs/concepts/services-networking/service/

Kubernetes Pod는 수명주기(lifecycle)이 있습니다. Worker node가 종료되면 node에서 실행 중인 Pod도 손실됩니다. ReplicationController는 application을 계속 실행하기 위해 새로운 Pod를 생성하여 클러스터를 원하는 상태로 동적으로 돌릴 수 있습니다. 예로 3개의 복제본(replicas)이 있는 이미지를 처리(image processing)하는 backend를 생각해봅시다. 복제본은 대체 가능합니다. frontend는 backend 복제본이나, Pod가 손실되거나 재생성되어도 신경쓰지 않아도 됩니다. 즉, Kubernetes 클러스터의 각 Pod에는 고유한 IP 주소(동일한 Node의 Pod)가 있으므로 Pod 간의 변경 사항을 자동으로 조정하여 application이 계속 작동할 수 있어야 합니다.

Kubernetes의 Service는 Pod의 논리적 집합과 액세스할 수 있는 정책을 정의하는 추상화(abstraction)입니다.

https://kubernetes.io/docs/tutorials/kubernetes-basics/expose-intro/

Services는 종속적인 Pod 간의 느슨한 결합(coupling)을 가능하게 합니다. Services는 모든 Kubernetes 객체와 마찬가지로 YAML 또는 JSON을 사용하여 정의됩니다. Service가 대상으로 하는 Pod는 LabelSelector에 의해 결정됩니다.

Services는 Label을 사용하여 그들이 작동하는 pod를 결정합니다. 만약 Pod가 올바른 Label을 가지고 있다면,  자동으로 선택되고 Services에 노출됩니다.

Services가 Pod 집합에 제공하는 액세스 수준은 Service 유형에 따라 다릅니다. 현재는 3가지 유형이 있습니다.

- ClusterIP (내부): 기본 유형은 이 service가 클러스터 내부에서만 볼 수 있습니다.

- NodePort: 클러스터의 각 Node에 외부에서 액세스할 수 있는 IP를 제공합니다.

- LoadBalancer: 서비스 트래픽을 Node 안에서 전달하는 클라우드 공급자의 load balancer를 추가합니다.

우리는 이제 Service를 만들고, Label Selector를 사용해 제한된 Pod를 외부에 expose 합니다.

Creating a Service

Sevice를 만들기 전에 먼저 https 트래픽을 처리할 수 있는 보안을 갖춘 Pod를 생성합시다.

디렉토리를 변경합니다.

$ cd ~/orchestrate-with-kubernetes/kubernetes

monolith service에 설정 파일을 살펴봅시다.

$ cat pods/secure-monolith.yaml

secret-monolith의 설정 데이터(configuration data)을 이용해 pod를 생성해봅시다.

$ 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가 생겼으므로, 이제 secure-monolith Pod를 외부에 expose할 차례입니다. 그렇게 하기 위해서는 Kubernetes service를 생성합시다.

monolith service 설정 파일을 살펴봅시다.

$ cat services/monolith.yaml

kind: Service
apiVersion: v1
metadata:
 name: "monolith"
spec:
 selector:
   app: "monolith"
   secure: "enabled"
 ports:
   - protocol: "TCP"
     port: 443
     targetPort: 443
     nodePort: 31000
 type: NodePort

알아야 할 것은

- app: “monolith” 그리고 secure: “enabled” label이 있는 모든 Pod를 자동으로 찾고, expose 하는데 사용되는 selector가 있습니다.

- 이제 우리는 port 31000에서 nginx(port 443)으로 외부 트래픽을 전달하는(forward) 방법으로 node-port를 expose 해야합니다.

monolith 서비스 구성 파일에서 monolith service를 생성하려면 kubectl create 명령어를 사용합니다.

$ kubectl create -f services/monolith.yaml

다음의 출력은 port를 사용하여 Service를 expose 하고 있음을 나타냅니다. 즉, 다른 application이 서버 중 하나의 port 31000에 바인딩(binding)하려고 하면 port 충돌이 발생할 수 있습니다. 일반적으로 Kubernetes는 port 31000 지정을 처리합니다.

gcloud compute firewall-rules 명령을 사용하여 expose 된 node-port에 monolith service에 대한 트래픽을 허용합니다.

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

모든 것이 설정되었으므로 port 전달을 사용하지 않고, 클러스터 외부에서 보안 일체형 service에 접근할 수 있어야 합니다.

먼저 Node 중에 하나에 대한 IP 주소를 얻은 다음 curl을 사용하여 service에 접근합니다.

$ gcloud compute instances list

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

도달하지 못하고 Connection Error가 발생합니다.

다음의 두 명령어를 사용해봅시다.

$ kubectl get services monolith

$ kubectl describe services monolith

Adding Labels to Pods

현재 monolith service에는 엔드포인트(endpoint)를 가지고 있지 않습니다. 이와 같은 문제를 해결하는 방법은 label query와 함께 kubectl get pods 명령을 사용하는 것입니다.

다음의 명령어로 우리는 monolith라는 label로 실행되는 Pod가 꽤 많이 있음을 알 수 있습니다.

$ kubectl get pods -l "app=monolith"

그러나 app는 monolith이면서 secure은 enabled 인것은 어떨까요?

$ kubectl get pods -l "app=monolith,secure=enabled"

이 Lable query의 결과는 나오지 않습니다. “secure=enabled” Label을 추가해야 할 필요가 있습니다.

kubectl label 명령을 사용하여 Label을 추가하고, secure-monolith Pod에 추가합시다. 그런 다음 Label이 업데이트 되었는 지 확인할 수 있습니다.

$ kubectl label pods secure-monolith 'secure=enabled'

$ kubectl get pods secure-monolith --show-labels

이제 우리 Pod에 올바르게 Label이 지정되었으므로, Service의 엔드포인트(endpoint)를 확인해봅시다.

$ kubectl describe services monolith | grep Endpoints

자 이제, Node 중 하나를 curl로 이용해 다시 접속해봅시다.

$ gcloud compute instances list

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

Deploying Applications with Kubernetes

마지막으로 production 환경에서 container를 확장하고 관리할 수 있도록 준비하는 것입니다. 그것은 Deployments가 들어오는 곳입니다. Deployments는 실행 중인 Pod가 사용자가 지정한 Pod의 원하는 수와 동일한지 확인하는 선언적인 방법입니다.

https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#what-is-a-deployment

Deployments의 주요 이점은 pod 관리에 대한 낮은 수준의 세부 사항을 추상화하는 데 있습니다. Deployments는 복제(replicas) 세트를 사용하여 pod 시작 및 중지를 관리합니다. pod를 업데이트하거나 확장해야 하는 경우 Deployments가 이를 처리합니다. 어떤 이유로 든 다운 될 경우 배치가 다시 시작되도록 처리합니다. 간단한 예를 살펴 보겠습니다.

Pod는 생성된 Node의 수명동안 Node에 연결됩니다. 위의 예에서 Node3은 실패(failure)되고, Deployment는 새로운 Pod를 생성하고 Node2에서 시작했습니다.

이제는 Pod 및 Service에 대해 배운 모든 것을 결합하여 배포를 사용하여 모노리스 응용 프로그램을 더 작은 Service로 분해해야 합니다.

Creating Deployments

우리는 monolith 앱을 세 가지의 작은 서비스로 만들 수 있습니다.

- auth는 인증된(authenticated) 사용자에 대해 JWT 토큰을 생성합니다.

- hello - 인증된 사용자에게 응답합니다.

- frontend - 트래픽을 auth 나 hello Service로 라우팅합니다.

우리는 각 Service마다 Deployments를 만들 준비가 되었습니다. 그런 다음, frontend Deployment를 위한 외부 Service와 hello와 auth를 위한 내부 Service를 정의합니다. 완료되면 monolith와 마찬가지로 Service와 상호 작용할 수 있고, 개별적으로 확장과 배포를 할 수 있습니다.

Deployment 설정 파일을 검토하여 시작합니다.

$ cat deployments/auth.yaml

deployment는 1개의 복제본(replica)가 생성되면 auth container로는 버전 1.0.0을 사용하고 있습니다.

auth deployment를 생성하기 위해서 kubectl create 명령을 실행하면, Deployment manifest 데이터를 따르는 하나의 Pod가 생성됩니다. 즉 Replicas field에 지정된 번호를 변경하여 Pod의 수를 조정할 수 있습니다.

$ kubectl create -f deployments/auth.yaml

이제 auth deployment를 위한 service를 만들 차례입니다.

$ kubectl create -f services/auth.yaml

다음은 hello deployment를 만들고 expose 합니다.

$ kubectl create -f deployments/hello.yaml

$ kubectl create -f services/hello.yaml

다시 한번 frontend 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를 생성하고 container와 함께 일부 설정 데이터를 저장해야 하기 때문에 한 가지 단계가 더 있습니다.

frontend와 상호 작용하여 외부 IP를 가져와 curl을 시도합니다.

$ kubectl get services frontend

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

hello 응답을 받을 수 있습니다.

Clean up

비용을 절감하기 위해서는 Resource를 직접 정리하는 방법을 알아야 합니다.

여기에는 cleanup 스크립트가 있습니다.

수행하는 작업을 확인해봅시다.

$ cat cleanup.sh

$ chmod +x cleanup.sh

$ ./cleanup.sh

$ gcloud container clusters delete io --zone

Y 키를 누른 다음 Enter 키를 눌러 정리를 합니다.