2019년 1월 21일 월요일

[클라우드 스터디잼-10] NGINX Ingress Controller on Google Kubernetes Engine

이번 과정에서는 "Ingress"에 대해서 알아 볼 수 있었습니다.

"Ingress"는 resource와 controller로 구성되어 있습니다.
resource는 "Ingress"의 동작에 대한 규칙을 정해 놓은 yaml이며,
controller는 layer7에 해당하는 로드밸런서의 역할을 제공합니다. 즉 http 요청에 대한 처리와 부하 분산을 제공합니다.
controller로는 gce, nginx, envoy, haproxy, istio, kong, traefik 을 이용할 수 있습니다.

과정에서는 "hello-app" 이라는 "Service"를 노출합니다. 그리고 helm을 이용해서 nginx-ingress를 kubernetes cluster에 설치합니다.
kind가 "Ingress"인 yaml 파일을 만듭니다. 이때 "path: /hello"로 지정하며, backend를 "serviceName: hello-app"과 "servicePort: 8080" 으로 지정을 합니다.

이렇게 해서 "nginx-ingress-controller"가 제공하는 "EXTERNAL-IP"에 "/hello"로 웹브라우저에서 연결을 해보면 서비스가 제공되는 것을 확인해 볼 수 있습니다.

"Ingress"를 통해서 로드밸런서를 제공하기 위해서는 "Service" 생성 과정에서 type의 지정이 필요합니다.

"Pod"는 죽고 사는 과정이 계속해서 반복되고 ip가 계속해서 변동됩니다.
이러한 "Pod"를 선택적으로 동일한 ip로 접근하기 위해서 "Service"를 사용합니다.
이 "Service"들이 제공하는 타입에 따라서 서비스가 제공되는 형태가 변경이 됩니다.

clusterip는 클러스터 내부에서만 접근 가능한 형태의 service입니다.
그리고 nodeport는 "node이름:port"로 외부에서도 접근이 가능하도록 서비스를 제공하는 형태입니다.
loadbalancer는 클라우드 서비스를 제공하는 벤더들에서 제공하는 로드밸런서를 사용합니다.
마지막으로 externalname은 외부의 서비스를 클러스터 내부에서 사용하고자 할 때 사용하는 형태입니다.

이와 같이 클라우드 서비스 벤더에서 제공하는 로드밸런서를 사용할때는 "Service"의 타입을 loadbalancer로 지정하고, "Ingress"를 통해서 제공하는 로드밸런서를 사용할때는 nodeport를 사용해서 "Service"를 생성합니다.

2019년 1월 17일 목요일

[클라우드 스터디잼-9] Helm Package Manager

이번 과정에서 kubernetes에서 사용할 수 있는 패키지 관리자에 대해서 알아 볼 수 있었습니다.
Helm은 클라이언트 역할을 하는 helm, 서버 역할을 하는 tiller 그리고 설정 정보들의 관리를 위한 chart로 이루어져 있습니다.
여기에서 클라이언트(helm)라고 하는건 클러스터의 외부에서 작업을 지시하기 위한 도구이고, 실제로 클러스터 안쪽에서 동작 하는건 서버(tiller)라고 보면 됩니다.

helm의 설치는 간단합니다.

$ curl https://raw.githubusercontent.com/kubernetes/helm/master/scripts/get > get_helm.sh
$ chmod 700 get_helm.sh
$ ./get_helm.sh

근데 이 과정 다음에 갑자기 tiller를 위한 계정을 만들고 해당 계정을 무언가에 바인딩을 합니다.
이 과정은 tiller가 클러스터 전체에서 권한을 갖기 위한 방법으로 여기면 될 것 같습니다.
비교가 적절할지 모르겠지만, 리눅스에서는 "sudo" 로 권한을 얻고, 윈도우에서 "관리자 권한"을 얻는 것 처럼 tiller에게도 더 높은 권한을 갖을 수 있도록 해주는 과정이라고 이해를 했습니다.
(권한에 대한 내용은 "http://bcho.tistory.com/1272" 를 참고하면 좋을것 같습니다.)

계정을 생성하고 권한을 설정하는 과정은 다음과 같습니다.

$ kubectl -n kube-system create serviceaccount tiller
$ kubectl create clusterrolebinding tiller --clusterrole cluster-admin --serviceaccount=kube-system:tiller

