Orchestrating the Cloud with Kubernetes

Overview

In this lab you will learn how to:

• Provision a complete Kubernetes cluster using Kubernetes Engine.
• Deploy and manage Docker containers using kubectl.
• Break an application into microservices using Kubernetes' Deployments and Services.

Kubernetes is all about applications. In this part of the lab you will use an example application called "app".

Note: App is hosted on GitHub and provides an example 12-Factor application. During this lab you will be working with the following Docker images:

• kelseyhightower/monolith - Monolith includes auth and hello services.
• kelseyhightower/auth - Auth microservice. Generates JWT tokens for authenticated users.
• kelseyhightower/hello - Hello microservice. Greets authenticated users.
• nginx - Frontend to the auth and hello services.

 

Kubernetes is an open source project (available on kubernetes.io) which can run on many different environments, from laptops to high-availability multi-node clusters, from public clouds to on-premise deployments, from virtual machines to bare metal.

For this lab, using a managed environment such as Kubernetes Engine allows you to focus on experiencing Kubernetes rather than setting up the underlying infrastructure.

 

이 실습에서의 학습 목표:

 

Kubernetes Engine을 사용하여 완전한 Kubernetes 클러스터를 프로비저닝하기

kubectl을 사용하여 Docker 컨테이너를 배포하고 관리하기

Kubernetes의 배포 및 서비스를 사용하여 애플리케이션을 마이크로서비스로 나누기

 

참고: 앱은 GitHub에서 호스팅되며 예제 12-Factor 애플리케이션을 제공함. 이 실습에서는 다음 Docker 이미지로 작업할 예정.

 

kelseyhightower/monolith - Monolith에는 인증 및 Hello 서비스가 포함됨

kelseyhightower/auth - 인증 마이크로 서비스. 인증된 사용자에 대한 JWT 토큰을 생성

kelseyhightower/hello - 안녕하세요 마이크로서비스입니다.라는 것을 통해 인증된 사용자를 맞이함

nginx - 인증 및 Hello 서비스에 대한 프론트엔드

Kubernetes는 랩톱에서 고가용성 다중 노드 클러스터, 공용 클라우드에서 온프레미스 배포, 가상 머신에서 베어 메탈에 이르기까지 다양한 환경에서 실행할 수 있는 오픈 소스 프로젝트(kubernetes.io에서 사용 가능)임.

 

이 실습에서처럼 Kubernetes Engine과 같은 관리 환경을 사용하면 기본 인프라를 설정하는 대신 Kubernetes에 집중할 수 있음.

Task 1. Get the sample code

태스크 1. 샘플 코드 가져오기

 

1. Clone the GitHub repository from the Cloud Shell command line:

cloud shell 명령줄에서 github 저장소를 복제. 

gsutil cp -r gs://spls/gsp021/* .

2. Change into the directory needed for this lab:

디렉토리 변경!

cd orchestrate-with-kubernetes/kubernetes

3. List the files to see what you're working with:

파일 나열을 통해 작업 중인 항목 확인

ls

The sample has the following layout:

deployments/  /* Deployment manifests */
  ...
nginx/        /* nginx config files */
  ...
pods/         /* Pod manifests */
  ...
services/     /* Services manifests */
  ...
tls/          /* TLS certificates */
  ...
cleanup.sh    /* Cleanup script */

Now that you have the code -- it's time to give Kubernetes a try!

Task 2. Quick Kubernetes Demo

태스크2. 빠른 Kubernetes 데모

 

The easiest way to get started with Kubernetes is to use the kubectl create command.

 

1. Use it to launch a single instance of the nginx container:

kubectl create deployment nginx --image=nginx:1.10.0

Kubernetes has created a deployment -- more about deployments later, but for now all you need to know is that deployments keep the pods up and running even when the nodes they run on fail.

In Kubernetes, all containers run in a pod.

 

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

위 명령어를 사용하여 nginx 컨테이너의 단일 인스턴스를 시작.

 

Kubernetes는 배포를 만들었음. 지금은 배포가 실행되는 노드에 오류가 발생하더라도 배포가 포드를 계속 실행 상태로 유지한다는 점만 알면 됨.

 

*Kubernetes에서 모든 컨테이너는 포드에서 실행됨.

 

2. Use the kubectl get pods command to view the running nginx container:

kubectl get pods 명령을 사용하여 실행 중인 nginx 컨테이너 보기

kubectl get pods

