Merge pull request #22772 from kubernetes/dev-1.17-ja.3
Third Japanese l10n work for release-1.17
This commit is contained in:
Kubernetes Prow Robot
@@ -39,7 +39,7 @@ card:
|
||||
|
||||
<div class="row">
|
||||
<div class="col-md-9">
|
||||
<h2>Kubernetesはどんなことができるの?</h2>
|
||||
<h2>Kubernetesはどんなことができるの？</h2>
|
||||
<p>モダンなWebサービスでは、ユーザはアプリケーションが24時間365日利用可能であることを期待しており、開発者はそれらのアプリケーションの新しいバージョンを1日に数回デプロイすることを期待しています。コンテナ化は、パッケージソフトウェアがこれらの目標を達成するのを助け、アプリケーションをダウンタイムなしで簡単かつ迅速にリリース、アップデートできるようにします。Kubernetesを使用すると、コンテナ化されたアプリケーションをいつでもどこでも好きなときに実行できるようになり、それらが機能するために必要なリソースとツールを見つけやすくなります。Kubernetesは、コンテナオーケストレーションにおけるGoogleのこれまでの経験と、コミュニティから得られた最善のアイデアを組み合わせて設計された、プロダクションレディなオープンソースプラットフォームです。</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
@@ -20,7 +20,7 @@ weight: 20
|
||||
<div class="row">
|
||||
<div class="col-md-12">
|
||||
<p>
|
||||
Podは、Kubernetesアプリケーションの基本的な実行単位です。各Podは、クラスターで実行されているワークロードの一部を表します。<a href="/ja/docs/concepts/workloads/pods/pod-overview/#understanding-pods">Podの詳細はこちらです。</a>。
|
||||
Podは、Kubernetesアプリケーションの基本的な実行単位です。各Podは、クラスターで実行されているワークロードの一部を表します。<a href="/ja/docs/concepts/workloads/pods/pod-overview/#understanding-pods">Podの詳細はこちらです</a>。
|
||||
</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
Executable
+5
@@ -0,0 +1,5 @@
|
||||
---
|
||||
title: "Service"
|
||||
weight: 70
|
||||
---
|
||||
|
||||
@@ -0,0 +1,421 @@
|
||||
---
|
||||
title: 送信元IPを使用する
|
||||
content_type: tutorial
|
||||
min-kubernetes-server-version: v1.5
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
Kubernetesクラスター内で実行されているアプリケーションは、Serviceという抽象化を経由して、他のアプリケーションや外の世界との発見や通信を行います。このドキュメントでは、異なる種類のServiceに送られたパケットの送信元IPに何が起こるのか、そして必要に応じてこの振る舞いを切り替える方法について説明します。
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
### 用語
|
||||
|
||||
このドキュメントでは、以下の用語を使用します。
|
||||
|
||||
{{< comment >}}
|
||||
If localizing this section, link to the equivalent Wikipedia pages for
|
||||
the target localization.
|
||||
{{< /comment >}}
|
||||
|
||||
[NAT](https://ja.wikipedia.org/wiki/%E3%83%8D%E3%83%83%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF%E3%82%A2%E3%83%89%E3%83%AC%E3%82%B9%E5%A4%89%E6%8F%9B)
|
||||
: ネットワークアドレス変換(network address translation)
|
||||
|
||||
[送信元NAT](https://en.wikipedia.org/wiki/Network_address_translation#SNAT)
|
||||
: パケットの送信元のIPを置換します。このページでは、通常ノードのIPアドレスを置換することを意味します。
|
||||
|
||||
[送信先NAT](https://en.wikipedia.org/wiki/Network_address_translation#DNAT)
|
||||
: パケットの送信先のIPを置換します。このページでは、通常{{< glossary_tooltip term_id="pod" >}}のIPアドレスを置換することを意味します。
|
||||
|
||||
[VIP](/ja/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies)
|
||||
: Kubernetes内のすべての{{< glossary_tooltip text="Service" term_id="service" >}}などに割り当てられる仮想IPアドレス(virtual IP address)です。
|
||||
|
||||
[kube-proxy](/ja/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies)
|
||||
: すべてのノード上でServiceのVIPを管理するネットワークデーモンです。
|
||||
|
||||
### 前提条件
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
以下の例では、HTTPヘッダー経由で受け取ったリクエストの送信元IPをエコーバックする、小さなnginxウェブサーバーを使用します。次のコマンドでウェブサーバーを作成できます。
|
||||
|
||||
```shell
|
||||
kubectl create deployment source-ip-app --image=k8s.gcr.io/echoserver:1.4
|
||||
```
|
||||
|
||||
出力は次のようになります。
|
||||
|
||||
```
|
||||
deployment.apps/source-ip-app created
|
||||
```
|
||||
|
||||
## {{% heading "objectives" %}}
|
||||
|
||||
* 単純なアプリケーションを様々な種類のService経由で公開する
|
||||
* それぞれの種類のServiceがどのように送信元IPのNATを扱うかを理解する
|
||||
* 送信元IPを保持することに関わるトレードオフを理解する
|
||||
|
||||
<!-- lessoncontent -->
|
||||
|
||||
## `Type=ClusterIP`を使用したServiceでの送信元IP
|
||||
|
||||
kube-proxyが[iptablesモード](/ja/docs/concepts/services-networking/service/#proxy-mode-iptables)(デフォルト)で実行されている場合、クラスター内部からClusterIPに送られたパケットに送信元のNATが行われることは決してありません。kube-proxyが実行されているノード上で`http://localhost:10249/proxyMode`にリクエストを送って、kube-proxyのモードを問い合わせてみましょう。
|
||||
|
||||
```console
|
||||
kubectl get nodes
|
||||
```
|
||||
|
||||
出力は次のようになります。
|
||||
|
||||
```
|
||||
NAME STATUS ROLES AGE VERSION
|
||||
kubernetes-node-6jst Ready <none> 2h v1.13.0
|
||||
kubernetes-node-cx31 Ready <none> 2h v1.13.0
|
||||
kubernetes-node-jj1t Ready <none> 2h v1.13.0
|
||||
```
|
||||
|
||||
これらのノードの1つでproxyモードを取得します(kube-proxyはポート10249をlistenしています)。
|
||||
|
||||
```shell
|
||||
# このコマンドは、問い合わせを行いたいノード上のシェルで実行してください。
|
||||
curl http://localhost:10249/proxyMode
|
||||
```
|
||||
|
||||
出力は次のようになります。
|
||||
|
||||
```
|
||||
iptables
|
||||
```
|
||||
|
||||
source IPアプリのServiceを作成することで、送信元IPが保持されているかテストできます。
|
||||
|
||||
```shell
|
||||
kubectl expose deployment source-ip-app --name=clusterip --port=80 --target-port=8080
|
||||
```
|
||||
|
||||
出力は次のようになります。
|
||||
|
||||
```
|
||||
service/clusterip exposed
|
||||
```
|
||||
```shell
|
||||
kubectl get svc clusterip
|
||||
```
|
||||
|
||||
出力は次のようになります。
|
||||
|
||||
```
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
clusterip ClusterIP 10.0.170.92 <none> 80/TCP 51s
|
||||
```
|
||||
|
||||
そして、同じクラスター上のPodから`ClusterIP`にアクセスします。
|
||||
|
||||
```shell
|
||||
kubectl run busybox -it --image=busybox --restart=Never --rm
|
||||
```
|
||||
|
||||
出力は次のようになります。
|
||||
|
||||
```
|
||||
Waiting for pod default/busybox to be running, status is Pending, pod ready: false
|
||||
If you don't see a command prompt, try pressing enter.
|
||||
|
||||
```
|
||||
|
||||
これで、Podの内部でコマンドが実行できます。
|
||||
|
||||
```shell
|
||||
# このコマンドは、"kubectl run" のターミナルの内部で実行してください
|
||||
ip addr
|
||||
```
|
||||
```
|
||||
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue
|
||||
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
|
||||
inet 127.0.0.1/8 scope host lo
|
||||
valid_lft forever preferred_lft forever
|
||||
inet6 ::1/128 scope host
|
||||
valid_lft forever preferred_lft forever
|
||||
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1460 qdisc noqueue
|
||||
link/ether 0a:58:0a:f4:03:08 brd ff:ff:ff:ff:ff:ff
|
||||
inet 10.244.3.8/24 scope global eth0
|
||||
valid_lft forever preferred_lft forever
|
||||
inet6 fe80::188a:84ff:feb0:26a5/64 scope link
|
||||
valid_lft forever preferred_lft forever
|
||||
```
|
||||
|
||||
そして、`wget`を使用してローカルのウェブサーバーに問い合わせます。
|
||||
|
||||
```shell
|
||||
# 10.0.170.92 の部分をウェブサーバーのPodのIPv4アドレスに置き換えてください
|
||||
wget -qO - 10.0.170.92
|
||||
```
|
||||
```
|
||||
CLIENT VALUES:
|
||||
client_address=10.244.3.8
|
||||
command=GET
|
||||
...
|
||||
```
|
||||
|
||||
`client_address`は常にクライアントのPodのIPアドレスになります。これは、クライアントのPodとサーバーのPodが同じノード内にあっても異なるノードにあっても変わりません。
|
||||
|
||||
## `Type=NodePort`を使用したServiceでの送信元IP
|
||||
|
||||
[`Type=NodePort`](/ja/docs/concepts/services-networking/service/#nodeport)を使用したServiceに送られたパケットは、デフォルトで送信元のNATが行われます。`NodePort` Serviceを作ることでテストできます。
|
||||
|
||||
```shell
|
||||
kubectl expose deployment source-ip-app --name=nodeport --port=80 --target-port=8080 --type=NodePort
|
||||
```
|
||||
|
||||
出力は次のようになります。
|
||||
|
||||
```
|
||||
service/nodeport exposed
|
||||
```
|
||||
|
||||
```shell
|
||||
NODEPORT=$(kubectl get -o jsonpath="{.spec.ports[0].nodePort}" services nodeport)
|
||||
NODES=$(kubectl get nodes -o jsonpath='{ $.items[*].status.addresses[?(@.type=="ExternalIP")].address }')
|
||||
```
|
||||
|
||||
クラウドプロバイダーで実行する場合、上に示した`nodes:nodeport`に対してファイアウォールのルールを作成する必要があるかもしれません。それでは、上で割り当てたノードポート経由で、クラスターの外部からServiceにアクセスしてみましょう。
|
||||
|
||||
```shell
|
||||
for node in $NODES; do curl -s $node:$NODEPORT | grep -i client_address; done
|
||||
```
|
||||
|
||||
出力は次のようになります。
|
||||
|
||||
```
|
||||
client_address=10.180.1.1
|
||||
client_address=10.240.0.5
|
||||
client_address=10.240.0.3
|
||||
```
|
||||
|
||||
これらは正しいクライアントIPではなく、クラスターのinternal IPであることがわかります。ここでは、次のようなことが起こっています。
|
||||
|
||||
* クライアントがパケットを`node2:nodePort`に送信する
|
||||
* `node2`は、パケット内の送信元IPアドレスを自ノードのIPアドレスに置換する(SNAT)
|
||||
* `node2`は、パケット内の送信先IPアドレスをPodのIPアドレスに置換する
|
||||
* パケットはnode1にルーティングされ、endpointにルーティングされる
|
||||
* Podからの応答がnode2にルーティングされて戻ってくる
|
||||
* Podからの応答がクライアントに送り返される
|
||||
|
||||
図で表すと次のようになります。
|
||||
|
||||
```
|
||||
client
|
||||
\ ^
|
||||
\ \
|
||||
v \
|
||||
node 1 <--- node 2
|
||||
| ^ SNAT
|
||||
| | --->
|
||||
v |
|
||||
endpoint
|
||||
```
|
||||
|
||||
クライアントのIPが失われることを回避するために、Kubernetesには[クライアントの送信元IPを保持する](/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)機能があります。`service.spec.externalTrafficPolicy`の値を`Local`に設定すると、kube-proxyはローカルに存在するエンドポイントへのプロキシーリクエストだけをプロキシーし、他のノードへはトラフィックを転送しなくなります。このアプローチでは、オリジナルの送信元IPアドレスが保持されます。ローカルにエンドポイントが存在しない場合には、そのノードに送信されたパケットは損失します。そのため、エンドポイントに到達するパケットに適用する可能性のあるパケット処理ルールでは、送信元IPが正しいことを信頼できます。
|
||||
|
||||
次のようにして`service.spec.externalTrafficPolicy`フィールドを設定します。
|
||||
|
||||
```shell
|
||||
kubectl patch svc nodeport -p '{"spec":{"externalTrafficPolicy":"Local"}}'
|
||||
```
|
||||
|
||||
出力は次のようになります。
|
||||
|
||||
```
|
||||
service/nodeport patched
|
||||
```
|
||||
|
||||
そして、再度テストしてみます。
|
||||
|
||||
```shell
|
||||
for node in $NODES; do curl --connect-timeout 1 -s $node:$NODEPORT | grep -i client_address; done
|
||||
```
|
||||
|
||||
出力は次のようになります。
|
||||
|
||||
```
|
||||
client_address=198.51.100.79
|
||||
```
|
||||
|
||||
今度は、*正しい*クライアントIPが含まれる応答が1つだけ得られました。これは、エンドポイントのPodが実行されているノードから来たものです。
|
||||
|
||||
ここでは、次のようなことが起こっています。
|
||||
|
||||
* クライアントがパケットをエンドポイントが存在しない`node2:nodePort`に送信する
|
||||
* パケットが損失する
|
||||
* クライアントがパケットをエンドポイントが*存在する*`node1:nodePort`に送信する
|
||||
* node1は、正しい送信元IPを持つパケットをエンドポイントにルーティングする
|
||||
|
||||
図で表すと次のようになります。
|
||||
|
||||
```
|
||||
client
|
||||
^ / \
|
||||
/ / \
|
||||
/ v X
|
||||
node 1 node 2
|
||||
^ |
|
||||
| |
|
||||
| v
|
||||
endpoint
|
||||
```
|
||||
|
||||
## `Type=LoadBalancer`を使用したServiceでの送信元IP
|
||||
|
||||
[`Type=LoadBalancer`](/ja/docs/concepts/services-networking/service/#loadbalancer)を使用したServiceに送られたパケットは、デフォルトでは送信元のNATは行われません。`Ready`状態にあるすべてのスケジュール可能なKubernetesのNodeは、ロードバランサーからのトラフィックを受付可能であるためです。そのため、エンドポイントが存在しないノードにパケットが到達した場合、システムはエンドポイントが*存在する*ノードにパケットをプロシキーします。このとき、(前のセクションで説明したように)パケットの送信元IPがノードのIPに置換されます。
|
||||
|
||||
ロードバランサー経由でsource-ip-appを公開することで、これをテストできます。
|
||||
|
||||
```shell
|
||||
kubectl expose deployment source-ip-app --name=loadbalancer --port=80 --target-port=8080 --type=LoadBalancer
|
||||
```
|
||||
|
||||
出力は次のようになります。
|
||||
|
||||
```
|
||||
service/loadbalancer exposed
|
||||
```
|
||||
|
||||
ServiceのIPアドレスを表示します。
|
||||
|
||||
```console
|
||||
kubectl get svc loadbalancer
|
||||
```
|
||||
|
||||
出力は次のようになります。
|
||||
|
||||
```
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
loadbalancer LoadBalancer 10.0.65.118 203.0.113.140 80/TCP 5m
|
||||
```
|
||||
|
||||
次に、Serviceのexternal-ipにリクエストを送信します。
|
||||
|
||||
```shell
|
||||
curl 203.0.113.140
|
||||
```
|
||||
|
||||
出力は次のようになります。
|
||||
|
||||
```
|
||||
CLIENT VALUES:
|
||||
client_address=10.240.0.5
|
||||
...
|
||||
```
|
||||
|
||||
しかし、Google Kubernetes EngineやGCE上で実行している場合、同じ`service.spec.externalTrafficPolicy`フィールドを`Local`に設定すると、ロードバランサーからのトラフィックを受け付け可能なノードのリストから、Serviceエンドポイントが*存在しない*ノードが強制的に削除されます。この動作は、ヘルスチェックを意図的に失敗させることによって実現されています。
|
||||
|
||||
図で表すと次のようになります。
|
||||
|
||||
```
|
||||
client
|
||||
|
|
||||
lb VIP
|
||||
/ ^
|
||||
v /
|
||||
ヘルスチェック ---> node 1 node 2 <--- ヘルスチェック
|
||||
200 <--- ^ | ---> 500
|
||||
| V
|
||||
endpoint
|
||||
```
|
||||
|
||||
アノテーションを設定することで動作をテストできます。
|
||||
|
||||
```shell
|
||||
kubectl patch svc loadbalancer -p '{"spec":{"externalTrafficPolicy":"Local"}}'
|
||||
```
|
||||
|
||||
Kubernetesにより割り当てられた`service.spec.healthCheckNodePort`フィールドをすぐに確認します。
|
||||
|
||||
```shell
|
||||
kubectl get svc loadbalancer -o yaml | grep -i healthCheckNodePort
|
||||
```
|
||||
|
||||
出力は次のようになります。
|
||||
|
||||
```yaml
|
||||
healthCheckNodePort: 32122
|
||||
```
|
||||
|
||||
`service.spec.healthCheckNodePort`フィールドは、`/healthz`でhealth checkを配信しているすべてのノード上のポートを指しています。次のコマンドでテストできます。
|
||||
|
||||
```shell
|
||||
kubectl get pod -o wide -l run=source-ip-app
|
||||
```
|
||||
|
||||
出力は次のようになります。
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE IP NODE
|
||||
source-ip-app-826191075-qehz4 1/1 Running 0 20h 10.180.1.136 kubernetes-node-6jst
|
||||
```
|
||||
|
||||
`curl`を使用して、さまざまなノード上の`/healthz`エンドポイントからデータを取得します。
|
||||
|
||||
```shell
|
||||
# このコマンドは選んだノードのローカル上で実行してください
|
||||
curl localhost:32122/healthz
|
||||
```
|
||||
```
|
||||
1 Service Endpoints found
|
||||
```
|
||||
|
||||
ノードが異なると、得られる結果も異なる可能性があります。
|
||||
|
||||
```shell
|
||||
# このコマンドは、選んだノード上でローカルに実行してください
|
||||
curl localhost:32122/healthz
|
||||
```
|
||||
```
|
||||
No Service Endpoints Found
|
||||
```
|
||||
|
||||
{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}上で実行中のコントローラーは、クラウドのロードバランサーを割り当てる責任があります。同じコントローラーは、各ノード上のポートやパスを指すHTTPのヘルスチェックも割り当てます。エンドポイントが存在しない2つのノードがヘルスチェックに失敗するまで約10秒待った後、`curl`を使用してロードバランサーのIPv4アドレスに問い合わせます。
|
||||
|
||||
```shell
|
||||
curl 203.0.113.140
|
||||
```
|
||||
|
||||
出力は次のようになります。
|
||||
|
||||
```
|
||||
CLIENT VALUES:
|
||||
client_address=198.51.100.79
|
||||
...
|
||||
```
|
||||
|
||||
## クロスプラットフォームのサポート
|
||||
|
||||
`Type=LoadBalancer`を使用したServiceで送信元IPを保持する機能を提供しているのは一部のクラウドプロバイダだけです。実行しているクラウドプロバイダによっては、以下のように異なる方法でリクエストを満たす場合があります。
|
||||
|
||||
1. クライアントとのコネクションをプロキシーが終端し、ノードやエンドポイントとの接続には新しいコネクションが開かれる。このような場合、送信元IPは常にクラウドのロードバランサーのものになり、クライアントのIPにはなりません。
|
||||
|
||||
2. クライアントからロードバランサーのVIPに送信されたリクエストが、中間のプロキシーではなく、クライアントの送信元IPとともにノードまで到達するようなパケット転送が使用される。
|
||||
|
||||
1つめのカテゴリーのロードバランサーの場合、真のクライアントIPと通信するために、 HTTPの[Forwarded](https://tools.ietf.org/html/rfc7239#section-5.2)ヘッダーや[X-FORWARDED-FOR](https://ja.wikipedia.org/wiki/X-Forwarded-For)ヘッダー、[proxy protocol](http://www.haproxy.org/download/1.5/doc/proxy-protocol.txt)などの、ロードバランサーとバックエンドの間で合意されたプロトコルを使用する必要があります。2つ目のカテゴリーのロードバランサーの場合、Serviceの`service.spec.healthCheckNodePort`フィールドに保存されたポートを指すHTTPのヘルスチェックを作成することで、上記の機能を活用できます。
|
||||
|
||||
## {{% heading "cleanup" %}}
|
||||
|
||||
Serviceを削除します。
|
||||
|
||||
```shell
|
||||
kubectl delete svc -l run=source-ip-app
|
||||
```
|
||||
|
||||
Deployment、ReplicaSet、Podを削除します。
|
||||
|
||||
```shell
|
||||
kubectl delete deployment source-ip-app
|
||||
```
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [Service経由でアプリケーションに接続する](/ja/docs/concepts/services-networking/connect-applications-service/)方法についてさらに学ぶ。
|
||||
* [External Load Balancerを作成する](/docs/tasks/access-application-cluster/create-external-load-balancer/)方法について学ぶ。
|
||||
|
||||
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
title: "ステートフルアプリケーション"
|
||||
weight: 50
|
||||
---
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,241 @@
|
||||
---
|
||||
title: "例: Persistent Volumeを使用したWordpressとMySQLをデプロイする"
|
||||
content_type: tutorial
|
||||
weight: 20
|
||||
card:
|
||||
name: tutorials
|
||||
weight: 40
|
||||
title: "ステートフルの例: Persistent Volumeを使用したWordpress"
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
このチュートリアルでは、WordPressのサイトとMySQLデータベースをMinikubeを使ってデプロイする方法を紹介します。2つのアプリケーションとも、データを保存するためにPersistentVolumeとPersistentVolumeClaimを使用します。
|
||||
|
||||
[PersistentVolume](/ja/docs/concepts/storage/persistent-volumes/)(PV)とは、管理者が手動でプロビジョニングを行うか、[StorageClass](/docs/concepts/storage/storage-classes)を使ってKubernetesによって動的にプロビジョニングされた、クラスター内のストレージの一部です。[PersistentVolumeClaim](/ja/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)(PVC)は、PVによって満たすことができる、ユーザーによるストレージへのリクエストのことです。PersistentVolumeとPersistentVolumeClaimは、Podのライフサイクルからは独立していて、Podの再起動、Podの再スケジューリング、さらにはPodの削除が行われたとしても、その中のデータは削除されずに残ります。
|
||||
|
||||
{{< warning >}}
|
||||
シングルインスタンスのWordPressとMySQLのPodを使用しているため、ここで行うデプロイは本番のユースケースには適しません。WordPressを本番環境にデプロイするときは、[WordPress Helm Chart](https://github.com/kubernetes/charts/tree/master/stable/wordpress)を使用することを検討してください。
|
||||
{{< /warning >}}
|
||||
|
||||
{{< note >}}
|
||||
このチュートリアルで提供されるファイルは、GAとなっているDeployment APIを使用しているため、Kubernetesバージョン1.9以降のためのものになっています。もしこのチュートリアルを古いバージョンのKubernetesで使いたい場合は、APIのバージョンを適切にアップデートするか、このチュートリアルの古いバージョンを参照してください。
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
|
||||
## {{% heading "objectives" %}}
|
||||
|
||||
* PersistentVolumeClaimとPersistentVolumeを作成する
|
||||
* 以下を含む`kustomization.yaml`を作成する
|
||||
* Secret generator
|
||||
* MySQLリソースの設定
|
||||
* WordPressリソースの設定
|
||||
* kustomizationディレクトリを`kubectl apply -k ./`で適用する
|
||||
* クリーンアップする
|
||||
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
このページで示された例は、`kubectl` 1.14以降で動作します。
|
||||
|
||||
以下の設定ファイルをダウンロードします。
|
||||
|
||||
1. [mysql-deployment.yaml](/examples/application/wordpress/mysql-deployment.yaml)
|
||||
|
||||
1. [wordpress-deployment.yaml](/examples/application/wordpress/wordpress-deployment.yaml)
|
||||
|
||||
|
||||
|
||||
<!-- lessoncontent -->
|
||||
|
||||
## PersistentVolumeClaimとPersistentVolumeを作成する
|
||||
|
||||
MySQLとWordpressはそれぞれ、データを保存するためのPersistentVolumeを必要とします。各PersistentVolumeClaimはデプロイの段階で作成されます。
|
||||
|
||||
多くのクラスタ環境では、デフォルトのStorageClassがインストールされています。StorageClassがPersistentVolumeClaim中で指定されていなかった場合、クラスターのデフォルトのStorageClassが代わりに使われます。
|
||||
|
||||
PersistentVolumeClaimが作成されるとき、StorageClassの設定に基づいてPersistentVolumeが動的にプロビジョニングされます。
|
||||
|
||||
{{< warning >}}
|
||||
ローカルのクラスターでは、デフォルトのStorageClassには`hostPath`プロビジョナーが使われます。`hostPath`ボリュームは開発およびテストにのみ適しています。`hostPath`ボリュームでは、データはPodがスケジュールされたノード上の`/tmp`内に保存されます。そのため、もしPodが死んだり、クラスター上の他のノードにスケジュールされたり、ノードが再起動すると、データは失われます。
|
||||
{{< /warning >}}
|
||||
|
||||
{{< note >}}
|
||||
`hostPath`プロビジョナーを使用する必要があるクラスターを立ち上げたい場合は、`--enable-hostpath-provisioner`フラグを `controller-manager` コンポーネントで設定する必要があります。
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
Google Kubernetes Engine上で動作するKubernetesクラスターを使っている場合は、[このガイド](https://cloud.google.com/kubernetes-engine/docs/tutorials/persistent-disk?hl=ja)に従ってください。
|
||||
{{< /note >}}
|
||||
|
||||
## kustomization.yamlを作成する
|
||||
|
||||
### Secret generatorを追加する
|
||||
|
||||
[Secret](/docs/concepts/configuration/secret/)とは、パスワードやキーのような機密性の高いデータ片を保存するためのオブジェクトです。バージョン1.14からは、`kubectl`がkustomizationファイルを使用したKubernetesオブジェクトの管理をサポートしています。`kustomization.yaml`内のgeneratorによってSecretを作成することができます。
|
||||
|
||||
以下のコマンドを実行して、`kustomization.yaml`の中にSecret generatorを追加します。`YOUR_PASSWORD`の部分を使いたいパスワードに置換してください。
|
||||
|
||||
```shell
|
||||
cat <<EOF >./kustomization.yaml
|
||||
secretGenerator:
|
||||
- name: mysql-pass
|
||||
literals:
|
||||
- password=YOUR_PASSWORD
|
||||
EOF
|
||||
```
|
||||
|
||||
## MySQLとWordPressのためのリソースの設定を追加する
|
||||
|
||||
以下のマニフェストには、シングルインスタンスのMySQLのDeploymentが書かれています。MySQLコンテナはPersistentVolumeを`/var/lib/mysql`にマウントします。`MYSQL_ROOT_PASSWORD`環境変数には、Secretから得られたデータベースのパスワードが設定されます。
|
||||
|
||||
{{< codenew file="application/wordpress/mysql-deployment.yaml" >}}
|
||||
|
||||
以下のマニフェストには、シングルインスタンスのWordPressのDeploymentが書かれています。WordPressコンテナはPersistentVolumeをウェブサイトのデータファイルのために`/var/www/html`にマウントします。`WORDPRESS_DB_HOST`環境変数に上で定義したMySQLのServiceの名前を設定すると、WordPressはServiceによってデータベースにアクセスします。`WORDPRESS_DB_PASSWORD`環境変数には、kustomizeが生成したSecretから得たデータベースのパスワードが設定されます。
|
||||
|
||||
|
||||
{{< codenew file="application/wordpress/wordpress-deployment.yaml" >}}
|
||||
|
||||
1. MySQLのDeploymentの設定ファイルをダウンロードします。
|
||||
|
||||
```shell
|
||||
curl -LO https://k8s.io/examples/application/wordpress/mysql-deployment.yaml
|
||||
```
|
||||
|
||||
2. WordPressの設定ファイルをダウンロードします。
|
||||
|
||||
```shell
|
||||
curl -LO https://k8s.io/examples/application/wordpress/wordpress-deployment.yaml
|
||||
```
|
||||
|
||||
3. これらを`kustomization.yaml`ファイルに追加します。
|
||||
|
||||
```shell
|
||||
cat <<EOF >>./kustomization.yaml
|
||||
resources:
|
||||
- mysql-deployment.yaml
|
||||
- wordpress-deployment.yaml
|
||||
EOF
|
||||
```
|
||||
|
||||
## 適用と確認
|
||||
|
||||
`kustomization.yaml`には、WordPressのサイトとMySQLデータベースのためのすべてのリソースが含まれています。次のコマンドでこのディレクトリを適用できます。
|
||||
|
||||
```shell
|
||||
kubectl apply -k ./
|
||||
```
|
||||
|
||||
これで、すべてのオブジェクトが存在していることを確認できます。
|
||||
|
||||
1. 次のコマンドを実行して、Secretが存在していることを確認します。
|
||||
|
||||
```shell
|
||||
kubectl get secrets
|
||||
```
|
||||
|
||||
結果は次のようになるはずです。
|
||||
|
||||
```shell
|
||||
NAME TYPE DATA AGE
|
||||
mysql-pass-c57bb4t7mf Opaque 1 9s
|
||||
```
|
||||
|
||||
1. 次のコマンドを実行して、PersistentVolumeが動的にプロビジョニングされていることを確認します。
|
||||
|
||||
```shell
|
||||
kubectl get pvc
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
PVがプロビジョニングされてバインドされるまでに、最大で数分かかる場合があります。
|
||||
{{< /note >}}
|
||||
|
||||
結果は次のようになるはずです。
|
||||
|
||||
```shell
|
||||
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
|
||||
mysql-pv-claim Bound pvc-8cbd7b2e-4044-11e9-b2bb-42010a800002 20Gi RWO standard 77s
|
||||
wp-pv-claim Bound pvc-8cd0df54-4044-11e9-b2bb-42010a800002 20Gi RWO standard 77s
|
||||
```
|
||||
|
||||
3. 次のコマンドを実行して、Podが実行中であることを確認します。
|
||||
|
||||
```shell
|
||||
kubectl get pods
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
PodのStatusが`Running`の状態になる前に、最大で数分かかる場合があります。
|
||||
{{< /note >}}
|
||||
|
||||
結果は次のようになるはずです。
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
wordpress-mysql-1894417608-x5dzt 1/1 Running 0 40s
|
||||
```
|
||||
|
||||
4. 次のコマンドを実行して、Serviceが実行中であることを確認します。
|
||||
|
||||
```shell
|
||||
kubectl get services wordpress
|
||||
```
|
||||
|
||||
結果は次のようになるはずです。
|
||||
|
||||
```
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
wordpress ClusterIP 10.0.0.89 <pending> 80:32406/TCP 4m
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
MinikubeではServiceを`NodePort`経由でしか公開できません。EXTERNAL-IPは常にpendingのままになります。
|
||||
{{< /note >}}
|
||||
|
||||
5. 次のコマンドを実行して、WordPress ServiceのIPアドレスを取得します。
|
||||
|
||||
```shell
|
||||
minikube service wordpress --url
|
||||
```
|
||||
|
||||
結果は次のようになるはずです。
|
||||
|
||||
```
|
||||
http://1.2.3.4:32406
|
||||
```
|
||||
|
||||
6. IPアドレスをコピーして、ブラウザーで読み込み、サイトを表示しましょう。
|
||||
|
||||
WordPressによりセットアップされた次のスクリーンショットのようなページが表示されるはずです。
|
||||
|
||||
|
||||
|
||||
{{< warning >}}
|
||||
WordPressのインストールをこのページのまま放置してはいけません。もしほかのユーザーがこのページを見つけた場合、その人はインスタンス上にウェブサイトをセットアップして、悪意のあるコンテンツの配信に利用できてしまいます。<br/><br/>ユーザー名とパスワードを決めてWordPressをインストールするか、このインスタンスを削除してください。
|
||||
{{< /warning >}}
|
||||
|
||||
|
||||
|
||||
## {{% heading "cleanup" %}}
|
||||
|
||||
|
||||
1. 次のコマンドを実行して、Secret、Deployment、Service、およびPersistentVolumeClaimを削除します。
|
||||
|
||||
```shell
|
||||
kubectl delete -k ./
|
||||
```
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* [イントロスペクションとデバッグ](/docs/tasks/debug-application-cluster/debug-application-introspection/)についてさらに学ぶ
|
||||
* [Job](/docs/concepts/workloads/controllers/job/)についてさらに学ぶ
|
||||
* [Portフォワーディング](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)についてさらに学ぶ
|
||||
* [コンテナへのシェルを取得する](/ja/docs/tasks/debug-application-cluster/get-shell-running-container/)方法について学ぶ
|
||||
|
||||
@@ -0,0 +1,370 @@
|
||||
---
|
||||
title: "例: Redisを使用したPHPのゲストブックアプリケーションのデプロイ"
|
||||
content_type: tutorial
|
||||
weight: 20
|
||||
card:
|
||||
name: tutorials
|
||||
weight: 30
|
||||
title: "ステートレスの例: Redisを使用したPHPのゲストブック"
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
このチュートリアルでは、Kubernetesと[Docker](https://www.docker.com/)を使用した、シンプルなマルチティアのウェブアプリケーションのビルドとデプロイの方法を紹介します。この例は、以下のコンポーネントから構成されています。
|
||||
|
||||
* ゲストブックのエントリーを保存するための、シングルインスタンスの[Redis](https://redis.io/)マスター
|
||||
* 読み込みデータ配信用の、複数の[レプリケーションされたRedis](https://redis.io/topics/replication)インスタンス
|
||||
* 複数のウェブフロントエンドのインスタンス
|
||||
|
||||
|
||||
|
||||
## {{% heading "objectives" %}}
|
||||
|
||||
* Redisのマスターを起動する。
|
||||
* Redisのスレーブを起動する。
|
||||
* ゲストブックのフロントエンドを起動する。
|
||||
* フロントエンドのServiceを公開して表示を確認する。
|
||||
* クリーンアップする。
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
{{< version-check >}}
|
||||
|
||||
|
||||
|
||||
<!-- lessoncontent -->
|
||||
|
||||
## Redisのマスターを起動する
|
||||
|
||||
ゲストブックアプリケーションでは、データを保存するためにRedisを使用します。ゲストブックはRedisのマスターインスタンスにデータを書き込み、複数のRedisのスレーブインスタンスからデータを読み込みます。
|
||||
|
||||
### RedisのマスターのDeploymentを作成する
|
||||
|
||||
以下のマニフェストファイルは、シングルレプリカのRedisのマスターPodを実行するDeploymentコントローラーを指定しています。
|
||||
|
||||
{{< codenew file="application/guestbook/redis-master-deployment.yaml" >}}
|
||||
|
||||
1. マニフェストファイルをダウンロードしたディレクトリ内で、ターミナルウィンドウを起動します。
|
||||
1. `redis-master-deployment.yaml`ファイルから、RedisのマスターのDeploymentを適用します。
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-deployment.yaml
|
||||
```
|
||||
|
||||
1. Podのリストを問い合わせて、RedisのマスターのPodが実行中になっていることを確認します。
|
||||
|
||||
```shell
|
||||
kubectl get pods
|
||||
```
|
||||
|
||||
結果は次のようになるはずです。
|
||||
|
||||
```shell
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
redis-master-1068406935-3lswp 1/1 Running 0 28s
|
||||
```
|
||||
|
||||
1. 次のコマンドを実行して、RedisのマスターのPodからログを表示します。
|
||||
|
||||
```shell
|
||||
kubectl logs -f POD-NAME
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
POD-NAMEの部分を実際のPodの名前に書き換えてください。
|
||||
{{< /note >}}
|
||||
|
||||
### RedisのマスターのServiceを作成する
|
||||
|
||||
ゲストブックアプリケーションは、データを書き込むためにRedisのマスターと通信する必要があります。そのためには、[Service](/docs/concepts/services-networking/service/)を適用して、トラフィックをRedisのマスターのPodへプロキシーしなければなりません。Serviceは、Podにアクセスするためのポリシーを指定します。
|
||||
|
||||
{{< codenew file="application/guestbook/redis-master-service.yaml" >}}
|
||||
|
||||
1. 次の`redis-master-service.yaml`から、RedisのマスターのServiceを適用します。
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-service.yaml
|
||||
```
|
||||
|
||||
1. Serviceのリストを問い合わせて、RedisのマスターのServiceが実行中になっていることを確認します。
|
||||
|
||||
```shell
|
||||
kubectl get service
|
||||
```
|
||||
|
||||
The response should be similar to this:
|
||||
|
||||
```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
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
このマニフェストファイルは、`redis-master`という名前のServiceを、前に定義したラベルにマッチする一連のラベル付きで作成します。これにより、ServiceはネットワークトラフィックをRedisのマスターのPodへとルーティングできるようになります。
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
## Redisのスレーブを起動する
|
||||
|
||||
Redisのマスターは1つのPodですが、レプリカのRedisのスレーブを追加することで、トラフィックの需要を満たすための高い可用性を持たせることができます。
|
||||
|
||||
### RedisのスレーブのDeploymentを作成する
|
||||
|
||||
Deploymentはマニフェストファイル内に書かれた設定に基づいてスケールします。ここでは、Deploymentオブジェクトは2つのレプリカを指定しています。
|
||||
|
||||
もし1つもレプリカが実行されていなければ、このDeploymentは2つのレプリカをコンテナクラスター上で起動します。逆に、もしすでに2つ以上のレプリカが実行されていれば、実行中のレプリカが2つになるようにスケールダウンします。
|
||||
|
||||
{{< codenew file="application/guestbook/redis-slave-deployment.yaml" >}}
|
||||
|
||||
1. `redis-slave-deployment.yaml`ファイルから、RedisのスレーブのDeploymentを適用します。
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/application/guestbook/redis-slave-deployment.yaml
|
||||
```
|
||||
|
||||
1. Podのリストを問い合わせて、RedisのスレーブのPodが実行中になっていることを確認します。
|
||||
|
||||
```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のスレーブのServiceを作成する
|
||||
|
||||
ゲストブックアプリケーションは、データを読み込むためにRedisのスレーブと通信する必要があります。Redisのスレーブが発見できるようにするためには、Serviceをセットアップする必要があります。Serviceは一連のPodに対する透過的なロードバランシングを提供します。
|
||||
|
||||
{{< codenew file="application/guestbook/redis-slave-service.yaml" >}}
|
||||
|
||||
1. 次の`redis-slave-service.yaml`ファイルから、RedisのスレーブのServiceを適用します。
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/application/guestbook/redis-slave-service.yaml
|
||||
```
|
||||
|
||||
1. Serviceのリストを問い合わせて、RedisのスレーブのServiceが実行中になっていることを確認します。
|
||||
|
||||
```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
|
||||
```
|
||||
|
||||
## ゲストブックのフロントエンドをセットアップして公開する
|
||||
|
||||
ゲストブックアプリケーションには、HTTPリクエストをサーブするPHPで書かれたウェブフロントエンドがあります。このアプリケーションは、書き込みリクエストに対しては`redis-master` Serviceに、読み込みリクエストに対しては`redis-slave` Serviceに接続するように設定されています。
|
||||
|
||||
### ゲストブックのフロントエンドのDeploymentを作成する
|
||||
|
||||
{{< codenew file="application/guestbook/frontend-deployment.yaml" >}}
|
||||
|
||||
1. `frontend-deployment.yaml`ファイルから、フロントエンドのDeploymentを適用します。
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/application/guestbook/frontend-deployment.yaml
|
||||
```
|
||||
|
||||
1. Podのリストを問い合わせて、3つのフロントエンドのレプリカが実行中になっていることを確認します。
|
||||
|
||||
```shell
|
||||
kubectl get pods -l app=guestbook -l tier=frontend
|
||||
```
|
||||
|
||||
結果は次のようになるはずです。
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
frontend-3823415956-dsvc5 1/1 Running 0 54s
|
||||
frontend-3823415956-k22zn 1/1 Running 0 54s
|
||||
frontend-3823415956-w9gbt 1/1 Running 0 54s
|
||||
```
|
||||
|
||||
### フロントエンドのServiceを作成する
|
||||
|
||||
適用した`redis-slave`および`redis-master` Serviceは、コンテナクラスター内部からのみアクセス可能です。これは、デフォルトのServiceのtypeが[ClusterIP](/docs/concepts/services-networking/service/#publishing-services---service-types)であるためです。`ClusterIP`は、Serviceが指している一連のPodに対して1つのIPアドレスを提供します。このIPアドレスはクラスター内部からのみアクセスできます。
|
||||
|
||||
もしゲストの人にゲストブックにアクセスしてほしいのなら、フロントエンドServiceを外部から見えるように設定しなければなりません。そうすれば、クライアントはコンテナクラスターの外部からServiceにリクエストを送れるようになります。Minikubeでは、Serviceを`NodePort`でのみ公開できます。
|
||||
|
||||
{{< note >}}
|
||||
一部のクラウドプロバイダーでは、Google Compute EngineやGoogle Kubernetes Engineなど、外部のロードバランサーをサポートしているものがあります。もしクラウドプロバイダーがロードバランサーをサポートしていて、それを使用したい場合は、`type: NodePort`という行を単に削除またはコメントアウトして、`type: LoadBalancer`のコメントアウトを外せば使用できます。
|
||||
{{< /note >}}
|
||||
|
||||
{{< codenew file="application/guestbook/frontend-service.yaml" >}}
|
||||
|
||||
1. `frontend-service.yaml`ファイルから、フロントエンドのServiceを提供します。
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/application/guestbook/frontend-service.yaml
|
||||
```
|
||||
|
||||
1. Serviceのリストを問い合わせて、フロントエンドのServiceが実行中であることを確認します。
|
||||
|
||||
```shell
|
||||
kubectl get services
|
||||
```
|
||||
|
||||
結果は次のようになるはずです。
|
||||
|
||||
```
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
frontend NodePort 10.0.0.112 <none> 80:31323/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
|
||||
```
|
||||
|
||||
### フロントエンドのServiceを`NodePort`経由で表示する
|
||||
|
||||
このアプリケーションをMinikubeやローカルのクラスターにデプロイした場合、ゲストブックを表示するためのIPアドレスを見つける必要があります。
|
||||
|
||||
1. 次のコマンドを実行すると、フロントエンドServiceに対するIPアドレスを取得できます。
|
||||
|
||||
```shell
|
||||
minikube service frontend --url
|
||||
```
|
||||
|
||||
結果は次のようになるはずです。
|
||||
|
||||
```
|
||||
http://192.168.99.100:31323
|
||||
```
|
||||
|
||||
1. IPアドレスをコピーして、ブラウザー上でページを読み込み、ゲストブックを表示しましょう。
|
||||
|
||||
### フロントエンドのServiceを`LoadBalancer`経由で表示する
|
||||
|
||||
もし`frontend-service.yaml`マニフェストを`type: LoadBalancer`でデプロイした場合、ゲストブックを表示するためのIPアドレスを見つける必要があります。
|
||||
|
||||
1. 次のコマンドを実行すると、フロントエンドServiceに対するIPアドレスを取得できます。
|
||||
|
||||
```shell
|
||||
kubectl get service frontend
|
||||
```
|
||||
|
||||
結果は次のようになるはずです。
|
||||
|
||||
```
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
frontend ClusterIP 10.51.242.136 109.197.92.229 80:32372/TCP 1m
|
||||
```
|
||||
|
||||
1. 外部IPアドレス(EXTERNAL-IP)をコピーして、ブラウザー上でページを読み込み、ゲストブックを表示しましょう。
|
||||
|
||||
## ウェブフロントエンドをスケールする
|
||||
|
||||
サーバーがDeploymentコントローラーを使用するServiceとして定義されているため、スケールアップやスケールダウンは簡単です。
|
||||
|
||||
1. 次のコマンドを実行すると、フロントエンドのPodの数をスケールアップできます。
|
||||
|
||||
```shell
|
||||
kubectl scale deployment frontend --replicas=5
|
||||
```
|
||||
|
||||
1. Podのリストを問い合わせて、実行中のフロントエンドのPodの数を確認します。
|
||||
|
||||
```shell
|
||||
kubectl get pods
|
||||
```
|
||||
|
||||
結果は次のようになるはずです。
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
frontend-3823415956-70qj5 1/1 Running 0 5s
|
||||
frontend-3823415956-dsvc5 1/1 Running 0 54m
|
||||
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
|
||||
```
|
||||
|
||||
1. 次のコマンドを実行すると、フロントエンドのPodの数をスケールダウンできます。
|
||||
|
||||
```shell
|
||||
kubectl scale deployment frontend --replicas=2
|
||||
```
|
||||
|
||||
1. Podのリストを問い合わせて、実行中のフロントエンドのPodの数を確認します。
|
||||
|
||||
```shell
|
||||
kubectl get pods
|
||||
```
|
||||
|
||||
結果は次のようになるはずです。
|
||||
|
||||
```
|
||||
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
|
||||
```
|
||||
|
||||
|
||||
|
||||
## {{% heading "cleanup" %}}
|
||||
|
||||
DeploymentとServiceを削除すると、実行中のPodも削除されます。ラベルを使用すると、複数のリソースを1つのコマンドで削除できます。
|
||||
|
||||
1. 次のコマンドを実行すると、すべてのPod、Deployment、Serviceが削除されます。
|
||||
|
||||
```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
|
||||
```
|
||||
|
||||
結果は次のようになるはずです。
|
||||
|
||||
```
|
||||
deployment.apps "redis-master" deleted
|
||||
deployment.apps "redis-slave" deleted
|
||||
service "redis-master" deleted
|
||||
service "redis-slave" deleted
|
||||
deployment.apps "frontend" deleted
|
||||
service "frontend" deleted
|
||||
```
|
||||
|
||||
1. Podのリストを問い合わせて、実行中のPodが存在しないことを確認します。
|
||||
|
||||
```shell
|
||||
kubectl get pods
|
||||
```
|
||||
|
||||
結果は次のようになるはずです。
|
||||
|
||||
```
|
||||
No resources found.
|
||||
```
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* ゲストブックアプリケーションに対する[ELKによるロギングとモニタリング](/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk/)
|
||||
* [Kubernetesの基本](/ja/docs/tutorials/kubernetes-basics/)のインタラクティブチュートリアルを終わらせる
|
||||
* Kubernetesを使って、[MySQLとWordpressのためにPersistent Volume](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/#visit-your-new-wordpress-blog)を使用したブログを作成する
|
||||
* [サービスとアプリケーションの接続](/ja/docs/concepts/services-networking/connect-applications-service/)についてもっと読む
|
||||
* [リソースの管理](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)についてもっと読む
|
||||
Reference in New Issue
Block a user