그리고 권한을 제거하고 계정을 삭제하는 과정은 다음과 같이 합니다.

$ kubectl delete clusterrolebinding tiller
$ kubectl -n kube-system delete serviceaccount tiller


이러한 과정은 kubernetes의 권한 관리 방식을 rbac를 이용할 경우에 이렇게 하고, rbac 이외에 abac라는 방식은 다른 방법이 존재하는것 같습니다.

계정을 생성했으면 tiller를 설치합니다.

$ helm init --service-account=tiller


tiller가 설치된 후에 "kubectl get po --namespace kube-system" 로 확인해 보면 "tiller-deploy-blahblah"가 실행되고 있는걸 확인 할 수 있습니다.

그리고 tiller를 제거하기 위해서는

$ kubectl -n kube-system delete deployment tiller-deploy

를 해주고 위에서 이야기했던 권한 제거하는 작업을 해주면 됩니다.

그리고 chart를 업데이트하고 chart를 이용해서 설치하는 과정은 아무런 고민없이 사용이 가능할 정도로 간단했습니다.

2019년 1월 16일 수요일

[클라우드 스터디잼-8] Setting up a Private Kubernetes Cluster

이번 과정의 실습을 진행하면서 클러스터에 대한 접근을 제한 할 수 있도록 하기 위한 방법에 대해서 알 수 있었습니다. 하지만 전체 내용에 대해서 정확하게 이해를 하지 못했습니다.