3. Once the nginx container has a Running status you can expose it outside of Kubernetes using the kubectl expose command:

nginx 컨테이너가 Running 상태가 되면 kubectl expose 명령을 사용하여 Kubernetes 외부에 노출할 수 있음.

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

 

So what just happened? Behind the scenes Kubernetes created an external Load Balancer with a public IP address attached to it. Any client who hits that public IP address will be routed to the pods behind the service. In this case that would be the nginx pod.

 

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

 

4. List our services now using the kubectl get services command:

kubectl get services 명령을 사용하여 지금 서비스 나열하기

kubectl get services

 

Note: It may take a few seconds before the ExternalIP field is populated for your service. This is normal -- just re-run the kubectl get services command every few seconds until the field populates.

 

 

5. Add the External IP to this command to hit the Nginx container remotely:

이 명령어<External IP> 대신에 실제 외부 IP를 추가하여 Nginx 컨테이너를 원격으로 적중시키기!

curl http://<External IP>:80

 

And there you go! Kubernetes supports an easy to use workflow out of the box using the kubectl run and expose commands.

 

kubectl 실행 및 노출 명령을 사용하면 즉시 사용할 수 있는 사용하기 쉬운 워크플로를 만들 수 있음

 

Now that you've seen a quick tour of kubernetes, it's time to dive into each of the components and abstractions.

Task 3. Pods

태스크3. pods

 

At the core of Kubernetes is the Pod.

Pods represent and hold a collection of one or more containers. Generally, if you have multiple containers with a hard dependency on each other, you package the containers inside a single pod.

 

포드는 하나 이상의 컨테이너 컬렉션을 나타내고 보유. 일반적으로 서로에 대한 종속성이 높은 여러 컨테이너가 있는 경우 컨테이너를 단일 포드 내에 패키징함.

In this example there is a pod that contains the monolith and nginx containers.

Pods also have Volumes. Volumes are data disks that live as long as the pods live, and can be used by the containers in that pod. Pods provide a shared namespace for their contents which means that the two containers inside of our example pod can communicate with each other, and they also share the attached volumes.

Pods also share a network namespace. This means that there is one IP Address per pod.

Next, a deeper dive into pods.

 

이 예에는 모노리스 및 nginx 컨테이너가 포함된 포드가 있음.

 

포드에는 볼륨도 있음. 볼륨은 포드가 살아있는 동안 지속되는 데이터 디스크이며 해당 포드의 컨테이너에서 사용할 수 있음. 포드는 콘텐츠에 대한 공유 네임스페이스를 제공. 즉, 예제 포드 내부의 두 컨테이너는 서로 통신할 수 있으며 연결된 볼륨도 공유할 수 있음.

 

Pod는 또한 네트워크 네임스페이스를 공유. 이는 포드당 하나의 IP 주소가 있음을 의미.

Task 4. Creating pods

태스크4. 포드 만들기

 

Pods can be created using pod configuration files. Take a moment to explore the monolith pod configuration file.

 

포드는 포드 구성 파일을 사용하여 생성할 수 있음. 아래는 모놀리스 포드 구성 파일

 

Run the following:

cat pods/monolith.yaml

The output shows the open configuration file:

apiVersion: v1
kind: Pod
metadata:
  name: monolith
  labels:
    app: monolith
spec:
  containers:
    - name: monolith
      image: kelseyhightower/monolith:1.0.0
      args:
        - "-http=0.0.0.0:80"
        - "-health=0.0.0.0:81"
        - "-secret=secret"
      ports:
        - name: http
          containerPort: 80
        - name: health
          containerPort: 81
      resources:
        limits:
          cpu: 0.2
          memory: "10Mi"

There's a few things to notice here. You'll see that:

• Your pod is made up of one container (the monolith).
• You're passing a few arguments to our container when it starts up.
• You're opening up port 80 for http traffic.

주의사항들 

- 포드는 하나의 컨테이너(모놀리스)로 구성됨

- 컨테이너가 시작될 때 몇 가지 인수를 컨테이너에 전달

- http 트래픽을 위해 포트 80을 여는 중

2. Create the monolith pod using kubectl:

kubectl을 사용하여 모놀리스 포드를 생성하기

kubectl create -f pods/monolith.yaml

 

3. Examine your pods. Use the kubectl get pods command to list all pods running in the default namespace:

포드를 검사하기. kubectl get pods 명령을 사용하여 기본 네임스페이스에서 실행 중인 모든 포드를 나열

