Merge branch 'dev-1.17-ja.3' of https://github.com/kubernetes/website into dev-1.17-ja.3
This commit is contained in:
nishipy
@@ -229,7 +229,9 @@ kubeletはリソースの割当を決定する際にトポロジーのヒント
|
||||
|
||||
NodeはKubernetesのREST APIにおけるトップレベルのリソースです。APIオブジェクトに関する詳細は以下の記事にてご覧いただけます:
|
||||
[Node APIオブジェクト](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core).
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [ノードコンポーネント](/ja/docs/concepts/overview/components/#node-components)について読む。
|
||||
* ノードレベルのトポロジーについて読む: [ノードのトポロジー管理ポリシーを制御する](/docs/tasks/administer-cluster/topology-manager/)
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: taintとtoleration
|
||||
title: TaintとToleration
|
||||
content_type: concept
|
||||
weight: 40
|
||||
---
|
||||
@@ -7,9 +7,9 @@ weight: 40
|
||||
|
||||
<!-- overview -->
|
||||
[_Nodeアフィニティ_](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)は
|
||||
{{< glossary_tooltip text="Pod" term_id="pod" >}}の属性であり、ある{{< glossary_tooltip text="Node" term_id="node" >}}群を*引きつけます*（優先条件または必須条件）。 反対に_taint_はNodeがある種のPodを排除できるようにします。
|
||||
{{< glossary_tooltip text="Pod" term_id="pod" >}}の属性であり、ある{{< glossary_tooltip text="Node" term_id="node" >}}群を*引きつけます*（優先条件または必須条件）。反対に _taint_ はNodeがある種のPodを排除できるようにします。
|
||||
|
||||
_toleration_はPodに適用され、一致するtaintが付与されたNodeへPodがスケジューリングされることを認めるものです。ただしそのNodeへ必ずスケジューリングされるとは限りません。
|
||||
_toleration_ はPodに適用され、一致するtaintが付与されたNodeへPodがスケジューリングされることを認めるものです。ただしそのNodeへ必ずスケジューリングされるとは限りません。
|
||||
|
||||
taintとtolerationは組になって機能し、Podが不適切なNodeへスケジューリングされないことを保証します。taintはNodeに一つまたは複数個付与することができます。これはそのNodeがtaintを許容しないPodを受け入れるべきではないことを示します。
|
||||
|
||||
|
||||
@@ -0,0 +1,57 @@
|
||||
---
|
||||
title: Ingressコントローラー
|
||||
reviewers:
|
||||
content_type: concept
|
||||
weight: 40
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
Ingressリソースが動作するためには、クラスターでIngressコントローラーが実行されている必要があります。
|
||||
|
||||
`kube-controller-manager`バイナリの一部として実行される他のタイプのコントローラーとは異なり、Ingressコントローラーはクラスターで自動的に起動されません。このページを使用して、クラスターに最適なIngressコントローラーの実装を選択してください。
|
||||
|
||||
プロジェクトとしてのKubernetesは現在、[GCE](https://git.k8s.io/ingress-gce/README.md)と[nginx](https://git.k8s.io/ingress-nginx/README.md)のコントローラーをサポートし、保守しています。
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## 追加のコントローラー {#additional-controllers}
|
||||
|
||||
* [AKS Application Gateway Ingress Controller](https://github.com/Azure/application-gateway-kubernetes-ingress)は[Azure Application Gateway](https://docs.microsoft.com/azure/application-gateway/overview)を利用して[AKSクラスター](https://docs.microsoft.com/azure/aks/kubernetes-walkthrough-portal)でIngressを実行可能にするIngressコントローラーです。
|
||||
* [Ambassador](https://www.getambassador.io/) API Gatewayは[Envoy](https://www.envoyproxy.io)ベースのIngressコントローラーで、[Datawire](https://www.datawire.io/)による[コミュニティ版](https://www.getambassador.io/docs)または[商用版](https://www.getambassador.io/pro/)のサポートがあります。
|
||||
* [AppsCode Inc.](https://appscode.com)では、最も広く使用されている[HAProxy](http://www.haproxy.org/)ベースのIngressコントローラーである[Voyager](https://appscode.com/products/voyager)のサポートと保守を提供しています。
|
||||
* [AWS ALB Ingress Controller](https://github.com/kubernetes-sigs/aws-alb-ingress-controller)は[AWS Application Load Balancer](https://aws.amazon.com/elasticloadbalancing/)を使用したIngressを有効にします。
|
||||
* [Contour](https://projectcontour.io/)は、VMwareが提供し、サポートしている[Envoy](https://www.envoyproxy.io/)ベースのIngressコントローラーです。
|
||||
* Citrixは、[ベアメタル](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment/baremetal)と[クラウド](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment)のデプロイ用に、ハードウェア(MPX）、仮想化(VPX)、[フリーコンテナ化(CPX) ADC](https://www.citrix.com/products/citrix-adc/cpx-express.html)用の[Ingressコントローラー](https://github.com/citrix/citrix-k8s-ingress-controller)を提供しています。
|
||||
* F5 Networksは[F5 BIG-IP Controller for Kubernetes](http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest)の[サポートと保守](https://support.f5.com/csp/article/K86859508)を提供しています。
|
||||
* [Gloo](https://gloo.solo.io)は[Envoy](https://www.envoyproxy.io)をベースにしたオープンソースのIngressコントローラーで、[solo.io](https://www.solo.io)からのエンタープライズサポートでAPI Gateway機能を提供しています。
|
||||
* [HAProxy Ingress](https://haproxy-ingress.github.io)は、HAProxy用の高度にカスタマイズ可能なコミュニティ主導のIngressコントローラーです。
|
||||
* [HAProxy Technologies](https://www.haproxy.com/)は[HAProxy Ingress Controller for Kubernetes](https://github.com/haproxytech/kubernetes-ingress)のサポートと保守を提供しています。[公式ドキュメント](https://www.haproxy.com/documentation/hapee/1-9r1/traffic-management/kubernetes-ingress-controller/)を参照してください。
|
||||
* [Istio](https://istio.io/)ベースのIngressコントローラー[Control Ingress Traffic](https://istio.io/docs/tasks/traffic-management/ingress/)。
|
||||
* [Kong](https://konghq.com/)は、[Kong Ingress Controller for Kubernetes](https://github.com/Kong/kubernetes-ingress-controller)の[コミュニティ版](https://discuss.konghq.com/c/kubernetes)と[商用版]](https://konghq.com/kong-enterprise/)のサポートと保守を提供しています。
|
||||
* [NGINX, Inc.](https://www.nginx.com/)は[NGINX Ingress Controller for Kubernetes](https://www.nginx.com/products/nginx/kubernetes-ingress-controller)のサポートと保守を提供しています。
|
||||
* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/)は、カスタムプロキシーを構築するためのライブラリーとして設計された、Kubernetes Ingressなどのユースケースを含む、サービス構成用のHTTPルーターとリバースプロキシーです。
|
||||
* [Traefik](https://github.com/containous/traefik)はフル機能([Let's Encrypt](https://letsencrypt.org), secrets, http2, websocket)のIngressコントローラーで、[Containous](https://containo.us/services)による商用サポートもあります。
|
||||
|
||||
## 複数のIngressコントローラーの使用 {#using-multiple-ingress-controllers}
|
||||
|
||||
[Ingressコントローラーは、好きな数だけ](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers))クラスターにデプロイすることができます。Ingressを作成する際には、クラスター内に複数のIngressコントローラーが存在する場合にどのIngressコントローラーを使用するかを示すために適切な[`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster)のアノテーションを指定します。
|
||||
|
||||
クラスを定義しない場合、クラウドプロバイダーはデフォルトのIngressコントローラーを使用する場合があります。
|
||||
|
||||
理想的には、すべてのIngressコントローラーはこの仕様を満たすべきですが、いくつかのIngressコントローラーはわずかに異なる動作をします。
|
||||
|
||||
|
||||
{{< note >}}
|
||||
Ingressコントローラーのドキュメントを確認して、選択する際の注意点を理解してください。
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* [Ingress](/ja/docs/concepts/services-networking/ingress/)の詳細
|
||||
* [Set up Ingress on Minikube with the NGINX Controller](/docs/tasks/access-application-cluster/ingress-minikube)
|
||||
Executable
+17
@@ -0,0 +1,17 @@
|
||||
---
|
||||
title: イメージ
|
||||
id: image
|
||||
date: 2018-04-12
|
||||
full_link:
|
||||
short_description: >
|
||||
アプリケーションの実行に必要なソフトウェアのセットを持つ、保存されたコンテナの実体です。
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
---
|
||||
アプリケーションの実行に必要なソフトウェアのセットを持つ、保存された{{< glossary_tooltip text="コンテナ" term_id="container" >}}の実体です。
|
||||
|
||||
<!--more-->
|
||||
|
||||
コンテナレジストリに格納し、ローカルシステムにプルして、アプリケーションとして実行できるようにするソフトウェアをパッケージ化する方法です。イメージに含まれているメタデータは、実行する実行可能ファイル、作成者、およびその他の情報を示すことができます。
|
||||
@@ -303,7 +303,7 @@ kubectl get nodes --show-labels
|
||||
Create the guestbook-go example, which includes an RC of size 3, running a simple web app:
|
||||
|
||||
```shell
|
||||
find kubernetes/examples/guestbook-go/ -name '*.json' | xargs -I {} kubectl create -f {}
|
||||
find kubernetes/examples/guestbook-go/ -name '*.json' | xargs -I {} kubectl apply -f {}
|
||||
```
|
||||
|
||||
The pods should be spread across all 3 zones:
|
||||
|
||||
BIN
Binary file not shown.
|
Before Width: | Height: | Size: 109 KiB |
BIN
Binary file not shown.
|
Before Width: | Height: | Size: 25 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 6.9 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 3.5 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 3.4 MiB |
@@ -91,9 +91,9 @@ Once you have a Linux-based Kubernetes master node you are ready to choose a net
|
||||
|
||||
1. In the `net-conf.json` section of your `kube-flannel.yml`, double-check:
|
||||
1. The cluster subnet (e.g. "10.244.0.0/16") is set as per your IP plan.
|
||||
* VNI 4096 is set in the backend
|
||||
* Port 4789 is set in the backend
|
||||
2. In the `cni-conf.json` section of your `kube-flannel.yml`, change the network name to `vxlan0`.
|
||||
* VNI 4096 is set in the backend
|
||||
* Port 4789 is set in the backend
|
||||
1. In the `cni-conf.json` section of your `kube-flannel.yml`, change the network name to `vxlan0`.
|
||||
|
||||
|
||||
Your `cni-conf.json` should look as follows:
|
||||
@@ -134,7 +134,18 @@ Once you have a Linux-based Kubernetes master node you are ready to choose a net
|
||||
kubectl get pods --all-namespaces
|
||||
```
|
||||
|
||||
|
||||
The output looks like as follows:
|
||||
|
||||
```
|
||||
NAMESPACE NAME READY STATUS RESTARTS AGE
|
||||
kube-system etcd-flannel-master 1/1 Running 0 1m
|
||||
kube-system kube-apiserver-flannel-master 1/1 Running 0 1m
|
||||
kube-system kube-controller-manager-flannel-master 1/1 Running 0 1m
|
||||
kube-system kube-dns-86f4d74b45-hcx8x 3/3 Running 0 12m
|
||||
kube-system kube-flannel-ds-54954 1/1 Running 0 1m
|
||||
kube-system kube-proxy-Zjlxz 1/1 Running 0 1m
|
||||
kube-system kube-scheduler-flannel-master 1/1 Running 0 1m
|
||||
```
|
||||
|
||||
Verify that the Flannel DaemonSet has the NodeSelector applied.
|
||||
|
||||
@@ -142,13 +153,20 @@ Once you have a Linux-based Kubernetes master node you are ready to choose a net
|
||||
kubectl get ds -n kube-system
|
||||
```
|
||||
|
||||
|
||||
The output looks like as follows. The NodeSelector `beta.kubernetes.io/os=linux` is applied.
|
||||
|
||||
```
|
||||
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
|
||||
kube-flannel-ds 2 2 2 2 2 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux 21d
|
||||
kube-proxy 2 2 2 2 2 beta.kubernetes.io/os=linux 26d
|
||||
```
|
||||
|
||||
#### Join Windows Worker
|
||||
|
||||
In this section we'll cover configuring a Windows node from scratch to join a cluster on-prem. If your cluster is on a cloud you'll likely want to follow the cloud specific guides in the next section.
|
||||
|
||||
#### Preparing a Windows Node
|
||||
|
||||
{{< note >}}
|
||||
All code snippets in Windows sections are to be run in a PowerShell environment with elevated permissions (Admin).
|
||||
{{< /note >}}
|
||||
@@ -171,9 +189,28 @@ All code snippets in Windows sections are to be run in a PowerShell environment
|
||||
[Environment]::SetEnvironmentVariable("HTTPS_PROXY", "http://proxy.example.com:443/", [EnvironmentVariableTarget]::Machine)
|
||||
```
|
||||
|
||||
If after reboot you see the following error, you need to restart the docker service manually
|
||||
After reboot, you can verify that the docker service is ready with the command below.
|
||||
|
||||
|
||||
```PowerShell
|
||||
docker version
|
||||
```
|
||||
|
||||
If you see error message like the following, you need to start the docker service manually.
|
||||
|
||||
```
|
||||
Client:
|
||||
Version: 17.06.2-ee-11
|
||||
API version: 1.30
|
||||
Go version: go1.8.7
|
||||
Git commit: 06fc007
|
||||
Built: Thu May 17 06:14:39 2018
|
||||
OS/Arch: windows / amd64
|
||||
error during connect: Get http://%2F%2F.%2Fpipe%2Fdocker_engine/v1.30/version: open //./pipe/docker_engine: The system c
|
||||
annot find the file specified. In the default daemon configuration on Windows, the docker client must be run elevated to
|
||||
connect. This error may also indicate that the docker daemon is not running.
|
||||
```
|
||||
|
||||
You can start the docker service manually like below.
|
||||
|
||||
```PowerShell
|
||||
Start-Service docker
|
||||
@@ -220,7 +257,13 @@ wget https://raw.githubusercontent.com/Microsoft/SDN/master/Kubernetes/flannel/s
|
||||
{{< /note >}}
|
||||
|
||||
```PowerShell
|
||||
.\start.ps1 -ManagementIP <Windows Node IP> -NetworkMode overlay -ClusterCIDR <Cluster CIDR> -ServiceCIDR <Service CIDR> -KubeDnsServiceIP <Kube-dns Service IP> -LogDir <Log directory>
|
||||
cd c:\k
|
||||
.\start.ps1 -ManagementIP <Windows Node IP> `
|
||||
-NetworkMode overlay `
|
||||
-ClusterCIDR <Cluster CIDR> `
|
||||
-ServiceCIDR <Service CIDR> `
|
||||
-KubeDnsServiceIP <Kube-dns Service IP> `
|
||||
-LogDir <Log directory>
|
||||
```
|
||||
|
||||
| Parameter | Default Value | Notes |
|
||||
@@ -261,4 +304,3 @@ Kubeadm is becoming the de facto standard for users to deploy a Kubernetes clust
|
||||
|
||||
Now that you've configured a Windows worker in your cluster to run Windows containers you may want to add one or more Linux nodes as well to run Linux containers. You are now ready to schedule Windows containers on your cluster.
|
||||
|
||||
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 80 KiB |
@@ -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)についてもっと読む
|
||||
@@ -0,0 +1,15 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: nginx
|
||||
labels:
|
||||
env: test
|
||||
spec:
|
||||
containers:
|
||||
- name: nginx
|
||||
image: nginx
|
||||
imagePullPolicy: IfNotPresent
|
||||
tolerations:
|
||||
- key: "example-key"
|
||||
operator: "Exists"
|
||||
effect: "NoSchedule"
|
||||
Reference in New Issue
Block a user