해당 내용은 이후에 비공개 클러스터 설정(https://cloud.google.com/kubernetes-engine/docs/how-to/private-clusters) 에 대한 내용이 실습 내용과 동일하므로 추후에 이해가 가능한 시점이 되면 다시 한번 시도해 보려고 합니다.

아래는 내용을 이해하기 위해서 학습했던 내용들의 링크입니다.

- 네트워크 입문: http://kujung.tistory.com/category/%EB%98%A5%20%EC%8B%B8%EA%B8%B0/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC
- IPv4 네트워크 주소와 호스트 주소/서브넷팅/IP Class: http://itsaessak.tistory.com/174
- IP 주소체계와 클래스 구별법 (IPV4): http://korean-daeddo.blogspot.com/2015/12/ip.html
- 서브넷 마스크와 서브넷팅 계산법: http://korean-daeddo.blogspot.com/2016/01/blog-post_26.html

그리고 구글 클라우드 플랫폼 서비스에서 제공하는 GKE 관련 문서(https://cloud.google.com/kubernetes-engine/docs/)들 중에서 함께 보면 도움이 되는 부분들입니다.
- 별칭 IP를 사용하여 VPC 네이티브 클러스터 만들기: https://cloud.google.com/kubernetes-engine/docs/how-to/alias-ips?hl=ko
- 네트워크 개요: https://cloud.google.com/kubernetes-engine/docs/concepts/network-overview?hl=ko

그 외에도 "CIDR" 에 대해서 학습을 할 수 있었습니다.


2019년 1월 14일 월요일

[클라우드 스터디잼-7] Build a Slack Bot with Node.js on Kubernetes

이번 과정은 Secret 객체에 대해서 좀 더 자세하게 알아볼 수 있는 과정이었습니다.

서비스를 제공하는 프로그램(node.js 코드)을 Docker image로 만든 다음 Registry Server에 Push를 합니다.
제공하는 서비스에서 외부의 서비스(slack)를 사용하기 위해서 민감한 정보인 token이 존재합니다. 이 내용이 코드상 또는 image 상에 존재하지 않게 Image를 만들고자 합니다.
그래서 별도로 "slack-token" 파일을 만들어서 파일을 통해서 token 정보를 제공하도록 만들어 놓았습니다. 해당 파일을 경로와 파일명을 포함해서 환경변수 "slack_token_path"에 등록해 놓고, 코드상에서는 환경 변수인 "slack_token_path"에 지정되어 있는 경로의 파일로 부터 token 정보를 읽어서 사용합니다.

실습 과정에서 보여지는 Docker image를 만드는 Dockerfile에는 token 정보를 다루고 있지 않습니다. 이를 통해서 해당 정보는 배포가 되지 않는다는걸 알 수 있습니다.

이제 Kubernetes 클러스터에서 배포를 하기 위해서 token 정보를 container들이 인식할 수 있도록 해주어야 합니다.
그래서 token 정보를 Secret으로 생성해서 클러스터에 배포합니다.

다시 반복해서 확인을 해보면, container에서 제공되는 서비스는 "slack_token_path" 라는 이름의 환경 변수를 읽어 파일 경로를 구할 수 있습니다. 이 경로를 통해서 token 정보를 알아냅니다. 그리고 구해진 token 정보를 이용해서 slack이 제공하는 기능을 이용할 수 있습니다.

이렇게 container에서 token 정보를 구할 수 있도록 하기 위해서, Deployment의 yaml 파일에서 container가 사용할 환경 변수를 등록할 수 있는 "env"를 이용해서 "slack_token_path"를 등록합니다. 이 환경 변수(slack_token_path)는 token 정보가 존재하는 "경로와 파일명"의 조합입니다.
이 경로에 해당 파일을 만들기 위해서 volumeMounts를 이용해서 지정된 경로에 volume을 mount 합니다.

이때 사용되어질 "secret" 타입의 volume은 token 정보를 Pod에서 사용할 수 있도록 하는 "Secret" 객체입니다.

token은 민감한 정보이기 때문에 별도의 과정을 통해서 전달되어 진다고 상상해 볼 수 있습니다. 어떠한 방식으로든지 전달된 token을 이용해서 "Secret"을 생성하는 과정을 거칠 수 있습니다.

Secret을 생성하는 인자 중 에 "generic"을 사용합니다. generic은 로컬의 파일등을 이용해서 Secret을 만들겠다는 의미로 type에 따라서 Secrete을 생성하는 방식을 달리 할 수도 있습니다.

2019년 1월 11일 금요일

[클라우드 스터디잼-6] Running a MongoDB Database in Kubernetes with StatefulSets

지금까지의 과정 중에서 가장 어려웠습니다.;;; 그리고 제대로 이해를 한건지도 잘 모르겠습니다.
일단을 이해했다고 생각되는 정도만 정리를 해봤습니다.

이번 과정은 StatefulSet에 대한 이해를 목표로 하고 있습니다.
StatefulSet에 대한 이해를 위해서는 Headless Service에 대한 이해와 StorageClass에 대한 이해가 필요했습니다.

StorageClass는 상태를 갖는걸 확인하기 위한 실습이 필요하다보니, Volume을 사용해야 하고 StatefulSet의 scale을 조정하게 되는 것에 따라서 Volume도 같이 조정이 되어야 해서 StorageClass 컨트롤러를 통해서 Volume을 동적으로 조정할 수 있도록 하려고 사용 된 것 같습니다.
(StorageClass는 다음에 기회가 되면 다시 좀 알아 봐야 할 것 같습니다.)

StatefulSet의 목적은 기존에 Deployment에서 상태가 없는 Pod들을 관리하기 위한 목적이 포함되어 있었다고 하면, 이 컨트롤러는 상태를 갖는 Pod를 관리하기 위한 목적이라고 이해를 했습니다. 데이터라는 상태를 갖는 mongodb를 실습에서 사용을 한 것 같습니다.

그리고 Deployment같은 컨트롤러의 경우에 Service 컨트롤러를 통해서 노출을 시켜줄 수 있었던 것 처럼 StatefulSet도 Service 컨트롤러를 이용해서 노출을 합니다. 여기에서 StatefulSet은 Headless Service라고 불리는 설정으로 노출이 되게 됩니다. Service를 정의하고 있는 yaml파일을 보시면 “clusterIP: None”으로 지정이 되어 있는걸 볼 수 있습니다. 이는 로드밸런서의 영향을 받지 않는 서비스를 정의할 때 사용한다고 합니다.

StatefulSet 컨트롤러를 통해서 관리되는 Pod는 생성되는 순서도 중요하기 때문에 Pod를 조회해보면 이름이 mongo-0, mongo-1... 과 같이 순서를 확인할 수 있는 숫자가 붙어 있습니다.
생성되는 순서도 0부터 차례대로 생성이 되고 scale을 통해서 replicas를 조정하면 차례대로 늘어나고 역순으로 줄어드는걸 확인 할 수 있었습니다.

Volume에 대한 이해가 없이 StatefuleSet을 바로 이해를 하려고 한다는게 무리가 있어 보입니다. 그래서 이후에 꼭 Volume에 대한 이해를 해보는 기회를 갖어야 할 것 같습니다.

2019년 1월 10일 목요일

[클라우드 스터디잼-5] Continuous Delivery with Jenkins in Kubernetes Engine

이번 과정은 Jenkins와 Kubernetes를 이용한 배포 자동화를 실습해 볼 수 있었습니다.
분량은 많지만 이해가 어렵지는 않은 내용이었습니다.

실습을 해보면서 Namespace라는 객체와 Helm이라는 패키지 관리 도구를 사용해 볼 수 있습니다. Namespace는 일반적으로 우리가 알고 있는 용도인데요. 논리적으로 무언가를 구분지어서 사용하고 싶을때 사용하는게 목적이라고 보면 될 것 같습니다.
이전 과정에서 배웠던 배포를 위한 전략에서는 label을 사용했었다면, 이번에는 Namespace를 사용해서 비슷한 문제 상황을 해결하는걸 경험해 볼 수 있습니다.

그리고 helm은 Kubernetes의 클러스터에 올라갈 수 있도록 미리 정의해서 배포해 놓은걸 사용할 수 있게 해주는 도구였습니다. 이번 실습 과정 중에는 Jenkins를 helm을 이용해서 설치를 했습니다.
(뒤에 있는 과정 중에서 helm을 좀 더 자세하게 다루는것 같으니 여기서는 이렇다는 정도만 확인하고 넘어가도 될 것 같습니다.)

이제 Jenkins를 통해서 배포가 자동화 되는 시나리오를 학습해 보기 위해서 서비스가 제공되는 과정을 만들어 놓습니다.
실제 서비스와 Canary 배포를 위한 Namespace를 "production", "canary"로 만들어서 배포를 하고 Service를 적용해 놓았습니다.

그리고 Jenkins에서 Pipeline을 만들어 놓습니다.
이 과정중에서 가장 중요한건 "Scan Multibranch Pipeline Trigger"가 아닐까 싶습니다.
이 설정으로 인해서 지정한 git 경로의 branch들에 변화가 생기는걸 지속적으로 확인하고 변화가 있을때 배포 작업을 시작합니다. branch에 변화가 생긴걸 확인하게 되면 build 및 기타등등의 Jenkins가 목적으로 하는 작업들을 수행 후, Jenkins에서 Kubernetes의 클러스터에 해당하는 branch 명으로 Namespace를 만들어서 배포하게 됩니다.

개발하는데 사용이 되었던 branch가 "new-feature"라면 "new-feature"라는 이름의 Namespace가 생성되고 해당 Namespace에 배포를 하게 됩니다. Canary 배포를 하고자 한다면, branch를 "canary"로 만들어서 배포를 하면 됩니다. 그리고 master branch의 경우에는 Jenkinsfile에 보면, master branch의 경우 "production" Namespace를 이용하도록 지정되어 있습니다.

이번 과정에서는 Namespace를 활용하면, 하나의 Kubernetes 클러스터 상에서도 각자 목적이 다른 솔루션들이 영역 구분을 하고 배치해도 흐름이 끊기지 않고 계속해서 작업이 이어지도록 할 수 있다는걸 학습했습니다.
각 객체들(Deployment, Service, Namespace ...)의 정의와 특성 그리고 한계점에 대해서 명확하게 파악해 놓으면 필요한 상황별로 설계를 하는데 도움이 많이 될 것 같습니다.

2019년 1월 9일 수요일

[클라우드 스터디잼-4] Managing Deployments Using Kubernetes Engine

이번 장에서는 "Deployment"가 어떤 역할을 할 수 있으며, 이를 이용해서 취할 수 있는 배포 전략에 대해서 알아볼 수 있었습니다.
(이번 장에서 실습을 위해서는 필수적으로 compute/zone 설정을 us-central1-a로 지정해 놓아야 cluster 생성을 정상적으로 할 수 있습니다.)

Deployment 뿐만이 아니라 다른 객체들을 사용하기 위해서도 yaml을 작성할때 각 필드에 대한 정보를 어디에서 확인해야 하는지가 궁금했습니다.
kubectl explain deployment
kubectl explain --recursive
kubectl explain deployment.metadata.name
등과 같이 확인을 할 수 있습니다.

Deployment는 ReplicaSet으로 Pod를 관리할 수 있도록 합니다. 그래서 "replicas"를 조정해서 서비스를 확장하거나 축소할 수 있습니다.
Deployment가 수정되면 Rolling 업데이트 방식으로 기존의 Pod가 줄어들면서 새로운 Deployment가 적용된 Pod가 늘어나는 방식으로 교체가 됩니다.
ReplicaSet을 조회해보고  rollout의 history를 조회해서 업데이트의 상태를 확인해 볼 수 있었습니다. 이렇게 Deployment가 적용되는 방식에 대해서는 "rollout"의 pause, status, resume, undo 등으로 상태등을 조정할 수 도 있었습니다.

배포를 관리하는 방식으로 Canary, Blue-Green 과 같은 방식들이 있습니다.

처음에 Canary 배포에 대한 부분은 실습을 하다만 느낌이 들었는데요, 그런 느낌은 Canary 배포의 목적에 대해서 알지 못 해서 그랬던것 같습니다.
실제 배포를 하기 전에 서비스의 실사용 환경에서 제한된 사용자를 선택해서 테스트 해보기 위한 정도라고 생각을 하고 실습을 다시 해보니 괜찮은 방법 같아 보였습니다. 실 서비스로 사용되어지는 Deployment와 배포되기 전에 확인을 위해서 사용되어질 Deployment(Canary)를 구분 지었을때, 문제가 발생하거나 하면 Deployment(Canary)만 조정을 하면 되니 신속한 관리가 가능할것 같았습니다.

Blue-Green 전략은 두 개의 Deployment(Blue/Green)를 적용해 놓고 Service를 원하는 Deployment에 적용시켜 놓는 방식으로 클러스터의 자원을 충분히 확보할 수 있을때 사용하면 좋은 전략인것 같습니다.

배포를 위한 전략들을 하나씩 실습해보면서 Deployment, Service 등의 각 객체의 특성을 잘 파악하고 있어야만, 어떻게 배치 할 수 있는지 그리고 어떤 식으로 운영할지에 대해서 계획 세울수 있겠다 싶었습니다.

[클라우드 스터디잼-3] Orchestrating the Cloud with Kubernetes

이번 장은 우선 "nginx"와 "monolith"라는 단어에 현혹되지 않도록 주의를 해야 할 것 같습니다.

최초에 nginx가 실행되는 Pod는 그거대로 Kubnernetes 작동에 대한 내용이고, Pod에 대한 내용에서 언급되는 nginx와 monolith는 또 그것대로의 내용을 설명합니다.
그리고 다음에 나오는 port-forward에 대한 내용은 또 완전히 별개의 내용입니다.

port-forward는 "Service"로 노출하지 않는 Pod에 대해서 테스트등을 해보기 위해서 아주 유용한 도구인 것 같습니다.
port-forward로 "monolith" Pod의 80 포트를 10080을 지정하면 local의 10080 포트를 사용하고 있는것 처럼 이용이 가능합니다.

"Service"는 Pod가 수시로 죽고 살아나는 과정 중에서 외부에 노출될 수 있는 일정한 IP를 제공하기 위한 목적입니다.
"Service"는 "selector"를 이용해서 Pod에 지정된 "label" 별로 Pod들을 선택할 수 있습니다. 그리고 "Service"의 형태로는 "ClusterIP", "NodePort", "LoadBalancer"가 있습니다.

"secure-monolith" Pod를 생성하는 과정중에 "secret"와 "configmap"을 생성하는게 나오는데 아직은 크게 신경쓰지 않아도 될 것 같습니다.
둘 다 비슷한 성격을 갖는데, "secret"는 패스워드 처럼 민감 데이터를 다루는 성격이고, "configmap"은 환경 설정과 같은 성격의 정보를 다룹니다. 특성 또는 상태를 갖는 정보를 포함하지 않고 Pod가 관리될 수 있도록 해줍니다.

"Deployment"는 "replicas" 항목에 지정된 만큼의 Pod를 관리하기 위한 용도입니다.

앞부분에서 약간의 착각을 할 수 있는 부분이 있기는 했었지만 전체적으로 간단하게라도 kubernetes를 이용한 관리방법에 대해서 이해를 할 수 있는 장 이었던것 같습니다.

2019년 1월 8일 화요일

[클라우드 스터디잼-2] Hello Node Kubernetes

2번째 과정에서는 Kubernetes의 기본적인 동작 방식에 대해서 알아 볼 수 있었습니다.

Kubernetes의 클러스터를 생성하는 과정은 Google Cloud Platform에서 기능을 제공하고 있어서 아주 간편했습니다.
책을 보면서 Kubernetes 공부를 처음 시작하는 과정에서 가장 시간을 많이 소비하게 되는 부분이었는데, 플랫폼에서 제공되는 기능을 glcoud를 이용해서 node와 각 node의 기본적인 설정을 지정후 cluster를 생성하는 명령 하나로 모든 과정이 생략될 수 있게 되었습니다.

그리고 Registry Server에 등록해 놓았던 Image를 이용해서 직접 "Pod"를 만들어보고, "Pod"의 개념과 "Deployment"의 개념이 무엇인지에 대해서 대략적으로 알아 볼 수 있었습니다.

다음으로 "Service"를 이용하면, 배포된 "Pod"들이 어떻게 외부에 노출이 될 수 있는지에 대해서 알아 볼 수 있었습니다.
기존에는 로컬 머신에서 VM들을 생성해서 학습을 하다 보니 외부에 정말 노출이 되는건가? 라는 의문이 들었었는데, "LoadBalancer"를 통해서 IP를 할당 받아서 해보니, 제공하고자 하는 기능이 "Service"를 통해서 외부에 노출이 될 수 있다는걸 확인 할 수 있었습니다.

서비스의 규모를 조정하기 위해서 scale을 이용해서 Pod를 관리하는걸 확인해 볼 수 있기도 했습니다.

마지막으로 서비스가 업데이트되었을때 배포를 하기 위한 과정에 대해서 알아보면서 Image를 새로 만들고 Registry Server에 재 등록을 하고 Deployment를 수정하는 과정을 실습해볼 수 있었습니다. 과정중에 약간 아쉬웠던 점은 Deployment가 수정되고 난 다음에 기존에 Pod가 종료되고 새로운 버전의 Pod가 활성화 되는 과정에 대해서도 확인을 해보면 과정을 이해하는데 더 좋을것 같았습니다.
(Deployment를 edit하는 과정을 완료하고, 바로 "kubectl get pods"를 해보면 확인이 가능합니다.)

추가 사항으로 Kubernetes 대시보드를 보기 위한 방법을 학습하는 부분에서는 해당 url 뒤에 "ui"로 변경을 해보았으나 대시보드가 보여지지는 않았습니다.

[클라우드 스터디잼-1] Intrduction to Docker

구글에서 지원해주는 “2019 클라우드 스터디잼 입문반” 스터디에 참여하기 시작했습니다.
이 스터디는 어떠한 형태로든 모인 멤버들이 일정 기간(1/7~1/27) 동안에 실습이 겸해진 과정(QWIKLABS - Kubernetes in the Google Cloud)을 완수하는 방식입니다.

첫번째 과정으로 “Introduction to Docker” 을 진행 했습니다. 다음은 과정을 진행하면서 학습할 수 있었던 내용의 요약입니다.

처음 해보는 과정이라서 그런지 익숙해지기 위한 시간이 약간 필요했지만 그다지 어렵지는 않았습니다.

Docker의 Image와 Container 그리고 Dockerfile의 이해를 위한 몇 가지의 실습이 진행되었습니다.
실습들을 통해서 Image와 Container를 어떻게 구분지어서 생각해야 하는지를 학습할 수 있었습니다.

그리고 만들어진 Image는 어떻게 배포하고 관리 되어져야 할 지에 대한 이해를 위해서, 구글에서 서비스하고 있는 플랫폼(Google Cloud Platform)이 제공하는 Registry Server에 gcloud라는 도구을 이용해서 Image를 등록하고 등록된 이미지를 이용하는 실습을 진행되었습니다.

이렇게 해서 첫번째 과정이 완료 되었습니다.

간단한 실습과 설명이었지만 Docker 관련 책에서의 분량으로 가늠해 보면 절반 정도의 내용을 압축해 놓은 과정이지 않았나 싶습니다.

[클라우드 스터디잼-10] NGINX Ingress Controller on Google Kubernetes Engine

이번 과정에서는 "Ingress"에 대해서 알아 볼 수 있었습니다. "Ingress"는 resource와 controller로 구성되어 있습니다. resource는 "Ingress"의 동작에 ...