kubectl get pods

Note: It may take a few seconds before the monolith pod is up and running. The monolith container image needs to be pulled from the Docker Hub before you can run it.

 

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

 

4. Once the pod is running, use kubectl describe command to get more information about the monolith pod:

 

포드가 실행되면 kubectl describe 명령을 사용하여 모노리스 포드에 대한 추가 정보를 얻기

kubectl describe pods monolith

You'll see a lot of the information about the monolith pod including the Pod IP address and the event log. This information will come in handy when troubleshooting.

Kubernetes makes it easy to create pods by describing them in configuration files and easy to view information about them when they are running. At this point you have the ability to create all the pods your deployment requires!

 

Pod IP 주소 및 이벤트 로그를 포함하여 모놀리스 Pod에 대한 많은 정보를 볼 수 있음. 이는 문제를 해결할 때 유용하므로 잘 써먹기!

 

Kubernetes를 사용하면 구성 파일에 설명하여 포드를 쉽게 생성하고 실행 중일 때 이에 대한 정보를 쉽게 볼 수 있음. 이 시점에서 배포에 필요한 모든 포드 생성 가능!

 

Task 5. Interacting with pods

태스크5. 포드와 상호작용하기 

 

By default, pods are allocated a private IP address and cannot be reached outside of the cluster. Use the kubectl port-forward command to map a local port to a port inside the monolith pod.

Note: From this point on the lab will ask you to work in multiple cloud shell tabs to set up communication between the pods. Any commands that are executed in a second or third command shell will be denoted in the command's instructions.

 

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

 

참고: 이 시점부터 실습에서는 여러 클라우드 셸 탭에서 작업하여 포드 간의 통신을 설정하도록 요청한다. 

 

1. Open a second Cloud Shell terminal. Now you have two terminals, one to run the kubectl port-forward command, and the other to issue curl commands.

 

두 번째 Cloud Shell 터미널을 연다. 하나는 kubectl port-forward 명령을 실행하고 다른 하나는 curl 명령을 실행한다.

 

2. In the 2nd terminal, run this command to set up port-forwarding:

 

두 번째 터미널에서 아래 명령어 사용해 포트 전달 설정하기

kubectl port-forward monolith 10080:80

3. Now in the 1st terminal start talking to your pod using curl:

첫번째 터미널에서 curl 이용해 포드와 대화 시작 

curl http://127.0.0.1:10080

Yes! You got a very friendly "hello" back from your container.

 

4. Now use the curl command to see what happens when you hit a secure endpoint:

 

curl 명령을 사용하여 보안 엔드포인트에 도달했을 때 어떤 일이 발생하는지 확인하기

curl http://127.0.0.1:10080/secure

Uh oh.

 

5. Try logging in to get an auth token back from the monolith:

 

로그인을 시도하여 모놀리스에서 인증 토큰을 다시 받기

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

6. At the login prompt, use the super-secret password "password" to login.

Logging in caused a JWT token to print out.

 

로그인해서 jwt 토큰 인쇄하기

 

7. Since Cloud Shell does not handle copying long strings well, create an environment variable for the token.

클라우드 쉘은 긴 문자열 복사를 잘 처리하지 못하므로 토큰에 대한 환경 변수 생성하기

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

8. Enter the super-secret password "password" again when prompted for the host password.

 

9. Use this command to copy and then use the token to hit the secure endpoint with curl:

아래 명령 사용하여 토큰을 사용해 curl 로 보안 엔드포인트에 도달하기

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

At this point you should get a response back from our application, letting us know everything is right in the world again.

애플리케이션에서 응답 받았어야 함.

 

10. Use the kubectl logs command to view the logs for the monolith Pod.

로그 사용해서 모놀리스 포드에 대한 로그 보기

kubectl logs monolith

11. Open a 3rd terminal and use the -f flag to get a stream of the logs happening in real-time:

세 번째 터미널 열고 -f 플래그 사용해 실시간으로 발생하는 로그 스트림 가져오기

kubectl logs -f monolith

12. Now if you use curl in the 1st terminal to interact with the monolith, you can see the logs updating (in the 3rd terminal):

이제 첫 번째 터미널에서 curl을 사용하여 모노리스와 상호 작용하면 로그가 업데이트되는 것을 볼 수 있음(세 번째 터미널에서).

curl http://127.0.0.1:10080

13. Use the kubectl exec command to run an interactive shell inside the Monolith Pod. This can come in handy when you want to troubleshoot from within a container:

 

