Update to Outdated files in dev-1.20-ko.5 branch (3)

This commit is contained in:
Yuk, Yongsu
2021-02-21 03:24:39 +09:00
committed by Yuk
parent fd8ee1d068
commit 2d78104965
26 changed files with 204 additions and 895 deletions
@@ -1,457 +0,0 @@
---
title: "예제: PHP / Redis 방명록 예제에 로깅과 메트릭 추가"
content_type: tutorial
weight: 21
card:
name: tutorials
weight: 31
title: "예제: PHP / Redis 방명록 예제에 로깅과 메트릭 추가"
---
<!-- overview -->
이 튜토리얼은 [Redis를 이용한 PHP 방명록](/ko/docs/tutorials/stateless-application/guestbook) 튜토리얼을 기반으로 한다. Elastic의 경량 로그, 메트릭, 네트워크 데이터 오픈소스 배송기인 *Beats* 를 방명록과 동일한 쿠버네티스 클러스터에 배포한다. Beats는 데이터를 수집하고 구문분석하여 Elasticsearch에 색인화하므로, Kibana에서 동작 정보를 결과로 보며 분석할 수 있다. 이 예시는 다음과 같이 구성되어 있다.
* [Redis를 이용한 PHP 방명록](/ko/docs/tutorials/stateless-application/guestbook)을 실행한 인스턴스
* Elasticsearch와 Kibana
* Filebeat
* Metricbeat
* Packetbeat
## {{% heading "objectives" %}}
* Redis를 이용한 PHP 방명록 시작.
* kube-state-metrics 설치.
* 쿠버네티스 시크릿 생성.
* Beats 배포.
* 로그와 메트릭의 대시보드 보기.
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}}
{{< version-check >}}
추가로 다음이 필요하다.
* 실행 중인 [Redis를 이용한 PHP 방명록](/ko/docs/tutorials/stateless-application/guestbook) 튜토리얼의 배포본.
* 실행 중인 Elasticsearch와 Kibana 디플로이먼트. [Elastic Cloud의 Elasticsearch 서비스](https://cloud.elastic.co)를 사용하거나,
[파일을 내려받아](https://www.elastic.co/guide/en/elastic-stack-get-started/current/get-started-elastic-stack.html)
워크스테이션이나 서버에서 운영하거나, [Elastic의 Helm 차트](https://github.com/elastic/helm-charts)를 이용한다.
<!-- lessoncontent -->
## Redis를 이용한 PHP 방명록 시작
이 튜토리얼은 [Redis를 이용한 PHP 방명록](/ko/docs/tutorials/stateless-application/guestbook)을 기반으로 한다. 방명록 애플리케이션을 실행 중이라면, 이를 모니터링할 수 있다. 실행되지 않은 경우라면 지침을 따라 방명록을 배포하고 **정리하기** 단계는 수행하지 말자. 방명록을 실행할 때 이 페이지로 돌아오자.
## 클러스터 롤 바인딩 추가
[클러스터 단위 롤 바인딩](/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding)을 생성하여, 클러스터 수준(kube-system 안에)으로 kube-state-metrics와 Beats를 배포할 수 있게 한다.
```shell
kubectl create clusterrolebinding cluster-admin-binding \
--clusterrole=cluster-admin --user=<your email associated with the k8s provider account>
```
## kube-state-metrics 설치
[*kube-state-metrics*](https://github.com/kubernetes/kube-state-metrics)는 쿠버네티스 API 서버를 모니터링하며 오브젝트 상태에 대한 메트릭을 생성하는 간단한 서비스이다. 이런 메트릭을 Metricbeat이 보고한다. 방명록이 실행된 쿠버네티스 클러스터에서 kube-state-metrics을 추가한다.
```shell
git clone https://github.com/kubernetes/kube-state-metrics.git kube-state-metrics
kubectl apply -f kube-state-metrics/examples/standard
```
### kube-state-metrics 실행 여부 확인
```shell
kubectl get pods --namespace=kube-system -l app.kubernetes.io/name=kube-state-metrics
```
출력
```
NAME READY STATUS RESTARTS AGE
kube-state-metrics-89d656bf8-vdthm 1/1 Running 0 21s
```
## Elastic의 예제를 GitHub 리포지터리에 클론한다.
```shell
git clone https://github.com/elastic/examples.git
```
나머지 커맨드는 `examples/beats-k8s-send-anywhere` 디렉터리의 파일을 참조할 것이라서, 그쪽으로 현재 디렉터리를 변경한다.
```shell
cd examples/beats-k8s-send-anywhere
```
## 쿠버네티스 시크릿 만들기
쿠버네티스 {{< glossary_tooltip text="시크릿" term_id="secret" >}}은 암호나 토큰, 키 같이 소량의 민감한 데이터를 포함하는 오브젝트이다. 이러한 정보는 다른 방식으로도 파드 스펙이나 이미지에 넣을 수 있을 것이다. 시크릿 오브젝트에 넣으면 이것이 어떻게 사용되는지 다양하게 제어할 수 있고, 우발적인 노출 사고의 위험이 줄일 수 있다.
{{< note >}}
여기에는 방식이 나뉘는데, 하나는 *자체 관리(Self managed)* 로 Elasticsearch와 Kibana(Elastic의 Helm 차트를 이용하여 사용자 서버를 구동하는)를 사용하는 경우이고 다른 경우는 Elastic Cloud의 Elasticsearch 서비스의 *관리 서비스(Managed service)* 를 사용하는 방식이다. 이 튜토리얼에서는 사용할 Elasticsearch와 Kibana 시스템의 종류에 따라 시크릿을 만들어야 한다.
{{< /note >}}
{{< tabs name="tab_with_md" >}}
{{% tab name="자체 관리(Self Managed)" %}}
### 자체 관리
Elastic Cloud의 Elasticsearch 서비스로 연결한다면 **관리 서비스** 탭으로 전환한다.
### 자격증명(credentials) 설정
자체 관리 Elasticsearch와 Kibana(자체 관리는 사실상 Elastic Cloud의 관리 서비스 Elasticsearch와 다르다) 서비스에 접속할 때에 4개 파일을 수정하여 쿠버네티스 시크릿을 생성한다. 파일은 다음과 같다.
1. `ELASTICSEARCH_HOSTS`
1. `ELASTICSEARCH_PASSWORD`
1. `ELASTICSEARCH_USERNAME`
1. `KIBANA_HOST`
이 정보를 Elasticsearch 클러스터와 Kibana 호스트에 지정한다. 여기 예시(또는 [*이 구성*](https://stackoverflow.com/questions/59892896/how-to-connect-from-minikube-to-elasticsearch-installed-on-host-local-developme/59892897#59892897)을 본다)가 있다.
#### `ELASTICSEARCH_HOSTS`
1. Elastic의 Elasticsearch Helm 차트에서 노드 그룹(nodeGroup).
```
["http://elasticsearch-master.default.svc.cluster.local:9200"]
```
1. Mac을 위한 Docker에서 Beats를 운영 중인 Mac에서 운영하는 단일 Elasticsearch 노드.
```
["http://host.docker.internal:9200"]
```
1. VM이나 물리 장비에서 운영 중인 두 개의 ELASTICSEARCH 노드.
```
["http://host1.example.com:9200", "http://host2.example.com:9200"]
```
`ELASTICSEARCH_HOSTS` 를 수정한다.
```shell
vi ELASTICSEARCH_HOSTS
```
#### `ELASTICSEARCH_PASSWORD`
화이트 스페이스나 인용 부호나 `<` 또는 `>` 도 없는 암호이다.
```
<사용자시크릿암호>
```
`ELASTICSEARCH_PASSWORD` 를 수정한다.
```shell
vi ELASTICSEARCH_PASSWORD
```
#### `ELASTICSEARCH_USERNAME`
화이트 스페이스나 인용 부호나 `<` 또는 `>` 도 없는 이름이다.
```
<Elasticsearch를 위한 수집 사용자 이름>
```
`ELASTICSEARCH_USERNAME` 을 수정한다.
```shell
vi ELASTICSEARCH_USERNAME
```
#### `KIBANA_HOST`
1.Elastic의 Kibana Helm 차트의 인스턴스이다. 하위 도메인 `default`는 기본 네임스페이스를 참조한다. 다른 네임스페이스를 사용하여 Helm 차트를 배포한 경우 하위 도메인이 다릅니다.
```
"kibana-kibana.default.svc.cluster.local:5601"
```
1. Mac 용 Docker에서 실행하는 Beats가 있는 Mac에서 실행하는 Kibana 인스턴스
```
"host.docker.internal:5601"
```
1. 가상머신이나 물리적 하드웨어에서 실행 중인 두 개의 Elasticsearch 노드
```
"host1.example.com:5601"
```
`KIBANA_HOST` 를 편집한다.
```shell
vi KIBANA_HOST
```
### 쿠버네티스 시크릿 만들기
이 커맨드는 방금 편집한 파일을 기반으로 쿠버네티스의 시스템 수준의 네임스페이스(`kube-system`)에 시크릿을 만든다.
```shell
kubectl create secret generic dynamic-logging \
--from-file=./ELASTICSEARCH_HOSTS \
--from-file=./ELASTICSEARCH_PASSWORD \
--from-file=./ELASTICSEARCH_USERNAME \
--from-file=./KIBANA_HOST \
--namespace=kube-system
```
{{% /tab %}}
{{% tab name="관리 서비스(Managed service)" %}}
## 관리 서비스
이 탭은 Elastic Cloud에서 Elasticsearch 서비스 만에 대한 것으로, 이미 자체 관리 Elasticsearch와 Kibana 배포로 시크릿을 생성했다면, [Beats 배포](#deploy-the-beats)를 계속한다.
### 자격증명(credentials) 설정
Elastic Cloud에서 관리되는 Elastic 서비스에 연결할 때, 쿠버네티스 시크릿을 생성하기 위해 편집할 두 파일이 있다. 파일은 다음과 같다.
1. `ELASTIC_CLOUD_AUTH`
1. `ELASTIC_CLOUD_ID`
디플로이먼트를 생성할 때에 Elasticsearch 콘솔에서 제공한 정보로 이를 설정한다. 여기 예시들이 있다.
#### `ELASTIC_CLOUD_ID`
```
devk8s:ABC123def456ghi789jkl123mno456pqr789stu123vwx456yza789bcd012efg345hijj678klm901nop345zEwOTJjMTc5YWQ0YzQ5OThlN2U5MjAwYTg4NTIzZQ==
```
#### `ELASTIC_CLOUD_AUTH`
사용자 이름, 콜론(`:`) 및 비밀번호인데, 공백 또는 따옴표는 없다.
```
elastic:VFxJJf9Tjwer90wnfTghsn8w
```
### 필요 파일 편집하기
```shell
vi ELASTIC_CLOUD_ID
vi ELASTIC_CLOUD_AUTH
```
### 쿠버네티스 시크릿 생성하기
이 커맨드는 방금 편집한 파일을 기반으로 쿠버네티스의 시스템 수준의 네임스페이스(`kube-system`)에 시크릿을 생성한다.
```shell
kubectl create secret generic dynamic-logging \
--from-file=./ELASTIC_CLOUD_ID \
--from-file=./ELASTIC_CLOUD_AUTH \
--namespace=kube-system
```
{{% /tab %}}
{{< /tabs >}}
## Beats 배포하기 {#deploy-the-beats}
각 Beat마다 메니페스트 파일을 제공한다. 이 메니페스트 파일은 앞서 생성한 시크릿을 사용하여, Elasticsearch 및 Kibana 서버에 연결하도록 Beats를 구성한다.
### Filebeat에 대해
Filebeat는 쿠버네티스 노드와 해당 노두에서 실행되는 각 파드에서 실행되는 컨테이너의 로그를 수집한다. Filebeat는 {{< glossary_tooltip text="데몬 셋" term_id="daemonset" >}}으로 배포한다. Filebeat는 쿠버네티스 클러스터에서 실행 중인 애플리케이션을 자동 검색할 수 있다. 시작시에 Filebeat는 기존 컨테이너를 검색하고 이에 적절한 구성을 시작하고 새 시작/종료 이벤트를 감시한다.
아래 내용은 Filebeat가 방명록 애플리케이션과 함께 배포된 Redis 컨테이너에서 Redis 로그를 찾아 구문분석할 수 있게 하는 자동 검색 구성이다. 이 구성은 `filebeat-kubernetes.yaml`파일에 있다.
```yaml
- condition.contains:
kubernetes.labels.app: redis
config:
- module: redis
log:
input:
type: docker
containers.ids:
- ${data.kubernetes.container.id}
slowlog:
enabled: true
var.hosts: ["${data.host}:${data.port}"]
```
이것은 `redis` 컨테이너가 `app` 문자열을 포함하는 레이블로 감지될 때에 Filebeat 모듈 `redis`를 적용하도록 Filebeat를 구성한다. Redis 모듈은 Docker 입력 유형을 사용하여 컨테이너에서 `로그` 스트림을 수집할 수 있다(이 Redis 컨테이너의 STDOUT 스트림과 연관된 쿠버네티스 노드에서 파일 읽기). 또한 이 모듈은 컨테이너 메타 데이터에 제공되는 적절한 파드 호스트와 포트에 연결하여 Redis의 `slowlog` 항목을 수집할 수 있다.
### Filebeat 배포
```shell
kubectl create -f filebeat-kubernetes.yaml
```
#### 확인
```shell
kubectl get pods -n kube-system -l k8s-app=filebeat-dynamic
```
### Metricbeat에 대해
Metricbeat 자동 검색은 Filebeat와 같은 방식으로 구성된다. 다음은 Redis 컨테이너에 대한 Metricbeat의 자동 검색 구성이다. 이 구성은 `metricbeat-kubernetes.yaml`에 있다.
```yaml
- condition.equals:
kubernetes.labels.tier: backend
config:
- module: redis
metricsets: ["info", "keyspace"]
period: 10s
# Redis hosts
hosts: ["${data.host}:${data.port}"]
```
이것은 컨테이너가 `tier` 레이블이 `backend` 문자열과 같은 레이블로 감지될 때에 Metricbeat 모듈 `redis`를 적용하도록 Metricbeat를 구성한다. `redis` 모듈은 컨테이너 메타데이터에 제공되는 적절한 파드 호스트와 포트에 연결하여 컨테이너에서 `info` 및 `keyspace` 메트릭을 수집할 수 있다.
### Metricbeat 배포
```shell
kubectl create -f metricbeat-kubernetes.yaml
```
#### 확인
```shell
kubectl get pods -n kube-system -l k8s-app=metricbeat
```
### Packetbeat에 대해
Packetbeat 구성은 Filebeat와 Metricbeat와는 다르다. 컨테이너 레이블과 일치시킬 패턴을 지정하지 않고, 구성은 관련 프로토콜 및 포트 번호를 기반으로 한다. 아래는 포트 번호의 하위 집합이다.
{{< note >}}
비표준 포트로 서비스를 실행했다면 해당 포트를 `filebeat.yaml`에 적절한 유형에 추가하고, Packetbeat 데몬 셋을 삭제하고 생성한다.
{{< /note >}}
```yaml
packetbeat.interfaces.device: any
packetbeat.protocols:
- type: dns
ports: [53]
include_authorities: true
include_additionals: true
- type: http
ports: [80, 8000, 8080, 9200]
- type: mysql
ports: [3306]
- type: redis
ports: [6379]
packetbeat.flows:
timeout: 30s
period: 10s
```
#### Packetbeat 배포하기
```shell
kubectl create -f packetbeat-kubernetes.yaml
```
#### 확인하기
```shell
kubectl get pods -n kube-system -l k8s-app=packetbeat-dynamic
```
## Kibana에서 보기
브라우저에서 Kibana를 열고, **대시보드** 애플리케이션을 열어보자. 검색창에 kubernetes를 입력하고 쿠버네티스를 위한 Metricbeat 대시보드를 클릭한다. 이 대시보드에는 노드 상태, 배포 등의 보고 내용이 있다.
대시보드 페이지에 Packetbeat를 검색하고 Packetbeat의 개요 페이지를 살펴보자.
마찬가지로 Apache와 Redis를 위한 대시보드를 확인한다. 각 로그와 메트릭에 대한 대시보드가 표시된다. 이 Apache Metricbeat 대시보드는 비어 있다. Apache Filebeat 대시보드를 보고, 맨 아래로 스크롤하여 Apache 오류 로그를 확인한다. Apache에서 보여줄 메트릭이 없는 이유를 알려줄 것이다.
Metricbeat에서 Apache 메트릭을 가져올 수 있게 하려면, mod-status 구성 파일을 포함한 컨피그맵을 추가하고 방명록을 재배포하여 서버 상태를 활성화해야 한다.
## 디플로이먼트를 확장하고 모니터링중인 새 파드를 확인하기
기존 디플로이먼트를 확인한다.
```shell
kubectl get deployments
```
출력
```
NAME READY UP-TO-DATE AVAILABLE AGE
frontend 3/3 3 3 3h27m
redis-master 1/1 1 1 3h27m
redis-slave 2/2 2 2 3h27m
```
front의 디플로이먼트를 두 개의 파드로 축소한다.
```shell
kubectl scale --replicas=2 deployment/frontend
```
출력
```
deployment.extensions/frontend scaled
```
frontend의 파드를 최대 3개의 파드로 확장한다.
```shell
kubectl scale --replicas=3 deployment/frontend
```
## Kibana에서 변화 확인하기
스크린 캡처를 확인하여, 표시된 필터를 추가하고 해당 열을 뷰에 추가한다. ScalingReplicaSet 항목이 표시되고, 여기에서 이벤트 목록의 맨 위에 풀링되는 이미지, 마운트된 볼륨, 파드 시작 등을 보여준다.
![Kibana 디스커버리](https://raw.githubusercontent.com/elastic/examples/master/beats-k8s-send-anywhere/scaling-up.png)
## {{% heading "cleanup" %}}
디플로이먼트와 서비스를 삭제하면 실행중인 파드도 삭제된다. 한 커맨드로 여러 개의 리소스를 삭제하기 위해 레이블을 이용한다.
1. 다음 커맨드를 실행하여 모든 파드, 디플로이먼트, 서비스를 삭제한다.
```shell
kubectl delete deployment -l app=redis
kubectl delete service -l app=redis
kubectl delete deployment -l app=guestbook
kubectl delete service -l app=guestbook
kubectl delete -f filebeat-kubernetes.yaml
kubectl delete -f metricbeat-kubernetes.yaml
kubectl delete -f packetbeat-kubernetes.yaml
kubectl delete secret dynamic-logging -n kube-system
```
1. 실행 중인 파드가 없음을 확인하기 위해 파드 목록을 조회한다.
```shell
kubectl get pods
```
출력은 다음과 같아야 한다.
```
No resources found.
```
## {{% heading "whatsnext" %}}
* [리소스 모니터링 도구](/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring/)를 공부한다.
* [로깅 아키텍처](/ko/docs/concepts/cluster-administration/logging/)를 더 읽어본다.
* [애플리케이션 검사 및 디버깅](/ko/docs/tasks/debug-application-cluster/)을 더 읽어본다.
* [애플리케이션 문제 해결](/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring/)을 더 읽어본다.
@@ -1,26 +1,25 @@
---
title: "예시: Redis를 사용한 PHP 방명록 애플리케이션 배포하기"
title: "예시: MongoDB를 사용한 PHP 방명록 애플리케이션 배포하기"
content_type: tutorial
weight: 20
card:
name: tutorials
weight: 30
title: "상태를 유지하지 않는 예제: Redis를 사용한 PHP 방명록"
title: "상태를 유지하지 않는 예제: MongoDB를 사용한 PHP 방명록"
min-kubernetes-server-version: v1.14
---
<!-- overview -->
이 튜토리얼에서는 쿠버네티스와 [Docker](https://www.docker.com/)를 사용하여 간단한 멀티 티어 웹 애플리케이션을 빌드하고 배포하는 방법을 보여준다. 이 예제는 다음과 같은 구성으로 이루어져 있다.
이 튜토리얼에서는 쿠버네티스와 [Docker](https://www.docker.com/)를 사용하여 간단한 _(운영 준비가 아닌)_ 멀티 티어 웹 애플리케이션을 빌드하고 배포하는 방법을 보여준다. 이 예제는 다음과 같은 구성으로 이루어져 있다.
* 방명록을 저장하는 단일 인스턴스 [Redis](https://redis.io/) 마스터
* 읽기를 제공하는 여러 개의 [복제된 Redis](https://redis.io/topics/replication) 인스턴스
* 방명록을 저장하는 단일 인스턴스 [MongoDB](https://www.mongodb.com/)
* 여러 개의 웹 프론트엔드 인스턴스
## {{% heading "objectives" %}}
* Redis 마스터를 시작
* Redis 슬레이브를 시작
* Mongo 데이터베이스를 시작
* 방명록 프론트엔드를 시작
* 프론트엔드 서비스를 노출하고 확인
* 정리 하기
@@ -37,24 +36,28 @@ card:
<!-- lessoncontent -->
## Redis 마스터를 실행하기
## Mongo 데이터베이스를 실행
방명록 애플리케이션은 Redis를 사용하여 데이터를 저장한다. Redis 마스터 인스턴스에 데이터를 기록하고 여러 Redis 슬레이브 인스턴스에서 데이터를 읽는다.
방명록 애플리케이션은 MongoDB를 사용해서 데이터를 저장한다.
### Redis 마스터의 디플로이먼트를 생성하기
### Mongo 디플로이먼트를 생성하기
아래의 매니페스트 파일은 단일 복제본 Redis 마스터 파드를 실행하는 디플로이먼트 컨트롤러를 지정한다.
아래의 매니페스트 파일은 단일 복제본 Mongo 파드를 실행하는 디플로이먼트 컨트롤러를 지정한다.
{{< codenew file="application/guestbook/redis-master-deployment.yaml" >}}
{{< codenew file="application/guestbook/mongo-deployment.yaml" >}}
1. 매니페스트 파일을 다운로드한 디렉터리에서 터미널 창을 시작한다.
1. `redis-master-deployment.yaml` 파일을 통해 Redis 마스터의 디플로이먼트에 적용한다.
1. `mongo-deployment.yaml` 파일을 통해 MongoDB 디플로이먼트에 적용한다.
```shell
kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-deployment.yaml
kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-deployment.yaml
```
<!--
컨텐츠에 대한 로컬 테스트는 파일의 상대경로로 한다.
kubectl apply -f ./content/en/examples/application/guestbook/mongo-deployment.yaml
-->
1. 파드의 목록을 질의하여 Redis 마스터 파드가 실행 중인지 확인한다.
1. 파드의 목록을 질의하여 MongoDB 파드가 실행 중인지 확인한다.
```shell
kubectl get pods
@@ -64,32 +67,32 @@ card:
```shell
NAME READY STATUS RESTARTS AGE
redis-master-1068406935-3lswp 1/1 Running 0 28s
mongo-5cfd459dd4-lrcjb 1/1 Running 0 28s
```
1. Redis 마스터 파드에서 로그를 보려면 다음 명령어를 실행한다.
2. MongoDB 파드에서 로그를 보려면 다음 명령어를 실행한다.
```shell
kubectl logs -f POD-NAME
kubectl logs -f deployment/mongo
```
{{< note >}}
POD-NAME을 해당 파드 이름으로 수정해야 한다.
{{< /note >}}
### MongoDB 서비스 생성하기
### Redis 마스터 서비스 생성하기
방명록 애플리케이션에서 데이터를 쓰려면 MongoDB와 통신해야 한다. MongoDB 파드로 트래픽을 프록시하려면 [서비스](/ko/docs/concepts/services-networking/service/)를 적용해야 한다. 서비스는 파드에 접근하기 위한 정책을 정의한다.
방명록 애플리케이션에서 데이터를 쓰려면 Redis 마스터와 통신해야 한다. Redis 마스터 파드로 트래픽을 프록시하려면 [서비스](/ko/docs/concepts/services-networking/service/)를 적용해야 한다. 서비스는 파드에 접근하기 위한 정책을 정의한다.
{{< codenew file="application/guestbook/mongo-service.yaml" >}}
{{< codenew file="application/guestbook/redis-master-service.yaml" >}}
1. `redis-master-service.yaml` 파일을 통해 Redis 마스터 서비스에 적용한다.
1. `mongo-service.yaml` 파일을 통해 MongoDB 서비스에 적용한다.
```shell
kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-service.yaml
kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-service.yaml
```
<!--
컨텐츠에 대한 로컬 테스트는 파일의 상대경로로 한다.
kubectl apply -f ./content/en/examples/application/guestbook/mongo-service.yaml
-->
1. 서비스의 목록을 질의하여 Redis 마스터 서비스가 실행 중인지 확인한다.
1. 서비스의 목록을 질의하여 MongoDB 서비스가 실행 중인지 확인한다.
```shell
kubectl get service
@@ -100,77 +103,17 @@ POD-NAME을 해당 파드 이름으로 수정해야 한다.
```shell
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 1m
redis-master ClusterIP 10.0.0.151 <none> 6379/TCP 8s
mongo ClusterIP 10.0.0.151 <none> 6379/TCP 8s
```
{{< note >}}
이 매니페스트 파일은 이전에 정의된 레이블과 일치하는 레이블 집합을 가진 `redis-master`라는 서비스를 생성하므로, 서비스는 네트워크 트래픽을 Redis 마스터 파드로 라우팅한다.
이 매니페스트 파일은 이전에 정의된 레이블과 일치하는 레이블 집합을 가진 `mongo`라는 서비스를 생성하므로, 서비스는 네트워크 트래픽을 MongoDB 파드로 라우팅한다.
{{< /note >}}
## Redis 슬레이브 실행하기
Redis 마스터는 단일 파드이지만, 복제된 Redis 슬레이브를 추가하여 트래픽 요구 사항을 충족시킬 수 있다.
### Redis 슬레이브의 디플로이먼트 생성하기
디플로이먼트는 매니페스트 파일에 설정된 구성에 따라 확장된다. 이 경우, 디플로이먼트 오브젝트는 두 개의 복제본을 지정한다.
실행 중인 복제본이 없으면, 이 디플로이먼트는 컨테이너 클러스터에 있는 두 개의 복제본을 시작한다. 반대로 두 개 이상의 복제본이 실행 중이면, 두 개의 복제본이 실행될 때까지 축소된다.
{{< codenew file="application/guestbook/redis-slave-deployment.yaml" >}}
1. `redis-slave-deployment.yaml` 파일을 통해 Redis 슬레이브의 디플로이먼트에 적용한다.
```shell
kubectl apply -f https://k8s.io/examples/application/guestbook/redis-slave-deployment.yaml
```
1. 파드의 목록을 질의하여 Redis 슬레이브 파드가 실행 중인지 확인한다.
```shell
kubectl get pods
```
결과는 아래와 같은 형태로 나타난다.
```shell
NAME READY STATUS RESTARTS AGE
redis-master-1068406935-3lswp 1/1 Running 0 1m
redis-slave-2005841000-fpvqc 0/1 ContainerCreating 0 6s
redis-slave-2005841000-phfv9 0/1 ContainerCreating 0 6s
```
### Redis 슬레이브 서비스 생성하기
방명록 애플리케이션은 Redis 슬레이브와 통신하여 데이터를 읽는다. Redis 슬레이브를 확인할 수 있도록 하기 위해 서비스를 설정해야 한다. 서비스는 파드 집합에 투명한 로드 밸런싱을 제공한다.
{{< codenew file="application/guestbook/redis-slave-service.yaml" >}}
1. `redis-slave-service.yaml` 파일을 통해 Redis 슬레이브 서비스에 적용한다.
```shell
kubectl apply -f https://k8s.io/examples/application/guestbook/redis-slave-service.yaml
```
1. 서비스의 목록을 질의하여 Redis 슬레이브 서비스가 실행 중인지 확인한다.
```shell
kubectl get services
```
결과는 아래와 같은 형태로 나타난다.
```
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 2m
redis-master ClusterIP 10.0.0.151 <none> 6379/TCP 1m
redis-slave ClusterIP 10.0.0.223 <none> 6379/TCP 6s
```
## 방명록 프론트엔드를 설정하고 노출하기
방명록 애플리케이션에는 PHP로 작성된 HTTP 요청을 처리하는 웹 프론트엔드가 있다. 쓰기 요청을 위한 `redis-master` 서비스와 읽기 요청을 `redis-slave` 서비스에 연결하도록 설정된다.
방명록 애플리케이션에는 PHP로 작성된 HTTP 요청을 처리하는 웹 프론트엔드가 있다. 방명록 항목들을 저장하기 `mongo` 서비스에 연결하도록 구성 한다.
### 방명록 프론트엔드의 디플로이먼트 생성하기
@@ -182,6 +125,11 @@ Redis 마스터는 단일 파드이지만, 복제된 Redis 슬레이브를 추
kubectl apply -f https://k8s.io/examples/application/guestbook/frontend-deployment.yaml
```
<!--
컨텐츠에 대한 로컬 테스트는 파일의 상대경로로 한다.
kubectl apply -f ./content/en/examples/application/guestbook/frontend-deployment.yaml
-->
1. 파드의 목록을 질의하여 세 개의 프론트엔드 복제본이 실행되고 있는지 확인한다.
```shell
@@ -199,12 +147,12 @@ Redis 마스터는 단일 파드이지만, 복제된 Redis 슬레이브를 추
### 프론트엔드 서비스 생성하기
서비스의 기본 유형은 [ClusterIP](/ko/docs/concepts/services-networking/service/#publishing-services-service-types)이기 때문에 적용한 redis-slave 및 redis-master 서비스는 컨테이너 클러스터 내에서만 접근할 수 있다. `ClusterIP`는 서비스가 가리키는 파드 집합에 대한 단일 IP 주소를 제공한다. 이 IP 주소는 클러스터 내에서만 접근할 수 있다.
서비스의 기본 유형은 [ClusterIP](/ko/docs/concepts/services-networking/service/#publishing-services-service-types)이기 때문에 적용한 `mongo` 서비스는 컨테이너 클러스터 내에서만 접근할 수 있다. `ClusterIP`는 서비스가 가리키는 파드 집합에 대한 단일 IP 주소를 제공한다. 이 IP 주소는 클러스터 내에서만 접근할 수 있다.
게스트가 방명록에 접근할 수 있도록 하려면, 외부에서 볼 수 있도록 프론트엔드 서비스를 구성해야 한다. 그렇게 하면 클라이언트가 컨테이너 클러스터 외부에서 서비스를 요청할 수 있다. Minikube는 `NodePort`를 해서 서비스를 노출할 수 있다.
게스트가 방명록에 접근할 수 있도록 하려면, 외부에서 볼 수 있도록 프론트엔드 서비스를 구성해야 한다. 그렇게 하면 클라이언트가 쿠버네티스 클러스터 외부에서 서비스를 요청할 수 있다. 그러나 쿠버네티스 사용자는 `ClusterIP`를 사용하더라도 `kubectl port-forward`를 사용해서 서비스에 접근할 수 있다.
{{< note >}}
Google Compute Engine 또는 Google Kubernetes Engine과 같은 일부 클라우드 공급자는 외부 로드 밸런서를 지원한다. 클라우드 공급자가 로드 밸런서를 지원하고 이를 사용하려면 `type : NodePort`를 삭제하거나 주석 처리하고 `type : LoadBalancer`의 주석을 제거해야 한다.
Google Compute Engine 또는 Google Kubernetes Engine과 같은 일부 클라우드 공급자는 외부 로드 밸런서를 지원한다. 클라우드 공급자가 로드 밸런서를 지원하고 이를 사용하려면 `type : LoadBalancer`의 주석을 제거해야 한다.
{{< /note >}}
{{< codenew file="application/guestbook/frontend-service.yaml" >}}
@@ -215,6 +163,11 @@ Google Compute Engine 또는 Google Kubernetes Engine과 같은 일부 클라우
kubectl apply -f https://k8s.io/examples/application/guestbook/frontend-service.yaml
```
<!--
컨텐츠에 대한 로컬 테스트는 파일의 상대경로로 한다.
kubectl apply -f ./content/en/examples/application/guestbook/frontend-service.yaml
-->
1. 서비스의 목록을 질의하여 프론트엔드 서비스가 실행 중인지 확인한다.
```shell
@@ -225,29 +178,27 @@ Google Compute Engine 또는 Google Kubernetes Engine과 같은 일부 클라우
```
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
frontend NodePort 10.0.0.112 <none> 80:31323/TCP 6s
frontend ClusterIP 10.0.0.112 <none> 80/TCP 6s
kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 4m
redis-master ClusterIP 10.0.0.151 <none> 6379/TCP 2m
redis-slave ClusterIP 10.0.0.223 <none> 6379/TCP 1m
mongo ClusterIP 10.0.0.151 <none> 6379/TCP 2m
```
### `NodePort`를 통해 프론트엔드 서비스 확인하기
### `kubectl port-forward`를 통해 프론트엔드 서비스 확인하기
애플리케이션을 Minikube 또는 로컬 클러스터에 배포한 경우, 방명록을 보려면 IP 주소를 찾아야 한다.
1. 프론트엔드 서비스의 IP 주소를 얻기 위해 아래 명령어를 실행한다.
1. 다음 명령어를 실행해서 로컬 머신의 `8080` 포트를 서비스의 `80` 포트로 전달한다.
```shell
minikube service frontend --url
kubectl port-forward svc/frontend 8080:80
```
결과는 아래와 같은 형태로 나타난다.
```
http://192.168.99.100:31323
Forwarding from 127.0.0.1:8080 -> 80
Forwarding from [::1]:8080 -> 80
```
1. IP 주소를 복사하고, 방명록을 보기 위해 브라우저에서 페이지를 로드한다.
1. 방명록을 보기위해 브라우저에서 [http://localhost:8080](http://localhost:8080) 페이지를 로드한다.
### `LoadBalancer`를 통해 프론트엔드 서비스 확인하기
@@ -270,7 +221,7 @@ Google Compute Engine 또는 Google Kubernetes Engine과 같은 일부 클라우
## 웹 프론트엔드 확장하기
서버가 디플로이먼트 컨롤러를 사용하는 서비스로 정의되어 있기 때문에 확장 또는 축소가 쉽다.
서버가 디플로이먼트 컨롤러를 사용하는 서비스로 정의되어 있기에 필요에 따라 확장 또는 축소할 수 있다.
1. 프론트엔드 파드의 수를 확장하기 위해 아래 명령어를 실행한다.
@@ -293,9 +244,7 @@ Google Compute Engine 또는 Google Kubernetes Engine과 같은 일부 클라우
frontend-3823415956-k22zn 1/1 Running 0 54m
frontend-3823415956-w9gbt 1/1 Running 0 54m
frontend-3823415956-x2pld 1/1 Running 0 5s
redis-master-1068406935-3lswp 1/1 Running 0 56m
redis-slave-2005841000-fpvqc 1/1 Running 0 55m
redis-slave-2005841000-phfv9 1/1 Running 0 55m
mongo-1068406935-3lswp 1/1 Running 0 56m
```
1. 프론트엔드 파드의 수를 축소하기 위해 아래 명령어를 실행한다.
@@ -316,9 +265,7 @@ Google Compute Engine 또는 Google Kubernetes Engine과 같은 일부 클라우
NAME READY STATUS RESTARTS AGE
frontend-3823415956-k22zn 1/1 Running 0 1h
frontend-3823415956-w9gbt 1/1 Running 0 1h
redis-master-1068406935-3lswp 1/1 Running 0 1h
redis-slave-2005841000-fpvqc 1/1 Running 0 1h
redis-slave-2005841000-phfv9 1/1 Running 0 1h
mongo-1068406935-3lswp 1/1 Running 0 1h
```
@@ -330,19 +277,18 @@ Google Compute Engine 또는 Google Kubernetes Engine과 같은 일부 클라우
1. 모든 파드, 디플로이먼트, 서비스를 삭제하기 위해 아래 명령어를 실행한다.
```shell
kubectl delete deployment -l app=redis
kubectl delete service -l app=redis
kubectl delete deployment -l app=guestbook
kubectl delete service -l app=guestbook
kubectl delete deployment -l app.kubernetes.io/name=mongo
kubectl delete service -l app.kubernetes.io/name=mongo
kubectl delete deployment -l app.kubernetes.io/name=guestbook
kubectl delete service -l app.kubernetes.io/name=guestbook
```
결과는 아래와 같은 형태로 나타난다.
```
deployment.apps "redis-master" deleted
deployment.apps "redis-slave" deleted
service "redis-master" deleted
service "redis-slave" deleted
deployment.apps "mongo" deleted
service "mongo" deleted
deployment.apps "frontend" deleted
deployment.apps "frontend" deleted
service "frontend" deleted
```
@@ -363,7 +309,6 @@ Google Compute Engine 또는 Google Kubernetes Engine과 같은 일부 클라우
## {{% heading "whatsnext" %}}
* [ELK 로깅과 모니터링](/ko/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk/)을 방명록 애플리케이션에 추가하기
* [쿠버네티스 기초](/ko/docs/tutorials/kubernetes-basics/) 튜토리얼을 완료
* [MySQL과 Wordpress을 위한 퍼시스턴트 볼륨](/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/#visit-your-new-wordpress-blog)을 사용하여 블로그 생성하는데 쿠버네티스 이용하기
* [애플리케이션 접속](/ko/docs/concepts/services-networking/connect-applications-service/)에 대해 더 알아보기