kubectl exec 명령을 사용하여 Monolith Pod 내에서 대화형 셸을 실행. 이는 컨테이너 내에서 문제를 해결하려는 경우에 유용할 수 있음.

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

14. For example, once you have a shell into the monolith container you can test external connectivity using the ping command:

예를 들어 모놀리스 컨테이너에 셸이 있으면 ping 명령을 사용하여 외부 연결을 테스트할 수 있음

ping -c 3 google.com

15. Be sure to log out when you're done with this interactive shell.

이 대화형 셸이 끝나면 로그아웃해야 함.

exit

As you can see, interacting with pods is as easy as using the kubectl command. If you need to hit a container remotely, or get a login shell, Kubernetes provides everything you need to get up and going.

 

Pod와 상호 작용하는 것은 kubectl 명령을 사용하는 것만큼 쉽다. 원격으로 컨테이너에 접근해야 하거나 로그인 셸을 가져와야 하는 경우 Kubernetes는 시작하고 시작하는 데 필요한 모든 것을 제공한다.

Task 6. Services

Pods aren't meant to be persistent. They can be stopped or started for many reasons - like failed liveness or readiness checks - and this leads to a problem:

What happens if you want to communicate with a set of Pods? When they get restarted they might have a different IP address.

That's where Services come in. Services provide stable endpoints for Pods.

 

포드는 영구적이지 않다. 활성 상태 또는 준비 상태 확인 실패와 같은 여러 가지 이유로 중지되거나 시작될 수 있으며 이로 인해 문제가 발생하기도 한다.

 

Pod 집합과 통신하려는 경우-> 다시 시작할 때 다른 IP 주소를 가질 수 있음.

이때 서비스는 Pod에 안정적인 엔드포인트를 제공함.

Services use labels to determine what Pods they operate on. If Pods have the correct labels, they are automatically picked up and exposed by our services.

The level of access a service provides to a set of pods depends on the Service's type. Currently there are three types:

• ClusterIP (internal) -- the default type means that this Service is only visible inside of the cluster,
• NodePort gives each node in the cluster an externally accessible IP and
• LoadBalancer adds a load balancer from the cloud provider which forwards traffic from the service to Nodes within it.

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

 

서비스가 포드 세트에 제공하는 액세스 수준은 서비스 유형에 따라 다르다. 현재는 세 가지 유형이 있음.

 

ClusterIP(내부) -- 기본 유형은 이 서비스가 클러스터 내부에서만 볼 수 있음을 의미

NodePort는 클러스터의 각 노드에 외부에서 액세스할 수 있는 IP를 제공하고

LoadBalancer는 서비스에서 서비스 내의 노드로 트래픽을 전달하는 클라우드 공급자의 로드 밸런서를 추가.

 

Now you'll learn how to:

• Create a service
• Use label selectors to expose a limited set of Pods externally

서비스 만들기와

레이블 선택기를 사용하여 제한된 Pod 집합을 외부에 노출하기를 배워 보자!

Task 7. Creating a service

Before you can create our services, first create a secure pod that can handle https traffic.

 

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

 

1. If you've changed directories, make sure you return to the ~/orchestrate-with-kubernetes/kubernetes directory:

 

디렉토리 변경했다면 디렉토리로 돌아가기

cd ~/orchestrate-with-kubernetes/kubernetes

 

2. Explore the monolith service configuration file:

 

모놀리스 서비스 구성 파일을 탐색

cat pods/secure-monolith.yaml

 

3. Create the secure-monolith pods and their configuration data:

 

 보안 모노리스 포드 및 해당 구성 데이터를 생성

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

Now that you have a secure pod, it's time to expose the secure-monolith Pod externally.To do that, create a Kubernetes service.

 

이제 보안 포드가 있으므로 보안 모놀리스 포드를 외부에 노출해야 함. 이를 위해 Kubernetes 서비스 생성

 

4. Explore the monolith service configuration file:

 모놀리식 서비스 구성 파일을 탐색.

cat services/monolith.yaml

(Output):

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

Things to note:

• There's a selector which is used to automatically find and expose any pods with the labels app: monolith and secure: enabled.
• Now you have to expose the nodeport here because this is how you'll forward external traffic from port 31000 to nginx (on port 443).

참고 사항:

 

레이블 app: monolith 및 secure:가 활성화된 모든 포드를 자동으로 찾고 노출하는 데 사용되는 selector가 있음.

이제 포트 31000에서 nginx(포트 443에서)로 외부 트래픽을 전달하는 방법이므로 여기에서 노드 포트를 노출해야 함.

 

kubectl create -f services/monolith.yaml

5. Use the kubectl create command to create the monolith service from the monolith service configuration file:

 

kubectl create 명령을 사용하여 모노리스 서비스 구성 파일에서 모노리스 서비스를 생성

 

(Output):

service/monolith created

You're using a port to expose the service. This means that it's possible to have port collisions if another app tries to bind to port 31000 on one of your servers.

Normally, Kubernetes would handle this port assignment. In this lab you chose a port so that it's easier to configure health checks later on.

 

포트를 사용하여 서비스를 노출하고 있음. 즉, 다른 앱이 서버 중 하나의 포트 31000에 바인딩하려고 하면 포트 충돌이 발생할 수 있음.

 

일반적으로 Kubernetes는 이 포트 할당을 처리. 이 실습에서는 나중에 상태 확인을 더 쉽게 구성할 수 있도록 포트를 선택했음.

 

6. Use the gcloud compute firewall-rules command to allow traffic to the monolith service on the exposed nodeport:

 

. gcloud compute firewall-rules 명령어를 사용하여 노출된 노드 포트의 모놀리식 서비스에 대한 트래픽을 허용하기

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

 

Now that everything is set up you should be able to hit the secure-monolith service from outside the cluster without using port forwarding.

 

이제 모든 것이 설정되었으므로 포트 전달을 사용하지 않고 클러스터 외부에서 보안 모놀리스 서비스에 접속할 수 있음.

 

1. First, get an external IP address for one of the nodes.

1. 먼저 노드 중 하나에 대한 외부 IP 주소를 가져오기.

gcloud compute instances list

 

2. Now try hitting the secure-monolith service using curl:

 

curl을 사용하여 보안 모놀리스 서비스를 시도

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

Uh oh! That timed out. What's going wrong?

Note: It's time for a quick knowledge check.

Use the following commands to answer the questions below:

kubectl get services monolith

kubectl describe services monolith

Questions:

 

• Why are you unable to get a response from the monolith service?
• How many endpoints does the monolith service have?
• What labels must a Pod have to be picked up by the monolith service?

 

Hint: it has to do with labels. You'll fix the issue in the next section.

 

시간 초과 발생!

다음 명령어 사용해 확인하기 

kubectl get services monolith

kubectl describe services monolith

Task 8. Adding labels to pods

Currently the monolith service does not have endpoints. One way to troubleshoot an issue like this is to use the kubectl get pods command with a label query.

 

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

 

1. You can see that you have quite a few pods running with the monolith label.

모놀리스 레이블로 실행되는 포드가 꽤 있음을 알 수 있음.

kubectl get pods -l "app=monolith"

2. But what about "app=monolith" and "secure=enabled"?

 하지만 "app=monolith" 및 "secure=enabled"는?

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

Notice this label query does not print any results. It seems like you need to add the "secure=enabled" label to them.

 

이 레이블 쿼리는 결과를 인쇄하지 않음. "secure=enabled" 레이블을 추가.

 

3. Use the kubectl label command to add the missing secure=enabled label to the secure-monolith Pod. Afterwards, you can check and see that your labels have been updated.

kubectl label 명령을 사용하여 누락된 secure=enabled 레이블을 secure-monolith Pod에 추가. 그런 다음 레이블이 업데이트되었는지 확인할 수 있음.

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

4. Now that your pods are correctly labeled, view the list of endpoints on the monolith service:

 

 이제 포드에 올바르게 레이블이 지정되었으므로 모놀리스 서비스의 엔드포인트 목록을 확인!

kubectl describe services monolith | grep Endpoints

And you have one!

5. Test this out by hitting one of our nodes again.

노드 중 하나를 다시 눌러 이를 테스트

gcloud compute instances list
curl -k https://<EXTERNAL_IP>:31000

Bam! Houston, we have contact.

Task 9. Deploying applications with Kubernetes

태스크 9. 쿠버네티스로 애플리케이션 배포 

The goal of this lab is to get you ready for scaling and managing containers in production. That's where Deployments come in. Deployments are a declarative way to ensure that the number of Pods running is equal to the desired number of Pods, specified by the user.

 

이 실습의 목표는 프로덕션 환경에서 컨테이너를 확장하고 관리할 수 있도록 준비하는 것. 배포해야 함! 배포는 실행 중인 Pod 수가 사용자가 지정한 원하는 Pod 수와 동일하도록 하는 선언적 방법

 

The main benefit of Deployments is in abstracting away the low level details of managing Pods. Behind the scenes Deployments use Replica Sets to manage starting and stopping the Pods. If Pods need to be updated or scaled, the Deployment will handle that. Deployment also handles restarting Pods if they happen to go down for some reason.

Look at a quick example:

 

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

Pods are tied to the lifetime of the Node they are created on. In the example above, Node3 went down (taking a Pod with it). Instead of manually creating a new Pod and finding a Node for it, your Deployment created a new Pod and started it on Node2.

 

Pod는 생성된 노드의 수명과 연결됨. 위의 예에서 Node3이 다운되었음(Pod와 함께 사용). 새 포드를 수동으로 생성하고 이에 대한 노드를 찾는 대신 배포에서 새 포드를 생성하고 Node2에서 시작.

 

That's pretty cool!

It's time to combine everything you learned about Pods and Services to break up the monolith application into smaller Services using Deployments.

 

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

Task 10. Creating deployments

태스크 10. 배포 만들기 

You're going to break the monolith app into three separate pieces:

• auth - Generates JWT tokens for authenticated users.
• hello - Greet authenticated users.
• frontend - Routes traffic to the auth and hello services.

You are ready to create deployments, one for each service. Afterwards, you'll define internal services for the auth and hello deployments and an external service for the frontend deployment. Once finished you'll be able to interact with the microservices just like with Monolith only now each piece will be able to be scaled and deployed, independently!

 

모놀리스 앱을 세 개의 개별 조각으로 나누기.

 

auth - 인증된 사용자에 대한 JWT 토큰을 생성.

hello - 인증된 사용자를 환영.

프론트엔드 - auth 및 hello 서비스로 트래픽을 라우팅.

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

 

1. Get started by examining the auth deployment configuration file.

 

1. 인증 배포 구성 파일을 검사하여 시작.

cat deployments/auth.yaml

(Output)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: auth
spec:
  selector:
    matchlabels:
      app: auth
  replicas: 1
  template:
    metadata:
      labels:
        app: auth
        track: stable
    spec:
      containers:
        - name: auth
          image: "kelseyhightower/auth:2.0.0"
          ports:
            - name: http
              containerPort: 80
            - name: health
              containerPort: 81
...

The deployment is creating 1 replica, and you're using version 2.0.0 of the auth container.

When you run the kubectl create command to create the auth deployment it will make one pod that conforms to the data in the Deployment manifest. This means you can scale the number of Pods by changing the number specified in the Replicas field.

 

배포에서 1개의 복제본이 생성되고 인증 컨테이너 버전 2.0.0을 사용 중.

 

kubectl create 명령을 실행하여 인증 배포를 생성하면 배포 매니페스트의 데이터를 준수하는 하나의 포드가 생성됨. 즉, Replicas 필드에 지정된 수를 변경하여 Pod 수를 확장 가능.

 

2. Anyway, go ahead and create your deployment object:

계속해서 배포 개체를 만들기.

kubectl create -f deployments/auth.yaml

3. It's time to create a service for your auth deployment. Use the kubectl create command to create the auth service:

 

인증 배포를 위한 서비스 만들기. kubectl create 명령을 사용하여 인증 서비스를 생성

kubectl create -f services/auth.yaml

4. Now do the same thing to create and expose the hello deployment:

이제 동일한 작업을 수행하여 hello 배포를 만들고 노출

kubectl create -f deployments/hello.yaml
kubectl c

5. And one more time to create and expose the frontend Deployment.

그리고 한 번 더 프론트엔드 배포를 만들고 노출

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

Note: There is one more step to creating the frontend because you need to store some configuration data with the container.

 

참고: 컨테이너와 함께 일부 구성 데이터를 저장해야 하기 때문에 프런트엔드를 만드는 단계가 하나 더 있음.

 

6. Interact with the frontend by grabbing its External IP and then curling to it:

외부 IP를 가져온 다음 컬링하여 프런트엔드와 상호 작용.

kubectl get services frontend

Note: It might take a minute for the external IP address to be generated. Run the above command again if the EXTERNAL-IP column status is pending.

 

참고: EXTERNAL-IP 열 상태가 보류 중인 경우 위의 명령을 다시 실행하기

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

And you get a hello response back!