--ip-masq=1 --kube-subnet-mgr=1
```
-1. My Windows Pods cannot launch because of missing `/run/flannel/subnet.env`
+1. `/run/flannel/subnet.env`がないため、Windows Podを起動できません
- This indicates that Flannel didn't launch correctly. You can either try to restart flanneld.exe or you can copy the files over manually from `/run/flannel/subnet.env` on the Kubernetes master to` C:\run\flannel\subnet.env` on the Windows worker node and modify the `FLANNEL_SUBNET` row to a different number. For example, if node subnet 10.244.4.1/24 is desired:
+ これは、Flannelが正しく起動しなかったことを示しています。 flanneld.exeの再起動を試みるか、Kubernetesマスターの`/run/flannel/subnet.env`からWindowsワーカーノードの`C:\run\flannel\subnet.env`に手動でファイルをコピーすることができます。「FLANNEL_SUBNET」行を別の番号に変更します。たとえば、ノードサブネット10.244.4.1/24が必要な場合は以下となります。:
```env
FLANNEL_NETWORK=10.244.0.0/16
@@ -480,77 +497,91 @@ Your main source of help for troubleshooting your Kubernetes cluster should star
FLANNEL_IPMASQ=true
```
-1. My Windows node cannot access my services using the service IP
+1. WindowsノードがService IPを使用してServiceにアクセスできない
- This is a known limitation of the current networking stack on Windows. Windows Pods are able to access the service IP however.
+ これは、Windows上の現在のネットワークスタックの既知の制限です。ただし、Windows PodはService IPにアクセスできます。
-1. No network adapter is found when starting kubelet
+1. kubeletの起動時にネットワークアダプターが見つかりません
- The Windows networking stack needs a virtual adapter for Kubernetes networking to work. If the following commands return no results (in an admin shell), virtual network creation — a necessary prerequisite for Kubelet to work — has failed:
+ WindowsネットワーキングスタックがKubernetesネットワーキングを動かすには、仮想アダプターが必要です。次のコマンドを実行しても結果が返されない場合（管理シェルで）、仮想ネットワークの作成（Kubeletが機能するために必要な前提条件）に失敗したことになります。:
```powershell
Get-HnsNetwork | ? Name -ieq "cbr0"
Get-NetAdapter | ? Name -Like "vEthernet (Ethernet*"
```
- Often it is worthwhile to modify the [InterfaceName](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/start.ps1#L6) parameter of the start.ps1 script, in cases where the host's network adapter isn't "Ethernet". Otherwise, consult the output of the `start-kubelet.ps1` script to see if there are errors during virtual network creation.
+ ホストのネットワークアダプターが「イーサネット」ではない場合、多くの場合、start.ps1スクリプトの[InterfaceName](https://github.com/microsoft/SDN/blob/master/Kubernetes/flannel/start.ps1#L6)パラメーターを修正する価値があります。そうでない場合は`start-kubelet.ps1`スクリプトの出力結果を調べて、仮想ネットワークの作成中にエラーがないか確認します。
-1. My Pods are stuck at "Container Creating" or restarting over and over
+1. Podが「Container Creating」と表示されたまま動かなくなったり、何度も再起動を繰り返します
- Check that your pause image is compatible with your OS version. The [instructions](https://docs.microsoft.com/en-us/virtualization/windowscontainers/kubernetes/deploying-resources) assume that both the OS and the containers are version 1803. If you have a later version of Windows, such as an Insider build, you need to adjust the images accordingly. Please refer to the Microsoft's [Docker repository](https://hub.docker.com/u/microsoft/) for images. Regardless, both the pause image Dockerfile and the sample service expect the image to be tagged as :latest.
+ PauseイメージがOSバージョンと互換性があることを確認してください。[説明](https://docs.microsoft.com/en-us/virtualization/windowscontainers/kubernetes/deploying-resources)では、OSとコンテナの両方がバージョン1803であると想定しています。それ以降のバージョンのWindowsを使用している場合は、Insiderビルドなどでは、それに応じてイメージを調整する必要があります。イメージについては、Microsoftの[Dockerレジストリ](https://hub.docker.com/u/microsoft/)を参照してください。いずれにしても、PauseイメージのDockerfileとサンプルサービスの両方で、イメージに:latestのタグが付けられていると想定しています。
- Starting with Kubernetes v1.14, Microsoft releases the pause infrastructure container at `mcr.microsoft.com/k8s/core/pause:1.2.0`. For more information search for "pause" in the [Guide for adding Windows Nodes in Kubernetes](../user-guide-windows-nodes).
+ Kubernetes v1.14以降、MicrosoftはPauseインフラストラクチャコンテナを`mcr.microsoft.com/k8s/core/pause:1.2.0`でリリースしています。詳細については、[KubernetesにWindowsノードを追加するためのガイド](../user-guide-windows-nodes)で「Pause」を検索してください。
-1. DNS resolution is not properly working
+1. DNS名前解決が正しく機能していない
- Check the DNS limitations for Windows in this [section](#dns-limitations).
+ この[セクション](#dns-limitations)でDNSの制限を確認してください。
-1. `kubectl port-forward` fails with "unable to do port forwarding: wincat not found"
+1. `kubectl port-forward`が「ポート転送を実行できません:wincatが見つかりません」で失敗します
- This was implemented in Kubernetes 1.15, and the pause infrastructure container `mcr.microsoft.com/k8s/core/pause:1.2.0`. Be sure to use these versions or newer ones.
- If you would like to build your own pause infrastructure container, be sure to include [wincat](https://github.com/kubernetes-sigs/sig-windows-tools/tree/master/cmd/wincat)
+ これはKubernetes 1.15、およびPauseインフラストラクチャコンテナ`mcr.microsoft.com/k8s/core/pause:1.2.0`で実装されました。必ずこれらのバージョン以降を使用してください。
+ 独自のPauseインフラストラクチャコンテナを構築する場合は、必ず[wincat](https://github.com/kubernetes-sigs/sig-windows-tools/tree/master/cmd/wincat)を含めてください。
-### Further investigation
+1. Windows Serverノードがプロキシの背後にあるため、Kubernetesのインストールが失敗します
-If these steps don't resolve your problem, you can get help running Windows containers on Windows nodes in Kubernetes through:
+ プロキシの背後にある場合は、次のPowerShell環境変数を定義する必要があります。:
+ ```PowerShell
+ [Environment]::SetEnvironmentVariable("HTTP_PROXY", "http://proxy.example.com:80/", [EnvironmentVariableTarget]::Machine)
+ [Environment]::SetEnvironmentVariable("HTTPS_PROXY", "http://proxy.example.com:443/", [EnvironmentVariableTarget]::Machine)
+ ```
-* StackOverflow [Windows Server Container](https://stackoverflow.com/questions/tagged/windows-server-container) topic
-* Kubernetes Official Forum [discuss.kubernetes.io](https://discuss.kubernetes.io/)
+1. `pause`コンテナとは何ですか
+
+ Kubernetes Podでは、インフラストラクチャまたは「pause」コンテナが最初に作成され、コンテナエンドポイントをホストします。インフラストラクチャやワーカーコンテナなど、同じPodに属するコンテナは、共通のネットワークネームスペースとエンドポイント（同じIPとポートスペース）を共有します。Pauseコンテナは、ネットワーク構成を失うことなくクラッシュまたは再起動するワーカーコンテナに対応するために必要です。
+
+ 「pause」（インフラストラクチャ）イメージは、Microsoft Container Registry（MCR）でホストされています。`docker pull mcr.microsoft.com/k8s/core/pause:1.2.0`を使用してアクセスできます。詳細については、[DOCKERFILE](https://github.com/kubernetes-sigs/sig-windows-tools/tree/master/cmd/wincat)をご覧ください。
+
+### さらなる調査
+
+これらの手順で問題が解決しない場合は、次の方法で、KubernetesのWindowsノードでWindowsコンテナを実行する際のヘルプを利用できます。:
+
+* StackOverflow [Windows Server Container](https://stackoverflow.com/questions/tagged/windows-server-container)トピック
+* Kubernetesオフィシャルフォーラム [discuss.kubernetes.io](https://discuss.kubernetes.io/)
* Kubernetes Slack [#SIG-Windows Channel](https://kubernetes.slack.com/messages/sig-windows)
-## Reporting Issues and Feature Requests
+## IssueとFeatureリクエストの報告
-If you have what looks like a bug, or you would like to make a feature request, please use the [GitHub issue tracking system](https://github.com/kubernetes/kubernetes/issues). You can open issues on [GitHub](https://github.com/kubernetes/kubernetes/issues/new/choose) and assign them to SIG-Windows. You should first search the list of issues in case it was reported previously and comment with your experience on the issue and add additional logs. SIG-Windows Slack is also a great avenue to get some initial support and troubleshooting ideas prior to creating a ticket.
+バグのようなものがある場合、またはFeatureリクエストを行う場合は、[GitHubのIssueシステム](https://github.com/kubernetes/kubernetes/issues)を使用してください。[GitHub](https://github.com/kubernetes/kubernetes/issues/new/choose)でIssueを開いて、SIG-Windowsに割り当てることができます。以前に報告された場合は、まずIssueリストを検索し、Issueについての経験をコメントして、追加のログを加える必要があります。SIG-Windows Slackは、チケットを作成する前に、初期サポートとトラブルシューティングのアイデアを得るための素晴らしい手段でもあります。
-If filing a bug, please include detailed information about how to reproduce the problem, such as:
+バグを報告する場合は、問題の再現方法に関する次のような詳細情報を含めてください。:
-* Kubernetes version: kubectl version
-* Environment details: Cloud provider, OS distro, networking choice and configuration, and Docker version
-* Detailed steps to reproduce the problem
-* [Relevant logs](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs)
-* Tag the issue sig/windows by commenting on the issue with `/sig windows` to bring it to a SIG-Windows member's attention
+* Kubernetesのバージョン: kubectlのバージョン
+* 環境の詳細: クラウドプロバイダー、OSのディストリビューション、選択したネットワーキングと構成、およびDockerのバージョン
+* 問題を再現するための詳細な手順
+* [関連するログ](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs)
+* `/sig windows`でIssueにコメントして、Issueにsig/windowsのタグを付けて、SIG-Windowsメンバーが気付くようにします
## {{% heading "whatsnext" %}}
-We have a lot of features in our roadmap. An abbreviated high level list is included below, but we encourage you to view our [roadmap project](https://github.com/orgs/kubernetes/projects/8) and help us make Windows support better by [contributing](https://github.com/kubernetes/community/blob/master/sig-windows/).
+ロードマップには多くの機能があります。高レベルの簡略リストを以下に示しますが、[ロードマッププロジェクト](https://github.com/orgs/kubernetes/projects/8)を見て、[貢献すること](https://github.com/kubernetes/community/blob/master/sig-windows/)によってWindowsサポートを改善することをお勧めします。
### CRI-ContainerD
-{{< glossary_tooltip term_id="containerd" >}} is another OCI-compliant runtime that recently graduated as a {{< glossary_tooltip text="CNCF" term_id="cncf" >}} project. It's currently tested on Linux, but 1.3 will bring support for Windows and Hyper-V. [[reference](https://blog.docker.com/2019/02/containerd-graduates-within-the-cncf/)]
+{{< glossary_tooltip term_id="containerd" >}}は、最近{{< glossary_tooltip text="CNCF" term_id="cncf" >}}プロジェクトとして卒業した、もう1つのOCI準拠ランタイムです。現在Linuxでテストされていますが、1.3はWindowsとHyper-Vをサポートします。[[リファレンス](https://blog.docker.com/2019/02/containerd-graduates-within-the-cncf/)]
-The CRI-ContainerD interface will be able to manage sandboxes based on Hyper-V. This provides a foundation where RuntimeClass could be implemented for new use cases including:
+CRI-ContainerDインターフェイスは、Hyper-Vに基づいてサンドボックスを管理できるようになります。これにより、RuntimeClassを次のような新しいユースケースに実装できる基盤が提供されます:
-* Hypervisor-based isolation between pods for additional security
-* Backwards compatibility allowing a node to run a newer Windows Server version without requiring containers to be rebuilt
-* Specific CPU/NUMA settings for a pod
-* Memory isolation and reservations
+* Pod間のハイパーバイザーベースの分離により、セキュリティを強化
+* 下位互換性により、コンテナの再構築を必要とせずにノードで新しいWindows Serverバージョンを実行
+* Podの特定のCPU/NUMA設定
+* メモリの分離と予約
-### Hyper-V isolation
+### Hyper-V分離
-The existing Hyper-V isolation support, an experimental feature as of v1.10, will be deprecated in the future in favor of the CRI-ContainerD and RuntimeClass features mentioned above. To use the current features and create a Hyper-V isolated container, the kubelet should be started with feature gates `HyperVContainer=true` and the Pod should include the annotation `experimental.windows.kubernetes.io/isolation-type=hyperv`. In the experiemental release, this feature is limited to 1 container per Pod.
+既存のHyper-V分離サポートは、v1.10の試験的な機能であり、上記のCRI-ContainerD機能とRuntimeClass機能を優先して将来廃止される予定です。現在の機能を使用してHyper-V分離コンテナを作成するには、kubeletのフィーチャーゲートを`HyperVContainer=true`で開始し、Podにアノテーション`experimental.windows.kubernetes.io/isolation-type=hyperv`を含める必要があります。実験的リリースでは、この機能はPodごとに1つのコンテナに制限されています。
```yaml
apiVersion: apps/v1
@@ -576,13 +607,11 @@ spec:
- containerPort: 80
```
-### Deployment with kubeadm and cluster API
-
-Kubeadm is becoming the de facto standard for users to deploy a Kubernetes cluster. Windows node support in kubeadm will come in a future release. We are also making investments in cluster API to ensure Windows nodes are properly provisioned.
-
-### A few other key features
-* Beta support for Group Managed Service Accounts
-* More CNIs
-* More Storage Plugins
+### kubeadmとクラスターAPIを使用したデプロイ
+Kubeadmは、ユーザーがKubernetesクラスターをデプロイするための事実上の標準になりつつあります。kubeadmのWindowsノードのサポートは、将来のリリースで提供予定です。Windowsノードが適切にプロビジョニングされるように、クラスターAPIにも投資しています。
+### その他の主な機能
+* グループ管理サービスアカウントのベータサポート
+* その他のCNI
+* その他のストレージプラグイン
diff --git a/content/ja/docs/setup/production-environment/windows/kubecluster.ps1-install.gif b/content/ja/docs/setup/production-environment/windows/kubecluster.ps1-install.gif
new file mode 100644
index 0000000000..e3d94b9b54
Binary files /dev/null and b/content/ja/docs/setup/production-environment/windows/kubecluster.ps1-install.gif differ
diff --git a/content/ja/docs/setup/production-environment/windows/kubecluster.ps1-join.gif b/content/ja/docs/setup/production-environment/windows/kubecluster.ps1-join.gif
new file mode 100644
index 0000000000..828417d685
Binary files /dev/null and b/content/ja/docs/setup/production-environment/windows/kubecluster.ps1-join.gif differ
diff --git a/content/ja/docs/setup/production-environment/windows/kubecluster.ps1-reset.gif b/content/ja/docs/setup/production-environment/windows/kubecluster.ps1-reset.gif
new file mode 100644
index 0000000000..e71d40d6df
Binary files /dev/null and b/content/ja/docs/setup/production-environment/windows/kubecluster.ps1-reset.gif differ
diff --git a/content/ja/docs/setup/production-environment/windows/user-guide-windows-containers.md b/content/ja/docs/setup/production-environment/windows/user-guide-windows-containers.md
index 24d61e8bbd..ee1ed7b9f1 100644
--- a/content/ja/docs/setup/production-environment/windows/user-guide-windows-containers.md
+++ b/content/ja/docs/setup/production-environment/windows/user-guide-windows-containers.md
@@ -27,44 +27,47 @@ Windows applications constitute a large portion of the services and applications
To deploy a Windows container on Kubernetes, you must first create an example application. The example YAML file below creates a simple webserver application. Create a service spec named `win-webserver.yaml` with the contents below:
```yaml
- apiVersion: v1
- kind: Service
- metadata:
- name: win-webserver
- labels:
- app: win-webserver
- spec:
- ports:
- # the port that this service should serve on
- - port: 80
- targetPort: 80
- selector:
- app: win-webserver
- type: NodePort
- ---
- apiVersion: extensions/v1beta1
- kind: Deployment
+apiVersion: v1
+kind: Service
+metadata:
+ name: win-webserver
+ labels:
+ app: win-webserver
+spec:
+ ports:
+ # the port that this service should serve on
+ - port: 80
+ targetPort: 80
+ selector:
+ app: win-webserver
+ type: NodePort
+---
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+ labels:
+ app: win-webserver
+ name: win-webserver
+spec:
+ replicas: 2
+ selector:
+ matchLabels:
+ app: win-webserver
+ template:
metadata:
labels:
app: win-webserver
name: win-webserver
spec:
- replicas: 2
- template:
- metadata:
- labels:
- app: win-webserver
- name: win-webserver
- spec:
- containers:
- - name: windowswebserver
- image: mcr.microsoft.com/windows/servercore:ltsc2019
- command:
+ containers:
+ - name: windowswebserver
+ image: mcr.microsoft.com/windows/servercore:ltsc2019
+ command:
- powershell.exe
- -command
- - "<#code used from https://gist.github.com/wagnerandrade/5424431#> ; $$listener = New-Object System.Net.HttpListener ; $$listener.Prefixes.Add('http://*:80/') ; $$listener.Start() ; $$callerCounts = @{} ; Write-Host('Listening at http://*:80/') ; while ($$listener.IsListening) { ;$$context = $$listener.GetContext() ;$$requestUrl = $$context.Request.Url ;$$clientIP = $$context.Request.RemoteEndPoint.Address ;$$response = $$context.Response ;Write-Host '' ;Write-Host('> {0}' -f $$requestUrl) ; ;$$count = 1 ;$$k=$$callerCounts.Get_Item($$clientIP) ;if ($$k -ne $$null) { $$count += $$k } ;$$callerCounts.Set_Item($$clientIP, $$count) ;$$ip=(Get-NetAdapter | Get-NetIpAddress); $$header='Windows Container Web Server
' ;$$callerCountsString='' ;$$callerCounts.Keys | % { $$callerCountsString+='IP {0} callerCount {1} ' -f $$ip[1].IPAddress,$$callerCounts.Item($$_) } ;$$footer='' ;$$content='{0}{1}{2}' -f $$header,$$callerCountsString,$$footer ;Write-Output $$content ;$$buffer = [System.Text.Encoding]::UTF8.GetBytes($$content) ;$$response.ContentLength64 = $$buffer.Length ;$$response.OutputStream.Write($$buffer, 0, $$buffer.Length) ;$$response.Close() ;$$responseStatus = $$response.StatusCode ;Write-Host('< {0}' -f $$responseStatus) } ; "
- nodeSelector:
- kubernetes.io/os: windows
+ - "<#code used from https://gist.github.com/wagnerandrade/5424431#> ; $$listener = New-Object System.Net.HttpListener ; $$listener.Prefixes.Add('http://*:80/') ; $$listener.Start() ; $$callerCounts = @{} ; Write-Host('Listening at http://*:80/') ; while ($$listener.IsListening) { ;$$context = $$listener.GetContext() ;$$requestUrl = $$context.Request.Url ;$$clientIP = $$context.Request.RemoteEndPoint.Address ;$$response = $$context.Response ;Write-Host '' ;Write-Host('> {0}' -f $$requestUrl) ; ;$$count = 1 ;$$k=$$callerCounts.Get_Item($$clientIP) ;if ($$k -ne $$null) { $$count = $$k } ;$$callerCounts.Set_Item($$clientIP, $$count) ;$$ip=(Get-NetAdapter | Get-NetIpAddress); $$header='
Windows Container Web Server
' ;$$callerCountsString='' ;$$callerCounts.Keys | % { $$callerCountsString='IP {0} callerCount {1} ' -f $$ip[1].IPAddress,$$callerCounts.Item($$_) } ;$$footer='' ;$$content='{0}{1}{2}' -f $$header,$$callerCountsString,$$footer ;Write-Output $$content ;$$buffer = [System.Text.Encoding]::UTF8.GetBytes($$content) ;$$response.ContentLength64 = $$buffer.Length ;$$response.OutputStream.Write($$buffer, 0, $$buffer.Length) ;$$response.Close() ;$$responseStatus = $$response.StatusCode ;Write-Host('< {0}' -f $$responseStatus) } ; "
+ nodeSelector:
+ kubernetes.io/os: windows
```
{{< note >}}
@@ -101,6 +104,18 @@ Port mapping is also supported, but for simplicity in this example the container
Windows container hosts are not able to access the IP of services scheduled on them due to current platform limitations of the Windows networking stack. Only Windows pods are able to access service IPs.
{{< /note >}}
+## Observability
+
+### Capturing logs from workloads
+
+Logs are an important element of observability; they enable users to gain insights into the operational aspect of workloads and are a key ingredient to troubleshooting issues. Because Windows containers and workloads inside Windows containers behave differently from Linux containers, users had a hard time collecting logs, limiting operational visibility. Windows workloads for example are usually configured to log to ETW (Event Tracing for Windows) or push entries to the application event log. [LogMonitor](https://github.com/microsoft/windows-container-tools/tree/master/LogMonitor), an open source tool by Microsoft, is the recommended way to monitor configured log sources inside a Windows container. LogMonitor supports monitoring event logs, ETW providers, and custom application logs, piping them to STDOUT for consumption by `kubectl logs `.
+
+Follow the instructions in the LogMonitor GitHub page to copy its binaries and configuration files to all your containers and add the necessary entrypoints for LogMonitor to push your logs to STDOUT.
+
+## Using configurable Container usernames
+
+Starting with Kubernetes v1.16, Windows containers can be configured to run their entrypoints and processes with different usernames than the image defaults. The way this is achieved is a bit different from the way it is done for Linux containers. Learn more about it [here](/docs/tasks/configure-pod-container/configure-runasusername/).
+
## Managing Workload Identity with Group Managed Service Accounts
Starting with Kubernetes v1.14, Windows container workloads can be configured to use Group Managed Service Accounts (GMSA). Group Managed Service Accounts are a specific type of Active Directory account that provides automatic password management, simplified service principal name (SPN) management, and the ability to delegate the management to other administrators across multiple servers. Containers configured with a GMSA can access external Active Directory Domain resources while carrying the identity configured with the GMSA. Learn more about configuring and using GMSA for Windows containers [here](/docs/tasks/configure-pod-container/configure-gmsa/).
@@ -116,22 +131,114 @@ Users can ensure Windows containers can be scheduled on the appropriate host usi
* kubernetes.io/os = [windows|linux]
* kubernetes.io/arch = [amd64|arm64|...]
-If a Pod specification does not specify a nodeSelector like `"beta.kubernetes.io/os": windows`, it is possible the Pod can be scheduled on any host, Windows or Linux. This can be problematic since a Windows container can only run on Windows and a Linux container can only run on Linux. The best practice is to use a nodeSelector.
+If a Pod specification does not specify a nodeSelector like `"kubernetes.io/os": windows`, it is possible the Pod can be scheduled on any host, Windows or Linux. This can be problematic since a Windows container can only run on Windows and a Linux container can only run on Linux. The best practice is to use a nodeSelector.
However, we understand that in many cases users have a pre-existing large number of deployments for Linux containers, as well as an ecosystem of off-the-shelf configurations, such as community Helm charts, and programmatic Pod generation cases, such as with Operators. In those situations, you may be hesitant to make the configuration change to add nodeSelectors. The alternative is to use Taints. Because the kubelet can set Taints during registration, it could easily be modified to automatically add a taint when running on Windows only.
-For example: `--register-with-taints='os=Win1809:NoSchedule'`
+For example: `--register-with-taints='os=windows:NoSchedule'`
By adding a taint to all Windows nodes, nothing will be scheduled on them (that includes existing Linux Pods). In order for a Windows Pod to be scheduled on a Windows node, it would need both the nodeSelector to choose Windows, and the appropriate matching toleration.
```yaml
nodeSelector:
- "beta.kubernetes.io/os": windows
+ kubernetes.io/os: windows
+ node.kubernetes.io/windows-build: '10.0.17763'
tolerations:
- key: "os"
operator: "Equal"
- value: "Win1809"
+ value: "windows"
effect: "NoSchedule"
```
+### Handling multiple Windows versions in the same cluster
+The Windows Server version used by each pod must match that of the node. If you want to use multiple Windows
+Server versions in the same cluster, then you should set additional node labels and nodeSelectors.
+
+Kubernetes 1.17 automatically adds a new label `node.kubernetes.io/windows-build` to simplify this. If you're running an older version, then it's recommended to add this label manually to Windows nodes.
+
+This label reflects the Windows major, minor, and build number that need to match for compatibility. Here are values used today for each Windows Server version.
+
+| Product Name | Build Number(s) |
+|--------------------------------------|------------------------|
+| Windows Server 2019 | 10.0.17763 |
+| Windows Server version 1809 | 10.0.17763 |
+| Windows Server version 1903 | 10.0.18362 |
+
+
+### Simplifying with RuntimeClass
+
+[RuntimeClass] can be used to simplify the process of using taints and tolerations. A cluster administrator can create a `RuntimeClass` object which is used to encapsulate these taints and tolerations.
+
+
+1. Save this file to `runtimeClasses.yml`. It includes the appropriate `nodeSelector` for the Windows OS, architecture, and version.
+
+```yaml
+apiVersion: node.k8s.io/v1beta1
+kind: RuntimeClass
+metadata:
+ name: windows-2019
+handler: 'docker'
+scheduling:
+ nodeSelector:
+ kubernetes.io/os: 'windows'
+ kubernetes.io/arch: 'amd64'
+ node.kubernetes.io/windows-build: '10.0.17763'
+ tolerations:
+ - effect: NoSchedule
+ key: os
+ operator: Equal
+ value: "windows"
+```
+
+1. Run `kubectl create -f runtimeClasses.yml` using as a cluster administrator
+1. Add `runtimeClassName: windows-2019` as appropriate to Pod specs
+
+For example:
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+ name: iis-2019
+ labels:
+ app: iis-2019
+spec:
+ replicas: 1
+ template:
+ metadata:
+ name: iis-2019
+ labels:
+ app: iis-2019
+ spec:
+ runtimeClassName: windows-2019
+ containers:
+ - name: iis
+ image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
+ resources:
+ limits:
+ cpu: 1
+ memory: 800Mi
+ requests:
+ cpu: .1
+ memory: 300Mi
+ ports:
+ - containerPort: 80
+ selector:
+ matchLabels:
+ app: iis-2019
+---
+apiVersion: v1
+kind: Service
+metadata:
+ name: iis
+spec:
+ type: LoadBalancer
+ ports:
+ - protocol: TCP
+ port: 80
+ selector:
+ app: iis-2019
+```
+
+[RuntimeClass]: https://kubernetes.io/docs/concepts/containers/runtime-class/
\ No newline at end of file
diff --git a/content/ja/docs/setup/production-environment/windows/user-guide-windows-nodes.md b/content/ja/docs/setup/production-environment/windows/user-guide-windows-nodes.md
index 29035e15d9..6edce770c1 100644
--- a/content/ja/docs/setup/production-environment/windows/user-guide-windows-nodes.md
+++ b/content/ja/docs/setup/production-environment/windows/user-guide-windows-nodes.md
@@ -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 -NetworkMode overlay -ClusterCIDR -ServiceCIDR -KubeDnsServiceIP -LogDir
+cd c:\k
+.\start.ps1 -ManagementIP `
+ -NetworkMode overlay `
+ -ClusterCIDR `
+ -ServiceCIDR `
+ -KubeDnsServiceIP `
+ -LogDir
```
| 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.
-
diff --git a/content/ja/docs/setup/production-environment/windows/windows-docker-error.png b/content/ja/docs/setup/production-environment/windows/windows-docker-error.png
deleted file mode 100644
index d00528c0d4..0000000000
Binary files a/content/ja/docs/setup/production-environment/windows/windows-docker-error.png and /dev/null differ
diff --git a/content/ja/docs/setup/release/_index.md b/content/ja/docs/setup/release/_index.md
index e930b48a08..8c812f72de 100755
--- a/content/ja/docs/setup/release/_index.md
+++ b/content/ja/docs/setup/release/_index.md
@@ -1,4 +1,4 @@
---
-title: "リリースノート及びバージョンスキュー"
+title: "リリースノートおよびバージョンスキュー"
weight: 10
---
diff --git a/content/ja/docs/setup/release/building-from-source.md b/content/ja/docs/setup/release/building-from-source.md
deleted file mode 100644
index 21f056ce39..0000000000
--- a/content/ja/docs/setup/release/building-from-source.md
+++ /dev/null
@@ -1,30 +0,0 @@
----
-title: リリースのビルド
-content_type: concept
-card:
- name: download
- weight: 20
- title: リリースのビルド
----
-
-ソースコードからリリースをビルドすることもできますし、既にビルドされたリリースをダウンロードすることも可能です。Kubernetesを開発する予定が無いのであれば、[リリースノート](/docs/setup/release/notes/)内にて既にビルドされたバージョンを使用することを推奨します。
-
-Kubernetes のソースコードは[kubernetes/kubernetes](https://github.com/kubernetes/kubernetes)のリポジトリからダウンロードすることが可能です。
-
-
-
-## ソースからのビルド
-
-単にソースからリリースをビルドするだけであれば、完全なGOの環境を準備する必要はなく、全てのビルドはDockerコンテナの中で行われます。
-
-リリースをビルドすることは簡単です。
-
-```shell
-git clone https://github.com/kubernetes/kubernetes.git
-cd kubernetes
-make release
-```
-
-リリース手段の詳細な情報はkubernetes/kubernetes内の[`build`](http://releases.k8s.io/{{< param "githubbranch" >}}/build/)ディレクトリを参照して下さい。
-
-
diff --git a/content/ja/docs/setup/release/version-skew-policy.md b/content/ja/docs/setup/release/version-skew-policy.md
index 19200d80a6..5c1a18b8ee 100644
--- a/content/ja/docs/setup/release/version-skew-policy.md
+++ b/content/ja/docs/setup/release/version-skew-policy.md
@@ -5,7 +5,7 @@ weight: 30
---
-このドキュメントでは、さまざまなKubernetesコンポーネント間でサポートされる最大のバージョンの差異（バージョンスキュー）について説明します。特定のクラスターデプロイツールは、バージョンの差異に追加の制限を加える場合があります。
+このドキュメントでは、さまざまなKubernetesコンポーネント間でサポートされる最大のバージョンの差異(バージョンスキュー)について説明します。特定のクラスターデプロイツールは、バージョンの差異に追加の制限を加える場合があります。
@@ -16,9 +16,10 @@ Kubernetesのバージョンは**x.y.z**の形式で表現され、**x**はメ
Kubernetesプロジェクトでは、最新の3つのマイナーリリースについてリリースブランチを管理しています。
-セキュリティフィックスを含む適用可能な修正は、重大度や実行可能性によってはこれら3つのリリースブランチにバックポートされることもあります。パッチリリースは、[定期的](https://git.k8s.io/sig-release/releases/patch-releases.md#cadence)または必要に応じてこれらのブランチから分岐されます。[リリースマネージャー](https://git.k8s.io/sig-release/release-managers.md)グループがこれを決定しています。
+セキュリティフィックスを含む適用可能な修正は、重大度や実行可能性によってはこれら3つのリリースブランチにバックポートされることもあります。パッチリリースは、定期的または必要に応じてこれらのブランチから分岐されます。[パッチリリースチーム](https://github.com/kubernetes/sig-release/blob/master/release-engineering/role-handbooks/patch-release-team.md#release-timing)がこれを決定しています。パッチリリースチームは[リリースマネージャー](https://github.com/kubernetes/sig-release/blob/master/release-managers.md)の一部です。
+詳細は、[Kubernetesパッチリリース](https://github.com/kubernetes/sig-release/blob/master/releases/patch-releases.md)ページを参照してください。
-詳細は、Kubernetes[パッチリリース](https://git.k8s.io/sig-release/releases/patch-releases.md)ページを参照してください。
+マイナーリリースは約3ヶ月ごとに行われるため、マイナーリリースのブランチはそれぞれ約9ヶ月保守されます。
## サポートされるバージョンの差異
@@ -51,7 +52,7 @@ HAクラスター内の`kube-apiserver`間にバージョンの差異がある
### kube-controller-manager、kube-scheduler、およびcloud-controller-manager
-`kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`は、通信する`kube-apiserver`インスタンスよりも新しいバージョンであってはなりません。`kube-apiserver`のマイナーバージョンと一致することが期待されますが、1つ古いマイナーバージョンでも可能です（ライブアップグレードを可能にするため）。
+`kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`は、通信する`kube-apiserver`インスタンスよりも新しいバージョンであってはなりません。`kube-apiserver`のマイナーバージョンと一致することが期待されますが、1つ古いマイナーバージョンでも可能です(ライブアップグレードを可能にするため)。
例:
@@ -59,17 +60,17 @@ HAクラスター内の`kube-apiserver`間にバージョンの差異がある
* `kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`は**1.13**および**1.12**がサポートされます
{{< note >}}
-HAクラスター内の`kube-apiserver`間にバージョンの差異があり、これらのコンポーネントがクラスター内のいずれかの`kube-apiserver`と通信する場合（たとえばロードバランサーを経由して）、コンポーネントの有効なバージョンは少なくなります。
+HAクラスター内の`kube-apiserver`間にバージョンの差異があり、これらのコンポーネントがクラスター内のいずれかの`kube-apiserver`と通信する場合(たとえばロードバランサーを経由して)、コンポーネントの有効なバージョンは少なくなります。
{{< /note >}}
例:
* `kube-apiserver`インスタンスが**1.13**および**1.12**であるとします
-* いずれかの`kube-apiserver`インスタンスへ配信するロードバランサーと通信する`kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`は**1.12**がサポートされます（**1.13**はバージョン**1.12**の`kube-apiserver`よりも新しくなるためサポートされません）
+* いずれかの`kube-apiserver`インスタンスへ配信するロードバランサーと通信する`kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`は**1.12**がサポートされます(**1.13**はバージョン**1.12**の`kube-apiserver`よりも新しくなるためサポートされません)
### kubectl
-`kubectl`は`kube-apiserver`の1つ以内のバージョン（古い、または新しいもの）をサポートします。
+`kubectl`は`kube-apiserver`の1つ以内のバージョン(古い、または新しいもの)をサポートします。
例:
@@ -83,25 +84,25 @@ HAクラスター内の`kube-apiserver`間にバージョンの差異がある
例:
* `kube-apiserver`インスタンスが**1.13**および**1.12**であるとします
-* `kubectl`は**1.13**および**1.12**がサポートされます（ほかのバージョンでは、ある`kube-apiserver`コンポーネントからマイナーバージョンが2つ以上離れる可能性があります）
+* `kubectl`は**1.13**および**1.12**がサポートされます(ほかのバージョンでは、ある`kube-apiserver`コンポーネントからマイナーバージョンが2つ以上離れる可能性があります)
## サポートされるコンポーネントのアップグレード順序
-コンポーネント間でサポートされるバージョンの差異は、コンポーネントをアップグレードする順序に影響されます。このセクションでは、既存のクラスターをバージョン**1.n**から**1.(n+1)**へ移行するために、コンポーネントをアップグレードする順序を説明します。
+コンポーネント間でサポートされるバージョンの差異は、コンポーネントをアップグレードする順序に影響されます。このセクションでは、既存のクラスターをバージョン**1.n**から**1.(n+1)** へ移行するために、コンポーネントをアップグレードする順序を説明します。
### kube-apiserver
前提条件:
* シングルインスタンスのクラスターにおいて、既存の`kube-apiserver`インスタンスは**1.n**とします
-* HAクラスターにおいて、既存の`kube-apiserver`は**1.n**または**1.(n+1)**とします（最新と最古の間で、最大で1つのマイナーバージョンの差異となります）
-* サーバーと通信する`kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`はバージョン**1.n**とします（必ず既存のAPIサーバーのバージョンよりも新しいものでなく、かつ新しいAPIサーバーのバージョンの1つ以内のマイナーバージョンとなります）
-* すべてのノードの`kubelet`インスタンスはバージョン**1.n**または**1.(n-1)**とします（必ず既存のAPIサーバーよりも新しいバージョンでなく、かつ新しいAPIサーバーのバージョンの2つ以内のマイナーバージョンとなります）
+* HAクラスターにおいて、既存の`kube-apiserver`は**1.n**または**1.(n+1)** とします(最新と最古の間で、最大で1つのマイナーバージョンの差異となります)
+* サーバーと通信する`kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`はバージョン**1.n**とします(必ず既存のAPIサーバーのバージョンよりも新しいものでなく、かつ新しいAPIサーバーのバージョンの1つ以内のマイナーバージョンとなります)
+* すべてのノードの`kubelet`インスタンスはバージョン**1.n**または**1.(n-1)** とします(必ず既存のAPIサーバーよりも新しいバージョンでなく、かつ新しいAPIサーバーのバージョンの2つ以内のマイナーバージョンとなります)
* 登録されたAdmission webhookは、新しい`kube-apiserver`インスタンスが送信するこれらのデータを扱うことができます:
- * `ValidatingWebhookConfiguration`および`MutatingWebhookConfiguration`オブジェクトは、**1.(n+1)**で追加されたRESTリソースの新しいバージョンを含んで更新されます（または、v1.15から利用可能な[`matchPolicy: Equivalent`オプション](/docs/reference/access-authn-authz/extensible-admission-controllers/#matching-requests-matchpolicy)を使用してください）
- * Webhookは送信されたRESTリソースの新しいバージョン、および**1.(n+1)**のバージョンで追加された新しいフィールドを扱うことができます
+ * `ValidatingWebhookConfiguration`および`MutatingWebhookConfiguration`オブジェクトは、**1.(n+1)** で追加されたRESTリソースの新しいバージョンを含んで更新されます(または、v1.15から利用可能な[`matchPolicy: Equivalent`オプション](/docs/reference/access-authn-authz/extensible-admission-controllers/#matching-requests-matchpolicy)を使用してください)
+ * Webhookは送信されたRESTリソースの新しいバージョン、および**1.(n+1)** のバージョンで追加された新しいフィールドを扱うことができます
-`kube-apiserver`を**1.(n+1)**にアップグレードしてください。
+`kube-apiserver`を**1.(n+1)** にアップグレードしてください。
{{< note >}}
[非推奨API](/docs/reference/using-api/deprecation-policy/)および[APIの変更ガイドライン](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api_changes.md)のプロジェクトポリシーにおいては、シングルインスタンスの場合でも`kube-apiserver`のアップグレードの際にマイナーバージョンをスキップしてはなりません。
@@ -111,17 +112,17 @@ HAクラスター内の`kube-apiserver`間にバージョンの差異がある
前提条件:
-* これらのコンポーネントと通信する`kube-apiserver`インスタンスが**1.(n+1)**であること（これらのコントロールプレーンコンポーネントが、クラスター内の`kube-apiserver`インスタンスと通信できるHAクラスターでは、これらのコンポーネントをアップグレードする前にすべての`kube-apiserver`インスタンスをアップグレードしなければなりません）
+* これらのコンポーネントと通信する`kube-apiserver`インスタンスが**1.(n+1)** であること(これらのコントロールプレーンコンポーネントが、クラスター内の`kube-apiserver`インスタンスと通信できるHAクラスターでは、これらのコンポーネントをアップグレードする前にすべての`kube-apiserver`インスタンスをアップグレードしなければなりません)
-`kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`を**1.(n+1)**にアップグレードしてください。
+`kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`を**1.(n+1)** にアップグレードしてください。
### kubelet
前提条件:
-* `kubelet`と通信する`kube-apiserver`が**1.(n+1)**であること
+* `kubelet`と通信する`kube-apiserver`が**1.(n+1)** であること
-必要に応じて、`kubelet`インスタンスを**1.(n+1)**にアップグレードしてください（**1.n**や**1.(n-1)**のままにすることもできます）。
+必要に応じて、`kubelet`インスタンスを**1.(n+1)** にアップグレードしてください(**1.n**や**1.(n-1)** のままにすることもできます)。
{{< warning >}}
`kube-apiserver`と2つのマイナーバージョンの`kubelet`インスタンスを使用してクラスターを実行させることは推奨されません:
diff --git a/content/ja/docs/tasks/access-application-cluster/ingress-minikube.md b/content/ja/docs/tasks/access-application-cluster/ingress-minikube.md
new file mode 100644
index 0000000000..563ce2478e
--- /dev/null
+++ b/content/ja/docs/tasks/access-application-cluster/ingress-minikube.md
@@ -0,0 +1,305 @@
+---
+title: Minikube上でNGINX Ingressコントローラーを使用してIngressをセットアップする
+content_type: task
+weight: 100
+---
+
+
+
+[Ingress](/ja/docs/concepts/services-networking/ingress/)とは、クラスター内のServiceに外部からのアクセスを許可するルールを定義するAPIオブジェクトです。[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers/)はIngress内に設定されたルールを満たすように動作します。
+
+このページでは、簡単なIngressをセットアップして、HTTPのURIに応じてwebまたはweb2というServiceにリクエストをルーティングする方法を説明します。
+
+
+
+## {{% heading "prerequisites" %}}
+
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+
+
+
+
+## Minikubeクラスターを作成する
+
+1. **Launch Terminal**をクリックします。
+
+ {{< kat-button >}}
+
+1. (オプション) Minikubeをローカル環境にインストールした場合は、次のコマンドを実行します。
+
+ ```shell
+ minikube start
+ ```
+
+## Ingressコントローラーを有効化する
+
+1. NGINX Ingressコントローラーを有効にするために、次のコマンドを実行します。
+
+ ```shell
+ minikube addons enable ingress
+ ```
+
+1. NGINX Ingressコントローラーが起動したことを確認します。
+
+ ```shell
+ kubectl get pods -n kube-system
+ ```
+
+ {{< note >}}
+ このコマンドの実行には数分かかる場合があります。
+ {{< /note >}}
+
+ 出力は次のようになります。
+
+ ```shell
+ NAME READY STATUS RESTARTS AGE
+ default-http-backend-59868b7dd6-xb8tq 1/1 Running 0 1m
+ kube-addon-manager-minikube 1/1 Running 0 3m
+ kube-dns-6dcb57bcc8-n4xd4 3/3 Running 0 2m
+ kubernetes-dashboard-5498ccf677-b8p5h 1/1 Running 0 2m
+ nginx-ingress-controller-5984b97644-rnkrg 1/1 Running 0 1m
+ storage-provisioner 1/1 Running 0 2m
+ ```
+
+## Hello Worldアプリをデプロイする
+
+1. 次のコマンドを実行して、Deploymentを作成します。
+
+ ```shell
+ kubectl create deployment web --image=gcr.io/google-samples/hello-app:1.0
+ ```
+
+ 出力は次のようになります。
+
+ ```shell
+ deployment.apps/web created
+ ```
+
+1. Deploymentを公開します。
+
+ ```shell
+ kubectl expose deployment web --type=NodePort --port=8080
+ ```
+
+ 出力は次のようになります。
+
+ ```shell
+ service/web exposed
+ ```
+
+1. Serviceが作成され、NodePort上で利用できるようになったことを確認します。
+
+ ```shell
+ kubectl get service web
+ ```
+
+ 出力は次のようになります。
+
+ ```shell
+ NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
+ web NodePort 10.104.133.249 8080:31637/TCP 12m
+ ```
+
+1. NodePort経由でServiceを訪問します。
+
+ ```shell
+ minikube service web --url
+ ```
+
+ 出力は次のようになります。
+
+ ```shell
+ http://172.17.0.15:31637
+ ```
+
+ {{< note >}}
+ Katacoda環境の場合のみ: 上部のterminalパネルでプラスのアイコンをクリックして、**Select port to view on Host 1**(Host 1を表示するポートを選択)をクリックします。NodePort(上の例では`31637`)を入力して、**Display Port**(ポートを表示)をクリックしてください。
+ {{< /note >}}
+
+ 出力は次のようになります。
+
+ ```shell
+ Hello, world!
+ Version: 1.0.0
+ Hostname: web-55b8c6998d-8k564
+ ```
+
+ これで、MinikubeのIPアドレスとNodePort経由で、サンプルアプリにアクセスできるようになりました。次のステップでは、Ingressリソースを使用してアプリにアクセスできるように設定します。
+
+## Ingressリソースを作成する
+
+以下に示すファイルは、hello-world.info経由で送られたトラフィックをServiceに送信するIngressリソースです。
+
+1. 以下の内容で`example-ingress.yaml`を作成します。
+
+ ```yaml
+ apiVersion: networking.k8s.io/v1beta1
+ kind: Ingress
+ metadata:
+ name: example-ingress
+ annotations:
+ nginx.ingress.kubernetes.io/rewrite-target: /$1
+ spec:
+ rules:
+ - host: hello-world.info
+ http:
+ paths:
+ - path: /
+ backend:
+ serviceName: web
+ servicePort: 8080
+ ```
+
+1. 次のコマンドを実行して、Ingressリソースを作成します。
+
+ ```shell
+ kubectl apply -f example-ingress.yaml
+ ```
+
+ 出力は次のようになります。
+
+ ```shell
+ ingress.networking.k8s.io/example-ingress created
+ ```
+
+1. 次のコマンドで、IPアドレスが設定されていることを確認します。
+
+ ```shell
+ kubectl get ingress
+ ```
+
+ {{< note >}}
+ このコマンドの実行には数分かかる場合があります。
+ {{< /note >}}
+
+ ```shell
+ NAME HOSTS ADDRESS PORTS AGE
+ example-ingress hello-world.info 172.17.0.15 80 38s
+ ```
+
+1. 次の行を`/etc/hosts`ファイルの最後に書きます。
+
+ {{< note >}}
+ Minikubeをローカル環境で実行している場合、`minikube ip`コマンドを使用すると外部のIPが取得できます。Ingressのリスト内に表示されるIPアドレスは、内部のIPになるはずです。
+ {{< /note >}}
+
+ ```
+ 172.17.0.15 hello-world.info
+ ```
+
+ この設定により、リクエストがhello-world.infoからMinikubeに送信されるようになります。
+
+1. Ingressコントローラーがトラフィックを制御していることを確認します。
+
+ ```shell
+ curl hello-world.info
+ ```
+
+ 出力は次のようになります。
+
+ ```shell
+ Hello, world!
+ Version: 1.0.0
+ Hostname: web-55b8c6998d-8k564
+ ```
+
+ {{< note >}}
+ Minikubeをローカル環境で実行している場合、ブラウザからhello-world.infoにアクセスできます。
+ {{< /note >}}
+
+## 2番目のDeploymentを作成する
+
+1. 次のコマンドを実行して、v2のDeploymentを作成します。
+
+ ```shell
+ kubectl create deployment web2 --image=gcr.io/google-samples/hello-app:2.0
+ ```
+
+ 出力は次のようになります。
+
+ ```shell
+ deployment.apps/web2 created
+ ```
+
+1. Deploymentを公開します。
+
+ ```shell
+ kubectl expose deployment web2 --port=8080 --type=NodePort
+ ```
+
+ 出力は次のようになります。
+
+ ```shell
+ service/web2 exposed
+ ```
+
+## Ingressを編集する
+
+1. 既存の`example-ingress.yaml`を編集して、以下の行を追加します。
+
+ ```yaml
+ - path: /v2
+ backend:
+ serviceName: web2
+ servicePort: 8080
+ ```
+
+1. 次のコマンドで変更を適用します。
+
+ ```shell
+ kubectl apply -f example-ingress.yaml
+ ```
+
+ 出力は次のようになります。
+
+ ```shell
+ ingress.networking/example-ingress configured
+ ```
+
+## Ingressを試す
+
+1. Hello Worldアプリの1番目のバージョンにアクセスします。
+
+ ```shell
+ curl hello-world.info
+ ```
+
+ 出力は次のようになります。
+
+ ```shell
+ Hello, world!
+ Version: 1.0.0
+ Hostname: web-55b8c6998d-8k564
+ ```
+
+1. Hello Worldアプリの2番目のバージョンにアクセスします。
+
+ ```shell
+ curl hello-world.info/v2
+ ```
+
+ 出力は次のようになります。
+
+ ```shell
+ Hello, world!
+ Version: 2.0.0
+ Hostname: web2-75cd47646f-t8cjk
+ ```
+
+ {{< note >}}
+ Minikubeをローカル環境で実行している場合、ブラウザからhello-world.infoおよびhello-world.info/v2にアクセスできます。
+ {{< /note >}}
+
+
+
+
+## {{% heading "whatsnext" %}}
+
+* [Ingress](/ja/docs/concepts/services-networking/ingress/)についてさらに学ぶ。
+* [Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers/)についてさらに学ぶ。
+* [Service](/ja/docs/concepts/services-networking/service/)についてさらに学ぶ。
+
+
+
diff --git a/content/ja/docs/tasks/access-application-cluster/list-all-running-container-images.md b/content/ja/docs/tasks/access-application-cluster/list-all-running-container-images.md
new file mode 100644
index 0000000000..3d36d99539
--- /dev/null
+++ b/content/ja/docs/tasks/access-application-cluster/list-all-running-container-images.md
@@ -0,0 +1,112 @@
+---
+title: クラスターで実行されているすべてのコンテナイメージを一覧表示する
+content_type: task
+weight: 100
+---
+
+
+
+このページでは、kubectlを使用して、クラスターで実行されているPodのすべてのコンテナイメージを一覧表示する方法を説明します。
+
+
+
+## {{% heading "prerequisites" %}}
+
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+
+
+
+
+この演習では、kubectlを使用してクラスターで実行されているすべてのPodを取得し、出力をフォーマットしてそれぞれのコンテナの一覧を取得します。
+
+## すべての名前空間のコンテナイメージを一覧表示する {#list-all-container-images-in-all-namespaces}
+
+- `kubectl get pods --all-namespaces`を使用して、すべての名前空間のPodを取得します
+- `-o jsonpath={.. image}`を使用して、コンテナイメージ名のリストのみが含まれるように出力をフォーマットします。これは、返されたjsonの`image`フィールドを再帰的に解析します。
+ - jsonpathの使い方については、[jsonpathリファレンス](/docs/user-guide/jsonpath/)を参照してください。
+- `tr`、`sort`、`uniq`などの標準ツールを使用して出力をフォーマットします。
+ - `tr`を使用してスペースを改行に置換します。
+ - `sort`を使用して結果を並べ替えます。
+ - `uniq`を使用してイメージ数を集計します。
+
+```sh
+kubectl get pods --all-namespaces -o jsonpath="{..image}" |\
+tr -s '[[:space:]]' '\n' |\
+sort |\
+uniq -c
+```
+
+上記のコマンドは、返されるすべてのアイテムについて、`image`という名前のすべてのフィールドを再帰的に返します。
+
+別の方法として、Pod内のimageフィールドへの絶対パスを使用することができます。これにより、フィールド名が繰り返されている場合でも正しいフィールドが取得されます。多くのフィールドは与えられたアイテム内で`name`と呼ばれます:
+
+```sh
+kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}"
+```
+
+jsonpathは次のように解釈されます:
+
+- `.items[*]`: 各戻り値
+- `.spec`: 仕様の取得
+- `.containers[*]`: 各コンテナ
+- `.image`: イメージの取得
+
+{{< note >}}
+例えば`kubectl get pod nginx`のように名前を指定して単一のPodを取得する場合、アイテムのリストではなく単一のPodが返されるので、パスの`.items[*]`部分は省略してください。
+{{< /note >}}
+
+## Podごとにコンテナイメージを一覧表示する {#list-container-images-by-pod}
+
+`range`を使用して要素を個別に繰り返し処理することにより、フォーマットをさらに制御できます。
+
+```sh
+kubectl get pods --all-namespaces -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\
+sort
+```
+
+## Podのラベルを使用してコンテナイメージ一覧をフィルタリングする {#list-container-images-filtering-by-pod-namespace}
+
+特定のラベルに一致するPodのみを対象とするには、-lフラグを使用します。以下は、`app=nginx`に一致するラベルを持つPodのみに一致します。
+
+```sh
+kubectl get pods --all-namespaces -o=jsonpath="{..image}" -l app=nginx
+```
+
+## Podの名前空間でコンテナイメージ一覧をフィルタリングする {#list-container-images-filtering-by-pod-namespace}
+
+特定の名前空間のPodのみを対象とするには、namespaceフラグを使用します。以下は`kube-system`名前空間のPodのみに一致します。
+
+```sh
+kubectl get pods --namespace kube-system -o jsonpath="{..image}"
+```
+
+## jsonpathの代わりにgo-templateを使用してコンテナイメージを一覧表示する {#list-container-images-using-a-go-template-instead-of-jsonpath}
+
+jsonpathの代わりに、kubectlは[go-templates](https://golang.org/pkg/text/template/)を使用した出力のフォーマットをサポートしています:
+
+
+```sh
+kubectl get pods --all-namespaces -o go-template --template="{{range .items}}{{range .spec.containers}}{{.image}} {{end}}{{end}}"
+```
+
+
+
+
+
+
+
+
+
+## {{% heading "whatsnext" %}}
+
+
+### 参照
+
+* [jsonpath](/docs/user-guide/jsonpath/)参照ガイド
+* [Go template](https://golang.org/pkg/text/template/)参照ガイド
+
+
+
+
diff --git a/content/ja/docs/tasks/access-application-cluster/service-access-application-cluster.md b/content/ja/docs/tasks/access-application-cluster/service-access-application-cluster.md
index 8b0439ec3a..1fe8e47e7b 100644
--- a/content/ja/docs/tasks/access-application-cluster/service-access-application-cluster.md
+++ b/content/ja/docs/tasks/access-application-cluster/service-access-application-cluster.md
@@ -23,7 +23,7 @@ weight: 60
## {{% heading "objectives" %}}
-* 2つのHellow Worldアプリケーションを稼働させる。
+* 2つのHello Worldアプリケーションを稼働させる。
* Nodeのポートを公開するServiceオブジェクトを作成する。
* 稼働しているアプリケーションにアクセスするためにServiceオブジェクトを使用する。
diff --git a/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md
index 99585c4631..8087e5602e 100644
--- a/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md
+++ b/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md
@@ -92,12 +92,12 @@ Kubeconfigの認証方法は、外部IDプロバイダーやx509証明書ベー
例:
- ```conf
-release=1.0
-tier=frontend
-environment=pod
-track=stable
-```
+ ```conf
+ release=1.0
+ tier=frontend
+ environment=pod
+ track=stable
+ ```
- **Namespace**: Kubernetesは、同じ物理クラスターを基盤とする複数の仮想クラスターをサポートしています。これらの仮想クラスタは[名前空間](/docs/tasks/administer-cluster/namespaces/) と呼ばれます。これにより、リソースを論理的に名前のついたグループに分割することができます。
diff --git a/content/ja/docs/tasks/administer-cluster/coredns.md b/content/ja/docs/tasks/administer-cluster/coredns.md
new file mode 100644
index 0000000000..068832e852
--- /dev/null
+++ b/content/ja/docs/tasks/administer-cluster/coredns.md
@@ -0,0 +1,79 @@
+---
+title: サービスディスカバリーにCoreDNSを使用する
+min-kubernetes-server-version: v1.9
+content_type: task
+---
+
+
+このページでは、CoreDNSのアップグレードプロセスと、kube-dnsの代わりにCoreDNSをインストールする方法を説明します。
+
+
+## {{% heading "prerequisites" %}}
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+
+
+
+## CoreDNSについて {#about-coredns}
+
+[CoreDNS](https://coredns.io)は、KubernetesクラスターDNSとして稼働させることができる柔軟で拡張可能なDNSサーバーです。Kubernetesと同様に、CoreDNSプロジェクトは{{< glossary_tooltip text="CNCF" term_id="cncf" >}}によってホストされています。
+
+既存のデプロイでkube-dnsを置き換えるか、クラスターのデプロイとアップグレードを代行してくれるkubeadmのようなツールを使用することで、クラスターでkube-dnsの代わりにCoreDNSを使用することができます。
+
+
+## CoreDNSのインストール {#installing-coredns}
+
+kube-dnsの手動デプロイや置き換えについては、[CoreDNS GitHub project](https://github.com/coredns/deployment/tree/master/kubernetes)のドキュメントを参照してください。
+
+## CoreDNSへの移行 {#migrating-to-coredns}
+
+### kubeadmを使用した既存のクラスターのアップグレード {#upgrading-an-existing-cluster-with-kubeadm}
+
+Kubernetesバージョン1.10以降では、`kube-dns`を使用しているクラスターを`kubeadm`を使用してアップグレードするときに、CoreDNSに移行することもできます。この場合、`kubeadm`は、`kube-dns` ConfigMapをベースにしてCoreDNS設定("Corefile")を生成し、フェデレーション、スタブドメイン、および上流のネームサーバーの設定を保持します。
+
+kube-dnsからCoreDNSに移行する場合は、アップグレード時に必ず`CoreDNS`フィーチャーゲートを`true`に設定してください。たとえば、`v1.11.0`のアップグレードは次のようになります:
+```
+kubeadm upgrade apply v1.11.0 --feature-gates=CoreDNS=true
+```
+
+Kubernetesバージョン1.13以降では、`CoreDNS`フィーチャーゲートが削除され、CoreDNSがデフォルトで使用されます。アップグレードしたクラスターでkube-dnsを使用する場合は、[こちら](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase#cmd-phase-addon)のガイドに従ってください。
+
+1.11以前のバージョンでは、Corefileはアップグレード中に作成されたものによって**上書き**されます。**カスタマイズしている場合は、既存のConfigMapを保存する必要があります。** 新しいConfigMapが稼働したら、カスタマイズを再適用できます。
+
+Kubernetesバージョン1.11以降でCoreDNSを実行している場合、アップグレード中、既存のCorefileは保持されます。
+
+
+### kubeadmを使用してCoreDNSの代わりにkube-dnsをインストールする {#installing-kube-dns-instead-of-coredns-with-kubeadm}
+
+{{< note >}}
+Kubernetes 1.11では、CoreDNSは一般利用可能(GA)にアップグレードされ、デフォルトでインストールされます。
+{{< /note >}}
+
+1.13以前のバージョンにkube-dnsをインストールするには、`CoreDNS`フィーチャーゲートの値を`false`に設定します:
+
+```
+kubeadm init --feature-gates=CoreDNS=false
+```
+
+バージョン1.13以降の場合は、[こちら](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase#cmd-phase-addon)に記載されているガイドに従ってください。
+
+## CoreDNSのアップグレード {#upgrading-coredns}
+
+CoreDNSはv1.9以降のKubernetesで使用できます。Kubernetesに同梱されているCoreDNSのバージョンと、CoreDNSに加えられた変更は[こちら](https://github.com/coredns/deployment/blob/master/kubernetes/CoreDNS-k8s_version.md)で確認できます。
+
+CoreDNSだけをアップグレードしたい場合や、独自のカスタムイメージを使用したい場合は、CoreDNSを手動でアップグレードすることができます。スムーズなアップグレードのために役立つ[ガイドラインとウォークスルー](https://github.com/coredns/deployment/blob/master/kubernetes/Upgrading_CoreDNS.md)が用意されています。
+
+## CoreDNSのチューニング {#tuning-coredns}
+
+リソース使用率が問題になる場合は、CoreDNSの設定を調整すると役立つ場合があります。詳細は、[CoreDNSのスケーリングに関するドキュメント](https://github.com/coredns/deployment/blob/master/kubernetes/Scaling_CoreDNS.md)を参照してください。
+
+
+
+## {{% heading "whatsnext" %}}
+
+
+[CoreDNS](https://coredns.io)は、`Corefile`を変更することで、kube-dnsよりも多くのユースケースをサポートするように設定することができます。詳細は[CoreDNSサイト](https://coredns.io/2017/05/08/custom-dns-entries-for-kubernetes/)を参照してください。
+
+
+
diff --git a/content/ja/docs/tasks/administer-cluster/extended-resource-node.md b/content/ja/docs/tasks/administer-cluster/extended-resource-node.md
new file mode 100644
index 0000000000..59156efd89
--- /dev/null
+++ b/content/ja/docs/tasks/administer-cluster/extended-resource-node.md
@@ -0,0 +1,169 @@
+---
+title: 拡張リソースをNodeにアドバタイズする
+content_type: task
+---
+
+
+
+このページでは、Nodeに対して拡張リソースを指定する方法を説明します。拡張リソースを利用すると、Kubernetesにとって未知のノードレベルのリソースをクラスター管理者がアドバタイズできるようになります。
+
+## {{% heading "prerequisites" %}}
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+
+
+## Nodeの名前を取得する
+
+```shell
+kubectl get nodes
+```
+
+この練習で使いたいNodeを1つ選んでください。
+
+## Nodeの1つで新しい拡張リソースをアドバタイズする
+
+Node上の新しい拡張リソースをアドバタイズするには、HTTPのPATCHリクエストをKubernetes APIサーバーに送ります。たとえば、Nodeの1つに4つのドングルが接続されているとします。以下に、4つのドングルリソースをNodeにアドバタイズするPATCHリクエストの例を示します。
+
+```shell
+PATCH /api/v1/nodes/<選択したNodeの名前>/status HTTP/1.1
+Accept: application/json
+Content-Type: application/json-patch+json
+Host: k8s-master:8080
+
+[
+ {
+ "op": "add",
+ "path": "/status/capacity/example.com~1dongle",
+ "value": "4"
+ }
+]
+```
+
+Kubernetesは、ドングルとは何かも、ドングルが何に利用できるのかを知る必要もないことに注意してください。上のPATCHリクエストは、ただNodeが4つのドングルと呼ばれるものを持っているとKubernetesに教えているだけです。
+
+Kubernetes APIサーバーに簡単にリクエストを送れるように、プロキシーを実行します。
+
+```shell
+kubectl proxy
+```
+
+もう1つのコマンドウィンドウを開き、HTTPのPATCHリクエストを送ります。`<選択したNodeの名前>`の部分は、選択したNodeの名前に置き換えてください。
+
+```shell
+curl --header "Content-Type: application/json-patch+json" \
+--request PATCH \
+--data '[{"op": "add", "path": "/status/capacity/example.com~1dongle", "value": "4"}]' \
+http://localhost:8001/api/v1/nodes/<選択したNodeの名前>/status
+```
+
+{{< note >}}
+上のリクエストにある`~1`は、PATCHのパスにおける`/`という文字をエンコーディングしたものです。JSON-Patch内のoperationのpathはJSON-Pointerとして解釈されます。詳細については、[IETF RFC 6901](https://tools.ietf.org/html/rfc6901)のsection 3を読んでください。
+{{< /note >}}
+
+出力には、Nodeがキャパシティー4のdongleを持っていることが示されます。
+
+```
+"capacity": {
+ "cpu": "2",
+ "memory": "2049008Ki",
+ "example.com/dongle": "4",
+```
+
+Nodeの説明を確認します。
+
+```
+kubectl describe node <選択したNodeの名前>
+```
+
+出力には、再びdongleリソースが表示されます。
+
+```yaml
+Capacity:
+ cpu: 2
+ memory: 2049008Ki
+ example.com/dongle: 4
+```
+
+これで、アプリケーション開発者は特定の数のdongleをリクエストするPodを作成できるようになりました。詳しくは、[拡張リソースをコンテナに割り当てる](/docs/tasks/configure-pod-container/extended-resource/)を読んでください。
+
+## 議論
+
+拡張リソースは、メモリやCPUリソースと同様のものです。たとえば、Nodeが持っている特定の量のメモリやCPUがNode上で動作している他のすべてのコンポーネントと共有されるのと同様に、Nodeが搭載している特定の数のdongleが他のすべてのコンポーネントと共有されます。そして、アプリケーション開発者が特定の量のメモリとCPUをリクエストするPodを作成できるのと同様に、Nodeが搭載している特定の数のdongleをリクエストするPodが作成できます。
+
+拡張リソースはKubernetesには詳細を意図的に公開しないため、Kubernetesは拡張リソースの実体をまったく知りません。Kubernetesが知っているのは、Nodeが特定の数の拡張リソースを持っているということだけです。拡張リソースは整数値でアドバタイズしなければなりません。たとえば、Nodeは4つのdongleをアドバタイズできますが、4.5のdongleというのはアドバタイズできません。
+
+### Storageの例
+
+Nodeに800GiBの特殊なディスクストレージがあるとします。この特殊なストレージの名前、たとえばexample.com/special-storageという名前の拡張リソースが作れます。そして、そのなかの一定のサイズ、たとえば100GiBのチャンクをアドバタイズできます。この場合、Nodeはexample.com/special-storageという種類のキャパシティ8のリソースを持っているとアドバタイズします。
+
+```yaml
+Capacity:
+ ...
+ example.com/special-storage: 8
+```
+
+特殊なストレージに任意のサイズのリクエストを許可したい場合、特殊なストレージを1バイトのサイズのチャンクでアドバタイズできます。その場合、example.com/special-storageという種類の800Giのリソースとしてアドバタイズします。
+
+```yaml
+Capacity:
+ ...
+ example.com/special-storage: 800Gi
+```
+
+すると、コンテナは好きなバイト数の特殊なストレージを最大800Giまでリクエストできるようになります。
+
+## クリーンアップ
+
+以下に、dongleのアドバタイズをNodeから削除するPATCHリクエストを示します。
+
+```
+PATCH /api/v1/nodes/<選択したNodeの名前>/status HTTP/1.1
+Accept: application/json
+Content-Type: application/json-patch+json
+Host: k8s-master:8080
+
+[
+ {
+ "op": "remove",
+ "path": "/status/capacity/example.com~1dongle",
+ }
+]
+```
+
+Kubernetes APIサーバーに簡単にリクエストを送れるように、プロキシーを実行します。
+
+```shell
+kubectl proxy
+```
+
+もう1つのコマンドウィンドウで、HTTPのPATCHリクエストを送ります。`<選択したNodeの名前>`の部分は、選択したNodeの名前に置き換えてください。
+
+```shell
+curl --header "Content-Type: application/json-patch+json" \
+--request PATCH \
+--data '[{"op": "remove", "path": "/status/capacity/example.com~1dongle"}]' \
+http://localhost:8001/api/v1/nodes/<選択したNodeの名前>/status
+```
+
+dongleのアドバタイズが削除されたことを検証します。
+
+```
+kubectl describe node <選択したNodeの名前> | grep dongle
+```
+
+(出力には何も表示されないはずです)
+
+## {{% heading "whatsnext" %}}
+
+### アプリケーション開発者向け
+
+* [拡張リソースをコンテナに割り当てる](/ja/docs/tasks/configure-pod-container/extended-resource/)
+
+### クラスター管理者向け
+
+* [Namespaceに対してメモリの最小値と最大値の制約を設定する](/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)
+* [Namespaceに対してCPUの最小値と最大値の制約を設定する](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)
+
+
+
diff --git a/content/ja/docs/tasks/administer-cluster/running-cloud-controller.md b/content/ja/docs/tasks/administer-cluster/running-cloud-controller.md
index e98cee60d8..9a06821517 100644
--- a/content/ja/docs/tasks/administer-cluster/running-cloud-controller.md
+++ b/content/ja/docs/tasks/administer-cluster/running-cloud-controller.md
@@ -9,7 +9,7 @@ content_type: concept
Kubernetes v1.6では`cloud-controller-manager`という新しいバイナリが導入されました。`cloud-controller-manager`はクラウド固有の制御ループを組み込むデーモンです。これらのクラウド固有の制御ループはもともと`kube-controller-manager`にありました。クラウドプロバイダーはKubernetesプロジェクトとは異なるペースで開発およびリリースされるため、プロバイダー固有のコードを`cloud-controller-manager`バイナリに抽象化することでクラウドベンダーはKubernetesのコアのコードとは独立して開発が可能となりました。
-`cloud-controller-manager`は、[cloudprovider.Interface](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go)を満たす任意のクラウドプロバイダーと接続できます。下位互換性のためにKubernetesのコアプロジェクトで提供される[cloud-controller-manager](https://github.com/kubernetes/kubernetes/tree/master/cmd/cloud-controller-manager)は`kube-controller-manager`と同じクラウドライブラリを使用します。Kubernetesのコアリポジトリで既にサポートされているクラウドプロバイダーは、Kubernetesリポジトリにあるcloud-controller-managerを使用してKubernetesのコアから移行することが期待されています。今後のKubernetesのリリースでは、すべてのクラウドコントローラーマネージャーはsigリードまたはクラウドベンダーが管理するKubernetesのコアプロジェクトの外で開発される予定です。
+`cloud-controller-manager`は、[cloudprovider.Interface](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go)を満たす任意のクラウドプロバイダーと接続できます。下位互換性のためにKubernetesのコアプロジェクトで提供される[cloud-controller-manager](https://github.com/kubernetes/kubernetes/tree/master/cmd/cloud-controller-manager)は`kube-controller-manager`と同じクラウドライブラリを使用します。Kubernetesのコアリポジトリですでにサポートされているクラウドプロバイダーは、Kubernetesリポジトリにあるcloud-controller-managerを使用してKubernetesのコアから移行することが期待されています。今後のKubernetesのリリースでは、すべてのクラウドコントローラーマネージャーはsigリードまたはクラウドベンダーが管理するKubernetesのコアプロジェクトの外で開発される予定です。
@@ -24,7 +24,7 @@ Kubernetes v1.6では`cloud-controller-manager`という新しいバイナリが
* クラウドの認証/認可: クラウドではAPIへのアクセスを許可するためにトークンまたはIAMルールが必要になる場合があります
* kubernetesの認証/認可: cloud-controller-managerは、kubernetes apiserverと通信するためにRBACルールの設定を必要とする場合があります
-* 高可用性: kube-controller-managerのように、リーダー選出を使用したクラウドコントローラーマネージャーの高可用性のセットアップが必要になる場合があります（デフォルトでオンになっています）。
+* 高可用性: kube-controller-managerのように、リーダー選出を使用したクラウドコントローラーマネージャーの高可用性のセットアップが必要になる場合があります(デフォルトでオンになっています)。
### cloud-controller-managerを動かす
@@ -35,7 +35,7 @@ cloud-controller-managerを正常に実行するにはクラスター構成に
クラウドコントローラーマネージャーを使用するようにクラスターを設定するとクラスターの動作がいくつか変わることに注意してください。
-* `--cloud-provider=external`を指定したkubeletは、初期化時に`NoSchedule`の`node.cloudprovider.kubernetes.io/uninitialized`汚染を追加します。これによりノードは作業をスケジュールする前に外部のコントローラーからの2回目の初期化が必要であるとマークされます。クラウドコントローラーマネージャーが使用できない場合クラスター内の新しいノードはスケジュールできないままになることに注意してください。スケジューラーはリージョンやタイプ（高CPU、GPU、高メモリ、スポットインスタンスなど）などのノードに関するクラウド固有の情報を必要とする場合があるためこの汚染は重要です。
+* `--cloud-provider=external`を指定したkubeletは、初期化時に`NoSchedule`の`node.cloudprovider.kubernetes.io/uninitialized`汚染を追加します。これによりノードは作業をスケジュールする前に外部のコントローラーからの2回目の初期化が必要であるとマークされます。クラウドコントローラーマネージャーが使用できない場合クラスター内の新しいノードはスケジュールできないままになることに注意してください。スケジューラーはリージョンやタイプ(高CPU、GPU、高メモリ、スポットインスタンスなど)などのノードに関するクラウド固有の情報を必要とする場合があるためこの汚染は重要です。
* クラスター内のノードに関するクラウド情報はローカルメタデータを使用して取得されなくなりましたが、代わりにノード情報を取得するためのすべてのAPI呼び出しはクラウドコントローラーマネージャーを経由して行われるようになります。これはセキュリティを向上させるためにkubeletでクラウドAPIへのアクセスを制限できることを意味します。大規模なクラスターではクラスター内からクラウドのほとんどすべてのAPI呼び出しを行うため、クラウドコントローラーマネージャーがレートリミットに達するかどうかを検討する必要があります。
v1.8の時点でクラウドコントローラーマネージャーは以下を実装できます。
@@ -69,7 +69,7 @@ Kubernetesのコアリポジトリにないクラウドコントローラーマ
### ボリュームのサポート
-ボリュームの統合にはkubeletとの調整も必要になるためクラウドコントローラーマネージャーは`kube-controller-manager`にあるボリュームコントローラーを実装しません。CSI（コンテナストレージインターフェイス）が進化してFlexボリュームプラグインの強力なサポートが追加されるにつれ、クラウドがボリュームと完全に統合できるようクラウドコントローラーマネージャーに必要なサポートが追加されます。Kubernetesリポジトリの外部にあるCSIボリュームプラグインの詳細については[こちら](https://github.com/kubernetes/features/issues/178)をご覧ください。
+ボリュームの統合にはkubeletとの調整も必要になるためクラウドコントローラーマネージャーは`kube-controller-manager`にあるボリュームコントローラーを実装しません。CSI(コンテナストレージインターフェイス)が進化してFlexボリュームプラグインの強力なサポートが追加されるにつれ、クラウドがボリュームと完全に統合できるようクラウドコントローラーマネージャーに必要なサポートが追加されます。Kubernetesリポジトリの外部にあるCSIボリュームプラグインの詳細については[こちら](https://github.com/kubernetes/features/issues/178)をご覧ください。
### スケーラビリティ
@@ -79,7 +79,7 @@ Kubernetesのコアリポジトリにないクラウドコントローラーマ
クラウドコントローラーマネージャープロジェクトの目標はKubernetesのコアプロジェクトからクラウドに関する機能の開発を切り離すことです。残念ながら、Kubernetesプロジェクトの多くの面でクラウドプロバイダーの機能がKubernetesプロジェクトに緊密に結びついているという前提があります。そのため、この新しいアーキテクチャを採用するとクラウドプロバイダーの情報を要求する状況が発生する可能性がありますが、クラウドコントローラーマネージャーはクラウドプロバイダーへのリクエストが完了するまでその情報を返すことができない場合があります。
-これの良い例は、KubeletのTLSブートストラップ機能です。現在、TLSブートストラップはKubeletがすべてのアドレスタイプ（プライベート、パブリックなど）をクラウドプロバイダー（またはローカルメタデータサービス）に要求する能力を持っていると仮定していますが、クラウドコントローラーマネージャーは最初に初期化されない限りノードのアドレスタイプを設定できないためapiserverと通信するためにはkubeletにTLS証明書が必要です。
+これの良い例は、KubeletのTLSブートストラップ機能です。現在、TLSブートストラップはKubeletがすべてのアドレスタイプ(プライベート、パブリックなど)をクラウドプロバイダー(またはローカルメタデータサービス)に要求する能力を持っていると仮定していますが、クラウドコントローラーマネージャーは最初に初期化されない限りノードのアドレスタイプを設定できないためapiserverと通信するためにはkubeletにTLS証明書が必要です。
このイニシアチブが成熟するに連れ、今後のリリースでこれらの問題に対処するための変更が行われます。
diff --git a/content/ja/docs/tasks/configure-pod-container/assign-cpu-resource.md b/content/ja/docs/tasks/configure-pod-container/assign-cpu-resource.md
index 5940705cdd..8091ded576 100644
--- a/content/ja/docs/tasks/configure-pod-container/assign-cpu-resource.md
+++ b/content/ja/docs/tasks/configure-pod-container/assign-cpu-resource.md
@@ -196,7 +196,7 @@ kubectl delete pod cpu-demo-2 --namespace=cpu-example
クラスターで動作するコンテナにCPU要求と制限を設定することで、クラスターのノードで利用可能なCPUリソースを効率的に使用することができます。PodのCPU要求を低く保つことで、Podがスケジュールされやすくなります。CPU要求よりも大きい制限を与えることで、次の2つを実現できます:
-* Podは利用可能なCPUリソースを、突発的な活動（バースト）に使用することができます。
+* Podは利用可能なCPUリソースを、突発的な活動(バースト)に使用することができます。
* バースト中のPodのCPUリソース量は、適切な量に制限されます。
diff --git a/content/ja/docs/tasks/configure-pod-container/assign-memory-resource.md b/content/ja/docs/tasks/configure-pod-container/assign-memory-resource.md
index fb361dfa72..1af80012fc 100644
--- a/content/ja/docs/tasks/configure-pod-container/assign-memory-resource.md
+++ b/content/ja/docs/tasks/configure-pod-container/assign-memory-resource.md
@@ -97,7 +97,7 @@ resources:
kubectl top pod memory-demo --namespace=mem-example
```
-この出力では、Podが約162,900,000バイト（約150MiB）のメモリーを使用していることを示しています。Podの100MiBの要求を超えていますが、200MiBの制限には収まっています。
+この出力では、Podが約162,900,000バイト(約150MiB)のメモリーを使用していることを示しています。Podの100MiBの要求を超えていますが、200MiBの制限には収まっています。
```
NAME CPU(cores) MEMORY(bytes)
@@ -278,7 +278,7 @@ kubectl delete pod memory-demo-3 --namespace=mem-example
クラスターで動作するコンテナにメモリー要求と制限を設定することで、クラスターのノードで利用可能なメモリーリソースを効率的に使用することができます。Podのメモリー要求を低く保つことで、Podがスケジュールされやすくなります。メモリー要求よりも大きい制限を与えることで、次の2つを実現できます:
-* Podは利用可能なメモリーを、突発的な活動（バースト）に使用することができます。
+* Podは利用可能なメモリーを、突発的な活動(バースト)に使用することができます。
* バースト中のPodのメモリー使用量は、適切な量に制限されます。
## クリーンアップ
diff --git a/content/ja/docs/tasks/configure-pod-container/assign-pods-nodes.md b/content/ja/docs/tasks/configure-pod-container/assign-pods-nodes.md
new file mode 100644
index 0000000000..e2e4e1d647
--- /dev/null
+++ b/content/ja/docs/tasks/configure-pod-container/assign-pods-nodes.md
@@ -0,0 +1,93 @@
+---
+title: Podをノードに割り当てる
+content_type: task
+weight: 120
+---
+
+
+このページでは、KubernetesのPodをKubernetesクラスター上の特定のノードに割り当てる方法を説明します。
+
+## {{% heading "prerequisites" %}}
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+
+
+## ラベルをノードに追加する
+
+1. クラスター内の{{< glossary_tooltip term_id="node" text="ノード" >}}のリストをラベル付きで表示します。
+
+ ```shell
+ kubectl get nodes --show-labels
+ ```
+
+ 出力は次のようになります。
+
+ ```shell
+ NAME STATUS ROLES AGE VERSION LABELS
+ worker0 Ready 1d v1.13.0 ...,kubernetes.io/hostname=worker0
+ worker1 Ready 1d v1.13.0 ...,kubernetes.io/hostname=worker1
+ worker2 Ready 1d v1.13.0 ...,kubernetes.io/hostname=worker2
+ ```
+1. ノードの1つを選択して、ラベルを追加します。
+
+ ```shell
+ kubectl label nodes disktype=ssd
+ ```
+
+ ここで、``は選択したノードの名前です。
+
+1. 選択したノードに`disktype=ssd`ラベルがあることを確認します。
+
+ ```shell
+ kubectl get nodes --show-labels
+ ```
+
+ 出力は次のようになります。
+
+ ```shell
+ NAME STATUS ROLES AGE VERSION LABELS
+ worker0 Ready 1d v1.13.0 ...,disktype=ssd,kubernetes.io/hostname=worker0
+ worker1 Ready 1d v1.13.0 ...,kubernetes.io/hostname=worker1
+ worker2 Ready 1d v1.13.0 ...,kubernetes.io/hostname=worker2
+ ```
+
+ 上の出力を見ると、`worker0`に`disktype=ssd`というラベルがあることがわかります。
+
+## 選択したノードにスケジューリングされるPodを作成する
+
+以下のPodの構成ファイルには、nodeSelectorに`disktype: ssd`を持つPodが書かれています。これにより、Podは`disktype: ssd`というラベルを持っているノードにスケジューリングされるようになります。
+
+{{< codenew file="pods/pod-nginx.yaml" >}}
+
+1. 構成ファイルを使用して、選択したノードにスケジューリングされるPodを作成します。
+
+ ```shell
+ kubectl apply -f https://k8s.io/examples/pods/pod-nginx.yaml
+ ```
+
+1. Podが選択したノード上で実行されているをことを確認します。
+
+ ```shell
+ kubectl get pods --output=wide
+ ```
+
+ 出力は次のようになります。
+
+ ```shell
+ NAME READY STATUS RESTARTS AGE IP NODE
+ nginx 1/1 Running 0 13s 10.200.0.4 worker0
+ ```
+
+## 特定のノードにスケジューリングされるPodを作成する
+
+`nodeName`という設定を使用して、Podを特定のノードにスケジューリングすることもできます。
+
+{{< codenew file="pods/pod-nginx-specific-node.yaml" >}}
+
+構成ファイルを使用して、`foo-node`にだけスケジューリングされるPodを作成します。
+
+## {{% heading "whatsnext" %}}
+
+* [ラベルとセレクター](/ja/docs/concepts/overview/working-with-objects/labels/)についてさらに学ぶ。
+* [ノード](/ja/docs/concepts/architecture/nodes/)についてさらに学ぶ。
diff --git a/content/ja/docs/tasks/configure-pod-container/configure-projected-volume-storage.md b/content/ja/docs/tasks/configure-pod-container/configure-projected-volume-storage.md
index f8e7341bb2..c67c826c4d 100644
--- a/content/ja/docs/tasks/configure-pod-container/configure-projected-volume-storage.md
+++ b/content/ja/docs/tasks/configure-pod-container/configure-projected-volume-storage.md
@@ -5,7 +5,7 @@ weight: 70
---
-このページでは、[`projected`](/docs/concepts/storage/volumes/#projected)（投影）ボリュームを使用して、既存の複数のボリュームソースを同一ディレクトリ内にマウントする方法を説明します。
+このページでは、[`projected`](/docs/concepts/storage/volumes/#projected)(投影)ボリュームを使用して、既存の複数のボリュームソースを同一ディレクトリ内にマウントする方法を説明します。
現在、`secret`、`configMap`、`downwardAPI`および`serviceAccountToken`ボリュームを投影できます。
{{< note >}}
diff --git a/content/ja/docs/tasks/configure-pod-container/configure-volume-storage.md b/content/ja/docs/tasks/configure-pod-container/configure-volume-storage.md
index 87fa5d965e..a7bb1a0d65 100644
--- a/content/ja/docs/tasks/configure-pod-container/configure-volume-storage.md
+++ b/content/ja/docs/tasks/configure-pod-container/configure-volume-storage.md
@@ -87,7 +87,7 @@ weight: 50
root@redis:/data/redis# kill
```
- ここで``はRedisプロセスID（PID）です。
+ ここで``はRedisプロセスID(PID)です。
1. 元の端末で、Redis Podへの変更を監視します。最終的には、このようなものが表示されます:
diff --git a/content/ja/docs/tasks/configure-pod-container/extended-resource.md b/content/ja/docs/tasks/configure-pod-container/extended-resource.md
new file mode 100644
index 0000000000..b056fc7389
--- /dev/null
+++ b/content/ja/docs/tasks/configure-pod-container/extended-resource.md
@@ -0,0 +1,124 @@
+---
+title: 拡張リソースをコンテナに割り当てる
+content_type: task
+weight: 40
+---
+
+
+
+{{< feature-state state="stable" >}}
+
+このページでは、拡張リソースをコンテナに割り当てる方法について説明します。
+
+## {{% heading "prerequisites" %}}
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+この練習を始める前に、[Nodeに拡張リソースをアドバタイズする](/ja/docs/tasks/administer-cluster/extended-resource-node/)の練習を行ってください。これにより、Nodeの1つがドングルリソースをアドバタイズするように設定されます。
+
+
+
+## 拡張リソースをPodに割り当てる
+
+拡張リソースをリクエストするには、コンテナのマニフェストに`resources:requests`フィールドを含めます。拡張リソースは、`*.kubernetes.io/`以外の任意のドメインで完全修飾されます。有効な拡張リソース名は、`example.com/foo`という形式になります。ここで、`example.com`はあなたの組織のドメインで、`foo`は記述的なリソース名で置き換えます。
+
+1つのコンテナからなるPodの構成ファイルを示します。
+
+{{< codenew file="pods/resource/extended-resource-pod.yaml" >}}
+
+構成ファイルでは、コンテナが3つのdongleをリクエストしていることがわかります。
+
+次のコマンドでPodを作成します。
+
+```shell
+kubectl apply -f https://k8s.io/examples/pods/resource/extended-resource-pod.yaml
+```
+
+Podが起動したことを確認します。
+
+```shell
+kubectl get pod extended-resource-demo
+```
+
+Podの説明を表示します。
+
+```shell
+kubectl describe pod extended-resource-demo
+```
+
+dongleのリクエストが表示されます。
+
+```yaml
+Limits:
+ example.com/dongle: 3
+Requests:
+ example.com/dongle: 3
+```
+
+## 2つ目のPodの作成を試みる
+
+以下に、1つのコンテナを持つPodの構成ファイルを示します。コンテナは2つのdongleをリクエストします。
+
+{{< codenew file="pods/resource/extended-resource-pod-2.yaml" >}}
+
+Kubernetesは、2つのdongleのリクエストを満たすことができません。1つ目のPodが、利用可能な4つのdongleのうち3つを使用してしまっているためです。
+
+Podを作成してみます。
+
+```shell
+kubectl apply -f https://k8s.io/examples/pods/resource/extended-resource-pod-2.yaml
+```
+
+Podの説明を表示します。
+
+```shell
+kubectl describe pod extended-resource-demo-2
+```
+
+出力にはPodがスケジュールできないことが示されます。2つのdongleが利用できるNodeが存在しないためです。
+
+```
+Conditions:
+ Type Status
+ PodScheduled False
+...
+Events:
+ ...
+ ... Warning FailedScheduling pod (extended-resource-demo-2) failed to fit in any node
+fit failure summary on nodes : Insufficient example.com/dongle (1)
+```
+
+Podのステータスを表示します。
+
+```shell
+kubectl get pod extended-resource-demo-2
+```
+
+出力には、Podは作成されたものの、Nodeにスケジュールされなかったことが示されています。PodはPending状態になっています。
+
+```yaml
+NAME READY STATUS RESTARTS AGE
+extended-resource-demo-2 0/1 Pending 0 6m
+```
+
+## クリーンアップ
+
+この練習で作成したPodを削除します。
+
+```shell
+kubectl delete pod extended-resource-demo
+kubectl delete pod extended-resource-demo-2
+```
+
+## {{% heading "whatsnext" %}}
+
+### アプリケーション開発者向け
+
+* [コンテナおよびPodへのメモリーリソースの割り当て](/ja/docs/tasks/configure-pod-container/assign-memory-resource/)
+* [コンテナおよびPodへのCPUリソースの割り当て](/ja/docs/tasks/configure-pod-container/assign-cpu-resource/)
+
+### クラスター管理者向け
+
+* [Nodeに拡張リソースをアドバタイズする](/ja/docs/tasks/administer-cluster/extended-resource-node/)
+
+
diff --git a/content/ja/docs/tasks/configure-pod-container/share-process-namespace.md b/content/ja/docs/tasks/configure-pod-container/share-process-namespace.md
index 513da2365c..b5fd61777e 100644
--- a/content/ja/docs/tasks/configure-pod-container/share-process-namespace.md
+++ b/content/ja/docs/tasks/configure-pod-container/share-process-namespace.md
@@ -97,7 +97,7 @@ Podは多くのリソースを共有するため、プロセスの名前空間
ただし、一部のコンテナイメージは他のコンテナから分離されることが期待されるため、これらの違いを理解することが重要です:
1. **コンテナプロセスは PID 1ではなくなります。**
- 一部のコンテナイメージは、PID 1なしで起動することを拒否し（たとえば、`systemd`を使用するコンテナ）、`kill -HUP 1`などのコマンドを実行してコンテナプロセスにシグナルを送信します。
+ 一部のコンテナイメージは、PID 1なしで起動することを拒否し(たとえば、`systemd`を使用するコンテナ)、`kill -HUP 1`などのコマンドを実行してコンテナプロセスにシグナルを送信します。
共有プロセス名前空間を持つPodでは、`kill -HUP 1`はPodサンドボックスにシグナルを送ります。(上の例では`/pause`)
1. **プロセスはPod内の他のコンテナに表示されます。**
diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-init-containers.md b/content/ja/docs/tasks/debug-application-cluster/debug-init-containers.md
index 5577881c95..fa5255ca7f 100644
--- a/content/ja/docs/tasks/debug-application-cluster/debug-init-containers.md
+++ b/content/ja/docs/tasks/debug-application-cluster/debug-init-containers.md
@@ -14,7 +14,7 @@ content_type: task
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-* [Initコンテナ](/ja/docs/concepts/abstractions/init-containers/)の基本を理解しておきましょう。
+* [Initコンテナ](/ja/docs/concepts/workloads/pods/init-containers/)の基本を理解しておきましょう。
* [Initコンテナを設定](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container/)しておきましょう。
@@ -100,7 +100,7 @@ kubectl logs -c
-## Podのステータスを理解する
+## Podのステータスを理解する {#understanding-pod-status}
`Init：`で始まるPodステータスはInitコンテナの実行ステータスを要約します。以下の表は、Initコンテナのデバッグ中に表示される可能性のあるステータス値の例をいくつか示しています。
diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-service.md b/content/ja/docs/tasks/debug-application-cluster/debug-service.md
index c4c965458b..a8332cbcfb 100644
--- a/content/ja/docs/tasks/debug-application-cluster/debug-service.md
+++ b/content/ja/docs/tasks/debug-application-cluster/debug-service.md
@@ -4,9 +4,7 @@ title: Serviceのデバッグ
---
-新規にKubernetesをインストールした環境でかなり頻繁に発生する問題は、Serviceが適切に機能しないというものです。
-Deployment（または他のワークロードコントローラー）を通じてPodを実行し、サービスを作成したにもかかわらず、アクセスしようとしても応答がありません。
-何が問題になっているのかを理解するのに、このドキュメントがきっと役立つでしょう。
+新規にKubernetesをインストールした環境でかなり頻繁に発生する問題は、Serviceが適切に機能しないというものです。Deployment(または他のワークロードコントローラー)を通じてPodを実行し、サービスを作成したにもかかわらず、アクセスしようとしても応答がありません。何が問題になっているのかを理解するのに、このドキュメントがきっと役立つでしょう。
@@ -16,8 +14,7 @@ Deployment（または他のワークロードコントローラー）を通じ
## Pod内でコマンドを実行する
-ここでの多くのステップでは、クラスターで実行されているPodが見ているものを確認する必要があります。
-これを行う最も簡単な方法は、インタラクティブなalpineのPodを実行することです。
+ここでの多くのステップでは、クラスターで実行されているPodが見ているものを確認する必要があります。これを行う最も簡単な方法は、インタラクティブなalpineのPodを実行することです。
```none
kubectl run -it --rm --restart=Never alpine --image=alpine sh
@@ -27,7 +24,7 @@ kubectl run -it --rm --restart=Never alpine --image=alpine sh
コマンドプロンプトが表示されない場合は、Enterキーを押してみてください。
{{< /note >}}
-使用したい実行中のPodが既にある場合は、以下のようにしてそのPod内でコマンドを実行できます。
+使用したい実行中のPodがすでにある場合は、以下のようにしてそのPod内でコマンドを実行できます。
```shell
kubectl exec -c --
@@ -35,8 +32,7 @@ kubectl exec -c --
## セットアップ
-このドキュメントのウォークスルーのために、いくつかのPodを実行しましょう。
-おそらくあなた自身のServiceをデバッグしているため、あなた自身の詳細に置き換えることもできますし、これに沿って2番目のデータポイントを取得することもできます。
+このドキュメントのウォークスルーのために、いくつかのPodを実行しましょう。おそらくあなた自身のServiceをデバッグしているため、あなた自身の詳細に置き換えることもできますし、これに沿って2番目のデータポイントを取得することもできます。
```shell
kubectl run hostnames --image=k8s.gcr.io/serve_hostname \
@@ -48,7 +44,7 @@ deployment.apps/hostnames created
`kubectl`コマンドは作成、変更されたリソースのタイプと名前を出力するため、この後のコマンドで使用することもできます。
-{{< note >}}
+
これは、次のYAMLでDeploymentを開始した場合と同じです。
```yaml
@@ -72,7 +68,6 @@ spec:
```
"run"ラベルは`kubectl run`によって、Deploymentの名前に自動的にセットされます。
-{{< /note >}}
Podが実行されていることを確認できます。
@@ -86,8 +81,7 @@ hostnames-632524106-ly40y 1/1 Running 0 2m
hostnames-632524106-tlaok 1/1 Running 0 2m
```
-Podが機能していることも確認できます。
-Pod IP アドレスリストを取得し、直接テストできます。
+Podが機能していることも確認できます。Pod IP アドレスリストを取得し、直接テストできます。
```shell
kubectl get pods -l run=hostnames \
@@ -117,8 +111,7 @@ hostnames-bvc05
hostnames-yp2kp
```
-この時点で期待通りの応答が得られない場合、Podが正常でないか、想定しているポートでリッスンしていない可能性があります。
-なにが起きているかを確認するために`kubectl logs`が役立ちます、Podに直接に入りデバッグする場合は `kubectl exec`が必要になります。
+この時点で期待通りの応答が得られない場合、Podが正常でないか、想定しているポートでリッスンしていない可能性があります。なにが起きているかを確認するために`kubectl logs`が役立ちます。Podに直接に入りデバッグする場合は`kubectl exec`が必要になります。
これまでにすべての計画が完了していると想定すると、Serviceが機能しない理由を調査することができます。
@@ -126,8 +119,7 @@ hostnames-yp2kp
賢明な読者は、Serviceをまだ実際に作成していないことにお気付きかと思いますが、これは意図的です。これは時々忘れられるステップであり、最初に確認すべきことです。
-存在しないServiceにアクセスしようとするとどうなるでしょうか？
-このServiceを名前で利用する別のPodがあると仮定すると、次のような結果が得られます。
+存在しないServiceにアクセスしようとするとどうなるでしょうか？このServiceを名前で利用する別のPodがあると仮定すると、次のような結果が得られます。
```shell
wget -O- hostnames
@@ -147,8 +139,7 @@ No resources found.
Error from server (NotFound): services "hostnames" not found
```
-Serviceを作成しましょう。
-前と同様に、これはウォークスルー用です。ご自身のServiceの詳細を使用することもできます。
+Serviceを作成しましょう。前と同様に、これはウォークスルー用です。ご自身のServiceの詳細を使用することもできます。
```shell
kubectl expose deployment hostnames --port=80 --target-port=9376
@@ -169,7 +160,6 @@ hostnames ClusterIP 10.0.1.175 80/TCP 5s
これで、Serviceが存在することがわかりました。
-{{< note >}}
前と同様に、これは次のようなYAMLでServiceを開始した場合と同じです。
```yaml
@@ -187,14 +177,11 @@ spec:
targetPort: 9376
```
-構成の全範囲をハイライトするため、ここで作成したServiceはPodとは異なるポート番号を使用します。
-多くの実際のServiceでは、これらのポートは同じになる場合があります。
-{{< /note >}}
+構成の全範囲をハイライトするため、ここで作成したServiceはPodとは異なるポート番号を使用します。多くの実際のServiceでは、これらのポートは同じになる場合があります。
## サービスはDNS名によって機能しているか？
-クライアントがサービスを使用する最も一般的な方法の1つは、DNS名を使用することです。
-同じNamespaceのPodから次のコマンドを実行してください。
+クライアントがサービスを使用する最も一般的な方法の1つは、DNS名を使用することです。同じNamespaceのPodから次のコマンドを実行してください。
```shell
nslookup hostnames
@@ -219,8 +206,7 @@ Name: hostnames.default
Address 1: 10.0.1.175 hostnames.default.svc.cluster.local
```
-これが機能する場合、クロスネームスペース名を使用するようにアプリケーションを調整するか、同じNamespaceでアプリとServiceを実行する必要があります。
-これでも失敗する場合は、完全修飾名を試してください。
+これが機能する場合、クロスネームスペース名を使用するようにアプリケーションを調整するか、同じNamespaceでアプリとServiceを実行する必要があります。これでも失敗する場合は、完全修飾名を試してください。
```shell
nslookup hostnames.default.svc.cluster.local
@@ -232,10 +218,7 @@ Name: hostnames.default.svc.cluster.local
Address 1: 10.0.1.175 hostnames.default.svc.cluster.local
```
-ここでのサフィックス"default.svc.cluster.local"に注意してください。
-"default"は、操作しているNamespaceです。
-"svc"は、これがServiceであることを示します。
-"cluster.local"はクラスタードメインであり、あなたのクラスターでは異なる場合があります。
+ここでのサフィックス"default.svc.cluster.local"に注意してください。"default"は、操作しているNamespaceです。"svc"は、これがServiceであることを示します。"cluster.local"はクラスタードメインであり、あなたのクラスターでは異なる場合があります。
クラスター内のノードからも試すこともできます。
@@ -254,8 +237,7 @@ Name: hostnames.default.svc.cluster.local
Address: 10.0.1.175
```
-完全修飾名では検索できるのに、相対名ではできない場合、Podの`/etc/resolv.conf`ファイルが正しいことを確認する必要があります。
-Pod内から実行します。
+完全修飾名では検索できるのに、相対名ではできない場合、Podの`/etc/resolv.conf`ファイルが正しいことを確認する必要があります。Pod内から実行します。
```shell
cat /etc/resolv.conf
@@ -269,25 +251,15 @@ search default.svc.cluster.local svc.cluster.local cluster.local example.com
options ndots:5
```
-nameserver行はクラスターのDNS Serviceを示さなければなりません。
-これは、`--cluster-dns`フラグで`kubelet`に渡されます。
+nameserver行はクラスターのDNS Serviceを示さなければなりません。これは、`--cluster-dns`フラグで`kubelet`に渡されます。
-`search`行には、`Service`名を見つけるための適切なサフィックスを含める必要があります。
-この場合、ローカルの`Namespace`で`Service`を見つけるためのサフィックス(`default.svc.cluster.local`)、すべての`Namespaces`で`Service`を見つけるためのサフィックス(`svc.cluster.local`)、およびクラスターのサフィックス(`cluster.local`)です。
-インストール方法によっては、その後に追加のレコードがある場合があります(合計6つまで)。
-クラスターのサフィックスは、`--cluster-domain`フラグを使用して`kubelet`に渡されます。
-このドキュメントではそれが"cluster.local"であると仮定していますが、あなたのクラスターでは異なる場合があります。
-その場合は、上記のすべてのコマンドでクラスターのサフィックスを変更する必要があります。
+`search`行には、`Service`名を見つけるための適切なサフィックスを含める必要があります。この場合、ローカルの`Namespace`で`Service`を見つけるためのサフィックス(`default.svc.cluster.local`)、すべての`Namespaces`で`Service`を見つけるためのサフィックス(`svc.cluster.local`)、およびクラスターのサフィックス(`cluster.local`)です。インストール方法によっては、その後に追加のレコードがある場合があります(合計6つまで)。クラスターのサフィックスは、`--cluster-domain`フラグを使用して`kubelet`に渡されます。このドキュメントではそれが"cluster.local"であると仮定していますが、あなたのクラスターでは異なる場合があります。その場合は、上記のすべてのコマンドでクラスターのサフィックスを変更する必要があります。
-`options`行では、DNSクライアントライブラリーが検索パスをまったく考慮しないように`ndots`を十分に高く設定する必要があります。
-Kubernetesはデフォルトでこれを5に設定します。これは、生成されるすべてのDNS名をカバーするのに十分な大きさです。
+`options`行では、DNSクライアントライブラリーが検索パスをまったく考慮しないように`ndots`を十分に高く設定する必要があります。Kubernetesはデフォルトでこれを5に設定します。これは、生成されるすべてのDNS名をカバーするのに十分な大きさです。
-### DNS名で機能するServiceはありますか？ {#does-any-service-exist-in-dns}
+### DNS名で機能するServiceはあるか？ {#does-any-service-exist-in-dns}
-上記がまだ失敗する場合、DNSルックアップがServiceに対して機能していません。
-一歩離れて、他の何が機能していないかを確認しましょう。
-KubernetesマスターのServiceは常に機能するはずです。
-Pod内から実行します。
+上記がまだ失敗する場合、DNSルックアップがServiceに対して機能していません。一歩離れて、他の何が機能していないかを確認しましょう。KubernetesマスターのServiceは常に機能するはずです。Pod内から実行します。
```shell
nslookup kubernetes.default
@@ -300,12 +272,11 @@ Name: kubernetes.default
Address 1: 10.0.0.1 kubernetes.default.svc.cluster.local
```
-これが失敗する場合は、このドキュメントの [kube-proxy](#is-the-kube-proxy-working)セクションを参照するか、このドキュメントの先頭に戻って最初からやり直してください。ただし、あなた自身のServiceをデバッグするのではなく 、DNSサービスをデバッグします。
+これが失敗する場合は、このドキュメントの[kube-proxy](#is-the-kube-proxy-working)セクションを参照するか、このドキュメントの先頭に戻って最初からやり直してください。ただし、あなた自身のServiceをデバッグするのではなく、DNSサービスをデバッグします。
## ServiceはIPでは機能するか？
-DNSサービスが正しく動作できると仮定すると、次にテストするのはIPによってServiceが動作しているかどうかです。
-上述の`kubectl get`で確認できるIPに、クラスター内のPodからアクセスします。
+DNSサービスが正しく動作できると仮定すると、次にテストするのはIPによってServiceが動作しているかどうかです。上述の`kubectl get`で確認できるIPに、クラスター内のPodからアクセスします。
```shell
for i in $(seq 1 3); do
@@ -321,13 +292,11 @@ hostnames-bvc05
hostnames-yp2kp
```
-Serviceが機能している場合は、正しい応答が得られるはずです。
-そうでない場合、おかしい可能性のあるものがいくつかあるため、続けましょう。
+Serviceが機能している場合は、正しい応答が得られるはずです。そうでない場合、おかしい可能性のあるものがいくつかあるため、続けましょう。
## Serviceは正しく定義されているか？
-馬鹿げているように聞こえるかもしれませんが、Serviceが正しく定義されPodのポートとマッチすることを二度、三度と確認すべきです。
-Serviceを読み返して確認しましょう。
+馬鹿げているように聞こえるかもしれませんが、Serviceが正しく定義されPodのポートとマッチすることを二度、三度と確認すべきです。Serviceを読み返して確認しましょう。
```shell
kubectl get service hostnames -o json
@@ -377,8 +346,7 @@ kubectl get service hostnames -o json
## ServiceにEndpointsがあるか？
-ここまで来たということは、Serviceは正しく定義され、DNSによって名前解決できることが確認できているでしょう。
-ここでは、実行したPodがServiceによって実際に選択されていることを確認しましょう。
+ここまで来たということは、Serviceは正しく定義され、DNSによって名前解決できることが確認できているでしょう。ここでは、実行したPodがServiceによって実際に選択されていることを確認しましょう。
以前に、Podが実行されていることを確認しました。再確認しましょう。
@@ -395,8 +363,7 @@ hostnames-yp2kp 1/1 Running 0 1h
"AGE"列は、これらのPodが約1時間前のものであることを示しており、それらが正常に実行され、クラッシュしていないことを意味します。
-"RESTARTS"列は、これらのポッドが頻繁にクラッシュしたり、再起動されていないことを示しています。 頻繁に再起動すると、断続的な接続性の問題が発生する可能性があります。
-再起動回数が多い場合は、[ポッドをデバッグする](/ja/docs/tasks/debug-application-cluster/debug-pod-replication-controller/#podのデバッグ)を参照してください。
+"RESTARTS"列は、これらのポッドが頻繁にクラッシュしたり、再起動されていないことを示しています。頻繁に再起動すると、断続的な接続性の問題が発生する可能性があります。再起動回数が多い場合は、[ポッドをデバッグする](/ja/docs/tasks/debug-application-cluster/debug-pod-replication-controller/#podのデバッグ)を参照してください。
Kubernetesシステム内には、すべてのServiceのセレクターを評価し、結果をEndpointsオブジェクトに保存するコントロールループがあります。
@@ -407,15 +374,11 @@ NAME ENDPOINTS
hostnames 10.244.0.5:9376,10.244.0.6:9376,10.244.0.7:9376
```
-これにより、EndpointsコントローラーがServiceの正しいPodを見つけていることを確認できます。
-`ENDPOINTS`列が``の場合、Serviceの`spec.selector`フィールドが実際にPodの`metadata.labels`値を選択していることを確認する必要があります。
-よくある間違いは、タイプミスまたは他のエラー、たとえばServiceが`app=hostnames`を選択しているのにDeploymentが`run=hostnames`を指定していることです。
+これにより、EndpointsコントローラーがServiceの正しいPodを見つけていることを確認できます。`ENDPOINTS`列が``の場合、Serviceの`spec.selector`フィールドが実際にPodの`metadata.labels`値を選択していることを確認する必要があります。よくある間違いは、タイプミスまたは他のエラー、たとえばServiceが`app=hostnames`を選択しているのにDeploymentが`run=hostnames`を指定していることです。
## Podは機能しているか？
-この時点で、Serviceが存在し、Podを選択していることがわかります。
-このウォークスルーの最初に、Pod自体を確認しました。
-Podが実際に機能していることを確認しましょう。Serviceメカニズムをバイパスして、上記EndpointsにリストされているPodに直接アクセスすることができます。
+この時点で、Serviceが存在し、Podを選択していることがわかります。このウォークスルーの最初に、Pod自体を確認しました。Podが実際に機能していることを確認しましょう。Serviceメカニズムをバイパスして、上記EndpointsにリストされているPodに直接アクセスすることができます。
{{< note >}}
これらのコマンドは、Serviceポート(80)ではなく、Podポート(9376)を使用します。
@@ -437,23 +400,17 @@ hostnames-bvc05
hostnames-yp2kp
```
-Endpointsリスト内の各Podは、それぞれの自身のホスト名を返すはずです。
-そうならない(または、あなた自身のPodの正しい振る舞いにならない)場合は、そこで何が起こっているのかを調査する必要があります。
+Endpointsリスト内の各Podは、それぞれの自身のホスト名を返すはずです。そうならない(または、あなた自身のPodの正しい振る舞いにならない)場合は、そこで何が起こっているのかを調査する必要があります。
## kube-proxyは機能しているか？ {#is-the-kube-proxy-working}
-ここに到達したのなら、Serviceは実行され、Endpointsがあり、Podが実際にサービスを提供しています。
-この時点で、Serviceのプロキシーメカニズム全体が疑わしいです。
-ひとつひとつ確認しましょう。
+ここに到達したのなら、Serviceは実行され、Endpointsがあり、Podが実際にサービスを提供しています。この時点で、Serviceのプロキシーメカニズム全体が疑わしいです。ひとつひとつ確認しましょう。
-Serviceのデフォルト実装、およびほとんどのクラスターで使用されるものは、kube-proxyです。
-kube-proxyはそれぞれのノードで実行され、Serviceの抽象化を提供するための小さなメカニズムセットの1つを構成するプログラムです。
-クラスターがkube-proxyを使用しない場合、以下のセクションは適用されず、使用しているServiceの実装を調査する必要があります。
+Serviceのデフォルト実装、およびほとんどのクラスターで使用されるものは、kube-proxyです。kube-proxyはそれぞれのノードで実行され、Serviceの抽象化を提供するための小さなメカニズムセットの1つを構成するプログラムです。クラスターがkube-proxyを使用しない場合、以下のセクションは適用されず、使用しているServiceの実装を調査する必要があります。
### kube-proxyは実行されているか？
-`kube-proxy`がノード上で実行されていることを確認しましょう。
-ノードで実行されていれば、以下のような結果が得られるはずです。
+`kube-proxy`がノード上で実行されていることを確認しましょう。ノードで実行されていれば、以下のような結果が得られるはずです。
```shell
ps auxw | grep kube-proxy
@@ -462,11 +419,7 @@ ps auxw | grep kube-proxy
root 4194 0.4 0.1 101864 17696 ? Sl Jul04 25:43 /usr/local/bin/kube-proxy --master=https://kubernetes-master --kubeconfig=/var/lib/kube-proxy/kubeconfig --v=2
```
-次に、マスターとの接続など、明らかな失敗をしていないことを確認します。
-これを行うには、ログを確認する必要があります。
-ログへのアクセス方法は、ノードのOSに依存します。
-一部のOSでは/var/log/kube-proxy.logのようなファイルですが、他のOSでは`journalctl`を使用してログにアクセスします。
-次のように表示されます。
+次に、マスターとの接続など、明らかな失敗をしていないことを確認します。これを行うには、ログを確認する必要があります。ログへのアクセス方法は、ノードのOSに依存します。一部のOSでは/var/log/kube-proxy.logのようなファイルですが、他のOSでは`journalctl`を使用してログにアクセスします。次のように表示されます。
```none
I1027 22:14:53.995134 5063 server.go:200] Running in resource-only container "/kube-proxy"
@@ -483,12 +436,9 @@ I1027 22:14:54.040223 5063 proxier.go:294] Adding new service "kube-system/ku
マスターに接続できないことに関するエラーメッセージが表示された場合、ノードの設定とインストール手順をダブルチェックする必要があります。
-`kube-proxy`が正しく実行できない理由の可能性の1つは、必須の`conntrack`バイナリが見つからないことです。
-これは、例えばKubernetesをスクラッチからインストールするなど、クラスターのインストール方法に依存して、一部のLinuxシステムで発生する場合があります。
-これが該当する場合は、`conntrack`パッケージを手動でインストール(例: Ubuntuでは`sudo apt install conntrack`)する必要があり、その後に再試行する必要があります。
+`kube-proxy`が正しく実行できない理由の可能性の1つは、必須の`conntrack`バイナリが見つからないことです。これは、例えばKubernetesをスクラッチからインストールするなど、クラスターのインストール方法に依存して、一部のLinuxシステムで発生する場合があります。これが該当する場合は、`conntrack`パッケージを手動でインストール(例: Ubuntuでは`sudo apt install conntrack`)する必要があり、その後に再試行する必要があります。
-kube-proxyは、いくつかのモードのいずれかで実行できます。 上記のログの`Using iptables Proxier`という行は、kube-proxyが「iptables」モードで実行されていることを示しています。
-最も一般的な他のモードは「ipvs」です。 古い「ユーザースペース」モードは、主にこれらに置き換えられました。
+kube-proxyは、いくつかのモードのいずれかで実行できます。上記のログの`Using iptables Proxier`という行は、kube-proxyが「iptables」モードで実行されていることを示しています。最も一般的な他のモードは「ipvs」です。古い「ユーザースペース」モードは、主にこれらに置き換えられました。
#### Iptables mode
@@ -510,9 +460,7 @@ iptables-save | grep hostnames
-A KUBE-SVC-NWV5X2332I4OT4T3 -m comment --comment "default/hostnames:" -j KUBE-SEP-57KPRZ3JQVENLNBR
```
-各サービスのポートごとに、 `KUBE-SERVICES`に1つのルールと1つの` KUBE-SVC- `チェーンが必要です。
-Podエンドポイントごとに、その `KUBE-SVC- `に少数のルールがあり、少数のルールが含まれる1つの `KUBE-SEP- `チェーンがあるはずです。
-正確なルールは、正確な構成（NodePortとLoadBalancerを含む）に基づいて異なります。
+各サービスのポートごとに、`KUBE-SERVICES`に1つのルールと1つの` KUBE-SVC- `チェーンが必要です。Podエンドポイントごとに、その`KUBE-SVC- `に少数のルールがあり、少数のルールが含まれる1つの`KUBE-SEP- `チェーンがあるはずです。正確なルールは、正確な構成(NodePortとLoadBalancerを含む)に基づいて異なります。
#### IPVS mode
@@ -532,12 +480,9 @@ TCP 10.0.1.175:80 rr
...
```
-各Serviceの各ポートに加えて、NodePort、External IP、およびLoad Balancer IPに対して、kube-proxyは仮想サーバーを作成します。
-Pod endpointごとに、対応する実サーバーが作成されます。
-この例では, サービスhostnames(`10.0.1.175:80`) は3つのendpoints(`10.244.0.5:9376`,`10.244.0.6:9376`, `10.244.0.7:9376`)を持っています。
+各Serviceの各ポートに加えて、NodePort、External IP、およびLoad Balancer IPに対して、kube-proxyは仮想サーバーを作成します。Pod endpointごとに、対応する実サーバーが作成されます。この例では、サービスhostnames(`10.0.1.175:80`)は3つのendpoints(`10.244.0.5:9376`、`10.244.0.6:9376`、`10.244.0.7:9376`)を持っています。
-IPVSプロキシーは、各Serviceアドレス(Cluster IP、External IP、NodePort IP、Load Balancer IPなど)毎の仮想サーバーと、Serviceのエンドポイントが存在する場合に対応する実サーバーを作成します。
-この例では、hostnames Service(`10.0.1.175:80`)は3つのエンドポイント(`10.244.0.5:9376`、`10.244.0.6:9376`、`10.244.0.7:9376`)を持ち、上と似た結果が得られるはずです。
+IPVSプロキシーは、各Serviceアドレス(Cluster IP、External IP、NodePort IP、Load Balancer IPなど)毎の仮想サーバーと、Serviceのエンドポイントが存在する場合に対応する実サーバーを作成します。この例では、hostnames Service(`10.0.1.175:80`)は3つのエンドポイント(`10.244.0.5:9376`、`10.244.0.6:9376`、`10.244.0.7:9376`)を持ち、上と似た結果が得られるはずです。
#### Userspace mode
@@ -553,7 +498,7 @@ iptables-save | grep hostnames
-A KUBE-PORTALS-HOST -d 10.0.1.175/32 -p tcp -m comment --comment "default/hostnames:default" -m tcp --dport 80 -j DNAT --to-destination 10.240.115.247:48577
```
-サービスの各ポートには2つのルールが必要です（この例では1つだけ）-「KUBE-PORTALS-CONTAINER」と「KUBE-PORTALS-HOST」です。
+サービスの各ポートには2つのルールが必要です(この例では1つだけ)-「KUBE-PORTALS-CONTAINER」と「KUBE-PORTALS-HOST」です。
「userspace」モードを使用する必要はほとんどないので、ここでこれ以上時間を費やすことはありません。
@@ -568,11 +513,9 @@ curl 10.0.1.175:80
hostnames-0uton
```
-もしこれが失敗し、あなたがuserspaceプロキシーを使用している場合、プロキシーへの直接アクセスを試してみてください。
-もしiptablesプロキシーを使用している場合、このセクションはスキップしてください。
+もしこれが失敗し、あなたがuserspaceプロキシーを使用している場合、プロキシーへの直接アクセスを試してみてください。もしiptablesプロキシーを使用している場合、このセクションはスキップしてください。
-上記の`iptables-save`の出力を振り返り、`kube-proxy`がServiceに使用しているポート番号を抽出します。
-上記の例では"48577"です。このポートに接続してください。
+上記の`iptables-save`の出力を振り返り、`kube-proxy`がServiceに使用しているポート番号を抽出します。上記の例では"48577"です。このポートに接続してください。
```shell
curl localhost:48577
@@ -589,18 +532,13 @@ Setting endpoints for default/hostnames:default to [10.244.0.5:9376 10.244.0.6:9
これらが表示されない場合は、`-v`フラグを4に設定して`kube-proxy`を再起動してから、再度ログを確認してください。
-### エッジケース: PodがService IP経由で自身に到達できない。 {#a-pod-fails-to-reach-itself-via-the-service-ip}
+### エッジケース: PodがService IP経由で自身に到達できない {#a-pod-fails-to-reach-itself-via-the-service-ip}
-これはありそうに聞こえないかもしれませんが、実際には起こり、動作するはずです。
-これはネットワークが"hairpin"トラフィック用に適切に設定されていない場合、通常は`kube-proxy`が`iptables`モードで実行され、Podがブリッジネットワークに接続されている場合に発生します。
-`Kubelet`は`hairpin-mode`[フラグ](/docs/admin/kubelet/)を公開します。
-これにより、Serviceのエンドポイントが自身のServiceのVIPにアクセスしようとした場合に、自身への負荷分散を可能にします。
-`hairpin-mode`フラグは`hairpin-veth`または`promiscuous-bridge`に設定する必要があります。
+これはありそうに聞こえないかもしれませんが、実際には起こり、動作するはずです。これはネットワークが"hairpin"トラフィック用に適切に設定されていない場合、通常は`kube-proxy`が`iptables`モードで実行され、Podがブリッジネットワークに接続されている場合に発生します。`Kubelet`は`hairpin-mode`[フラグ](/docs/admin/kubelet/)を公開します。これにより、Serviceのエンドポイントが自身のServiceのVIPにアクセスしようとした場合に、自身への負荷分散を可能にします。`hairpin-mode`フラグは`hairpin-veth`または`promiscuous-bridge`に設定する必要があります。
この問題をトラブルシューティングする一般的な手順は次のとおりです。
-* `hairpin-mode`が`hairpin-veth`または`promiscuous-bridge`に設定されていることを確認します。
-次のような表示がされるはずです。この例では、`hairpin-mode`は`promiscuous-bridge`に設定されています。
+* `hairpin-mode`が`hairpin-veth`または`promiscuous-bridge`に設定されていることを確認します。次のような表示がされるはずです。この例では、`hairpin-mode`は`promiscuous-bridge`に設定されています。
```shell
ps auxw | grep kubelet
@@ -609,20 +547,13 @@ ps auxw | grep kubelet
root 3392 1.1 0.8 186804 65208 ? Sl 00:51 11:11 /usr/local/bin/kubelet --enable-debugging-handlers=true --config=/etc/kubernetes/manifests --allow-privileged=True --v=4 --cluster-dns=10.0.0.10 --cluster-domain=cluster.local --configure-cbr0=true --cgroup-root=/ --system-cgroups=/system --hairpin-mode=promiscuous-bridge --runtime-cgroups=/docker-daemon --kubelet-cgroups=/kubelet --babysit-daemons=true --max-pods=110 --serialize-image-pulls=false --outofdisk-transition-frequency=0
```
-* 実際に使われている`hairpin-mode`を確認します。
-これを行うには、kubeletログを確認する必要があります。
-ログへのアクセス方法は、ノードのOSによって異なります。
-一部のOSでは/var/log/kubelet.logなどのファイルですが、他のOSでは`journalctl`を使用してログにアクセスします。
-互換性のために、実際に使われている`hairpin-mode`が`--hairpin-mode`フラグと一致しない場合があることに注意してください。
-kubelet.logにキーワード`hairpin`を含むログ行があるかどうかを確認してください。
-実際に使われている`hairpin-mode`を示す以下のようなログ行があるはずです。
+* 実際に使われている`hairpin-mode`を確認します。これを行うには、kubeletログを確認する必要があります。ログへのアクセス方法は、ノードのOSによって異なります。一部のOSでは/var/log/kubelet.logなどのファイルですが、他のOSでは`journalctl`を使用してログにアクセスします。互換性のために、実際に使われている`hairpin-mode`が`--hairpin-mode`フラグと一致しない場合があることに注意してください。kubelet.logにキーワード`hairpin`を含むログ行があるかどうかを確認してください。実際に使われている`hairpin-mode`を示す以下のようなログ行があるはずです。
```none
I0629 00:51:43.648698 3252 kubelet.go:380] Hairpin mode set to "promiscuous-bridge"
```
-* 実際に使われている`hairpin-mode`が`hairpin-veth`の場合、`Kubelet`にノードの`/sys`で操作する権限があることを確認します。
-すべてが正常に機能している場合、次のようなものが表示されます。
+* 実際に使われている`hairpin-mode`が`hairpin-veth`の場合、`Kubelet`にノードの`/sys`で操作する権限があることを確認します。すべてが正常に機能している場合、次のようなものが表示されます。
```shell
for intf in /sys/devices/virtual/net/cbr0/brif/*; do cat $intf/hairpin_mode; done
@@ -634,8 +565,7 @@ for intf in /sys/devices/virtual/net/cbr0/brif/*; do cat $intf/hairpin_mode; don
1
```
-実際に使われている`hairpin-mode`が`promiscuous-bridge`の場合、`Kubelet`にノード上のLinuxブリッジを操作する権限があることを確認してください。
-`cbr0`ブリッジが使用され適切に構成されている場合、以下が表示されます。
+実際に使われている`hairpin-mode`が`promiscuous-bridge`の場合、`Kubelet`にノード上のLinuxブリッジを操作する権限があることを確認してください。`cbr0`ブリッジが使用され適切に構成されている場合、以下が表示されます。
```shell
ifconfig cbr0 |grep PROMISC
@@ -648,15 +578,9 @@ UP BROADCAST RUNNING PROMISC MULTICAST MTU:1460 Metric:1
## 助けを求める
-ここまでたどり着いたということは、とてもおかしなことが起こっています。
-Serviceは実行中で、Endpointsがあり、Podは実際にサービスを提供しています。
-DNSは動作していて、`kube-proxy`も誤動作していないようです。
-それでも、あなたのServiceは機能していません。
-おそらく私たちにお知らせ頂いた方がよいでしょう。調査をお手伝いします！
+ここまでたどり着いたということは、とてもおかしなことが起こっています。Serviceは実行中で、Endpointsがあり、Podは実際にサービスを提供しています。DNSは動作していて、`kube-proxy`も誤動作していないようです。それでも、あなたのServiceは機能していません。おそらく私たちにお知らせ頂いた方がよいでしょう。調査をお手伝いします！
-[Slack](/docs/troubleshooting/#slack)または
-[Forum](https://discuss.kubernetes.io)または
-[GitHub](https://github.com/kubernetes/kubernetes)でお問い合わせください。
+[Slack](/docs/troubleshooting/#slack)、[Forum](https://discuss.kubernetes.io)または[GitHub](https://github.com/kubernetes/kubernetes)でお問い合わせください。
diff --git a/content/ja/docs/tasks/debug-application-cluster/get-shell-running-container.md b/content/ja/docs/tasks/debug-application-cluster/get-shell-running-container.md
index b6825075b8..684fa981c1 100644
--- a/content/ja/docs/tasks/debug-application-cluster/get-shell-running-container.md
+++ b/content/ja/docs/tasks/debug-application-cluster/get-shell-running-container.md
@@ -47,7 +47,7 @@ kubectl exec -it shell-demo -- /bin/bash
```
{{< note >}}
-ダブルダッシュの記号 "--" はコマンドに渡す引数とkubectlの引数を分離します。
+ダブルダッシュの記号 `--` はコマンドに渡す引数とkubectlの引数を分離します。
{{< /note >}}
diff --git a/content/ja/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md b/content/ja/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md
new file mode 100644
index 0000000000..a6679de198
--- /dev/null
+++ b/content/ja/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md
@@ -0,0 +1,149 @@
+---
+title: 環境変数によりコンテナにPod情報を共有する
+content_type: task
+weight: 30
+---
+
+
+
+このページでは、Podが内部で実行しているコンテナに自身の情報を共有する方法を説明します。環境変数ではPodのフィールドとコンテナのフィールドを共有することができます。
+
+
+
+
+## {{% heading "prerequisites" %}}
+
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+
+
+
+
+
+## Downward API {#the-downward-api}
+
+Podとコンテナのフィールドを実行中のコンテナに共有する方法は2つあります:
+
+* 環境変数
+* [ボリュームファイル](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#the-downward-api)
+
+これら2つの方法を合わせて、Podとコンテナフィールドを共有する方法を*Downward API*と呼びます。
+
+
+## Podフィールドを環境変数の値として使用する {#use-pod-fields-as-values-for-environment-variables}
+
+この演習では、1つのコンテナを持つPodを作成します。Podの設定ファイルは次のとおりです:
+
+{{< codenew file="pods/inject/dapi-envars-pod.yaml" >}}
+
+設定ファイルには、5つの環境変数があります。`env`フィールドは[EnvVars](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvar-v1-core)の配列です。配列の最初の要素では、環境変数`MY_NODE_NAME`の値をPodの`spec.nodeName`フィールドから取得することを指定します。同様に、他の環境変数もPodのフィールドから名前を取得します。
+
+{{< note >}}
+この例のフィールドはPodのフィールドです。これらはPod内のコンテナのフィールドではありません。
+{{< /note >}}
+
+Podを作成します:
+
+```shell
+kubectl apply -f https://k8s.io/examples/pods/inject/dapi-envars-pod.yaml
+```
+
+Podのコンテナが実行されていることを確認します:
+
+```shell
+kubectl get pods
+```
+
+コンテナのログを表示します:
+
+```shell
+kubectl logs dapi-envars-fieldref
+```
+
+出力には、選択した環境変数の値が表示されます:
+
+```
+minikube
+dapi-envars-fieldref
+default
+172.17.0.4
+default
+```
+
+これらの値がログにある理由を確認するには、設定ファイルの`command`および`args`フィールドを確認してください。コンテナが起動すると、5つの環境変数の値が標準出力に書き込まれます。これを10秒ごとに繰り返します。
+
+次に、Podで実行しているコンテナへのシェルを取得します:
+
+```shell
+kubectl exec -it dapi-envars-fieldref -- sh
+```
+
+シェルで環境変数を表示します:
+
+```shell
+/# printenv
+```
+
+出力は、特定の環境変数にPodフィールドの値が割り当てられていることを示しています:
+
+```
+MY_POD_SERVICE_ACCOUNT=default
+...
+MY_POD_NAMESPACE=default
+MY_POD_IP=172.17.0.4
+...
+MY_NODE_NAME=minikube
+...
+MY_POD_NAME=dapi-envars-fieldref
+```
+
+## コンテナフィールドを環境変数の値として使用する {#use-container-fields-as-values-for-environment-variables}
+
+前の演習では、環境変数の値としてPodフィールドを使用しました。次の演習では、環境変数の値としてコンテナフィールドを使用します。これは、1つのコンテナを持つPodの設定ファイルです:
+
+{{< codenew file="pods/inject/dapi-envars-container.yaml" >}}
+
+設定ファイルには、4つの環境変数があります。`env`フィールドは[EnvVars](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvar-v1-core)の配列です。配列の最初の要素では、環境変数`MY_CPU_REQUEST`の値を`test-container`という名前のコンテナの`requests.cpu`フィールドから取得することを指定します。同様に、他の環境変数もコンテナのフィールドから値を取得します。
+
+Podを作成します:
+
+```shell
+kubectl apply -f https://k8s.io/examples/pods/inject/dapi-envars-container.yaml
+```
+
+Podのコンテナが実行されていることを確認します:
+
+```shell
+kubectl get pods
+```
+
+コンテナのログを表示します:
+
+```shell
+kubectl logs dapi-envars-resourcefieldref
+```
+
+出力には、選択した環境変数の値が表示されます:
+
+```
+1
+1
+33554432
+67108864
+```
+
+
+
+## {{% heading "whatsnext" %}}
+
+
+* [コンテナの環境変数の定義](/ja/docs/tasks/inject-data-application/define-environment-variable-container/)
+* [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)
+* [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
+* [EnvVar](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvar-v1-core)
+* [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core)
+* [ObjectFieldSelector](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#objectfieldselector-v1-core)
+* [ResourceFieldSelector](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcefieldselector-v1-core)
+
+
diff --git a/content/ja/docs/tasks/manage-gpus/scheduling-gpus.md b/content/ja/docs/tasks/manage-gpus/scheduling-gpus.md
new file mode 100644
index 0000000000..b4a01a7bd7
--- /dev/null
+++ b/content/ja/docs/tasks/manage-gpus/scheduling-gpus.md
@@ -0,0 +1,184 @@
+---
+content_type: concept
+title: GPUのスケジューリング
+description: クラスター内のノードのリソースとしてGPUを設定してスケジューリングします
+---
+
+
+
+{{< feature-state state="beta" for_k8s_version="v1.10" >}}
+
+Kubernetesには、複数ノードに搭載されたAMDおよびNVIDIAのGPU(graphical processing unit)を管理するための**実験的な**サポートが含まれています。
+
+このページでは、異なるバージョンのKubernetesを横断してGPUを使用する方法と、現時点での制限について説明します。
+
+
+
+## デバイスプラグインを使用する
+
+Kubernetesでは、GPUなどの特別なハードウェアの機能にPodがアクセスできるようにするために、{{< glossary_tooltip text="デバイスプラグイン" term_id="device-plugin" >}}が実装されています。
+
+管理者として、ノード上に対応するハードウェアベンダーのGPUドライバーをインストールして、以下のような対応するGPUベンダーのデバイスプラグインを実行する必要があります。
+
+* [AMD](#deploying-amd-gpu-device-plugin)
+* [NVIDIA](#deploying-nvidia-gpu-device-plugin)
+
+上記の条件を満たしていれば、Kubernetesは`amd.com/gpu`または`nvidia.com/gpu`をスケジュール可能なリソースとして公開します。
+
+これらのGPUをコンテナから使用するには、`cpu`や`memory`をリクエストするのと同じように`.com/gpu`というリソースをリクエストするだけです。ただし、GPUを使用するときにはリソースのリクエストの指定方法にいくつか制限があります。
+
+- GPUは`limits`セクションでのみ指定されることが想定されている。この制限は、次のことを意味します。
+ * Kubernetesはデフォルトでlimitの値をrequestの値として使用するため、GPUの`requests`を省略して`limits`を指定できる。
+ * GPUを`limits`と`requests`の両方で指定できるが、これら2つの値は等しくなければならない。
+ * GPUの`limits`を省略して`requests`だけを指定することはできない。
+- コンテナ(およびPod)はGPUを共有しない。GPUのオーバーコミットは起こらない。
+- 各コンテナは1つ以上のGPUをリクエストできる。1つのGPUの一部だけをリクエストすることはできない。
+
+以下に例を示します。
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+ name: cuda-vector-add
+spec:
+ restartPolicy: OnFailure
+ containers:
+ - name: cuda-vector-add
+ # https://github.com/kubernetes/kubernetes/blob/v1.7.11/test/images/nvidia-cuda/Dockerfile
+ image: "k8s.gcr.io/cuda-vector-add:v0.1"
+ resources:
+ limits:
+ nvidia.com/gpu: 1 # 1 GPUをリクエストしています
+```
+
+### AMDのGPUデバイスプラグインをデプロイする {#deploying-amd-gpu-device-plugin}
+
+[AMD公式のGPUデバイスプラグイン](https://github.com/RadeonOpenCompute/k8s-device-plugin)には以下の要件があります。
+
+- Kubernetesのノードに、AMDのGPUのLinuxドライバーがあらかじめインストール済みでなければならない。
+
+クラスターが起動して上記の要件が満たされれば、以下のコマンドを実行することでAMDのデバイスプラグインをデプロイできます。
+
+```shell
+kubectl create -f https://raw.githubusercontent.com/RadeonOpenCompute/k8s-device-plugin/v1.10/k8s-ds-amdgpu-dp.yaml
+```
+
+このサードパーティーのデバイスプラグインに関する問題は、[RadeonOpenCompute/k8s-device-plugin](https://github.com/RadeonOpenCompute/k8s-device-plugin)で報告できます。
+
+### NVIDIAのGPUデバイスプラグインをデプロイする {#deploying-nvidia-gpu-device-plugin}
+
+現在、NVIDIAのGPU向けのデバイスプラグインの実装は2種類あります。
+
+#### NVIDIA公式のGPUデバイスプラグイン
+
+[NVIDIA公式のGPUデバイスプラグイン](https://github.com/NVIDIA/k8s-device-plugin)には以下の要件があります。
+
+- Kubernetesのノードに、NVIDIAのドライバーがあらかじめインストール済みでなければならない。
+- Kubernetesのノードに、[nvidia-docker 2.0](https://github.com/NVIDIA/nvidia-docker)があらかじめインストール済みでなければならない。
+- KubeletはコンテナランタイムにDockerを使用しなければならない。
+- runcの代わりにDockerの[デフォルトランタイム](https://github.com/NVIDIA/k8s-device-plugin#preparing-your-gpu-nodes)として、`nvidia-container-runtime`を設定しなければならない。
+- NVIDIAのドライバーのバージョンが次の条件を満たさなければならない ~= 384.81。
+
+クラスターが起動して上記の要件が満たされれば、以下のコマンドを実行することでNVIDIAのデバイスプラグインがデプロイできます。
+
+```shell
+kubectl create -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/1.0.0-beta4/nvidia-device-plugin.yml
+```
+
+このサードパーティーのデバイスプラグインに関する問題は、[NVIDIA/k8s-device-plugin](https://github.com/NVIDIA/k8s-device-plugin)で報告できます。
+
+#### GCEで使用されるNVIDIAのGPUデバイスプラグイン
+
+[GCEで使用されるNVIDIAのGPUデバイスプラグイン](https://github.com/GoogleCloudPlatform/container-engine-accelerators/tree/master/cmd/nvidia_gpu)は、nvidia-dockerを必要としないため、KubernetesのContainer Runtime Interface(CRI)と互換性のある任意のコンテナランタイムで動作するはずです。このデバイスプラグインは[Container-Optimized OS](https://cloud.google.com/container-optimized-os/)でテストされていて、1.9以降ではUbuntu向けの実験的なコードも含まれています。
+
+以下のコマンドを実行すると、NVIDIAのドライバーとデバイスプラグインをインストールできます。
+
+```shell
+# NVIDIAドライバーをContainer-Optimized OSにインストールする
+kubectl create -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/stable/daemonset.yaml
+
+# NVIDIAドライバーをUbuntuにインストールする(実験的)
+kubectl create -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/stable/nvidia-driver-installer/ubuntu/daemonset.yaml
+
+# デバイスプラグインをインストールする
+kubectl create -f https://raw.githubusercontent.com/kubernetes/kubernetes/release-1.14/cluster/addons/device-plugins/nvidia-gpu/daemonset.yaml
+```
+
+このサードパーティーのデバイスプラグインの使用やデプロイに関する問題は、[GoogleCloudPlatform/container-engine-accelerators](https://github.com/GoogleCloudPlatform/container-engine-accelerators)で報告できます。
+
+Googleは、GKE上でNVIDIAのGPUを使用するための[手順](https://cloud.google.com/kubernetes-engine/docs/how-to/gpus)も公開しています。
+
+## 異なる種類のGPUを搭載するクラスター
+
+クラスター上の別のノードに異なる種類のGPUが搭載されている場合、[NodeラベルとNodeセレクター](/docs/tasks/configure-pod-container/assign-pods-nodes/)を使用することで、Podを適切なノードにスケジューリングできます。
+
+以下に例を示します。
+
+```shell
+# アクセラレーターを搭載したノードにラベルを付けます。
+kubectl label nodes accelerator=nvidia-tesla-k80
+kubectl label nodes accelerator=nvidia-tesla-p100
+```
+
+## 自動的なNodeラベルの付加 {#node-labeller}
+
+AMDのGPUデバイスを使用している場合、[Node Labeller](https://github.com/RadeonOpenCompute/k8s-device-plugin/tree/master/cmd/k8s-node-labeller)をデプロイできます。Node Labellerは{{< glossary_tooltip text="コントローラー" term_id="controller" >}}の1種で、GPUデバイスのプロパティを持つノードに自動的にラベルを付けてくれます。
+
+現在は、このコントローラーは以下のプロパティに基づいてラベルを追加できます。
+
+* デバイスID(-device-id)
+* VRAMのサイズ(-vram)
+* SIMDの数(-simd-count)
+* Compute Unitの数(-cu-count)
+* ファームウェアとフィーチャーのバージョン(-firmware)
+* 2文字の頭字語で表されたGPUファミリー(-family)
+ * SI - Southern Islands
+ * CI - Sea Islands
+ * KV - Kaveri
+ * VI - Volcanic Islands
+ * CZ - Carrizo
+ * AI - Arctic Islands
+ * RV - Raven
+
+```shell
+kubectl describe node cluster-node-23
+```
+
+```
+ Name: cluster-node-23
+ Roles:
+ Labels: beta.amd.com/gpu.cu-count.64=1
+ beta.amd.com/gpu.device-id.6860=1
+ beta.amd.com/gpu.family.AI=1
+ beta.amd.com/gpu.simd-count.256=1
+ beta.amd.com/gpu.vram.16G=1
+ beta.kubernetes.io/arch=amd64
+ beta.kubernetes.io/os=linux
+ kubernetes.io/hostname=cluster-node-23
+ Annotations: kubeadm.alpha.kubernetes.io/cri-socket: /var/run/dockershim.sock
+ node.alpha.kubernetes.io/ttl: 0
+ …
+```
+
+Node Labellerを使用すると、GPUの種類をPodのspec内で指定できます。
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+ name: cuda-vector-add
+spec:
+ restartPolicy: OnFailure
+ containers:
+ - name: cuda-vector-add
+ # https://github.com/kubernetes/kubernetes/blob/v1.7.11/test/images/nvidia-cuda/Dockerfile
+ image: "k8s.gcr.io/cuda-vector-add:v0.1"
+ resources:
+ limits:
+ nvidia.com/gpu: 1
+ nodeSelector:
+ accelerator: nvidia-tesla-p100 # または nvidia-tesla-k80 など
+```
+
+これにより、指定した種類のGPUを搭載したノードにPodがスケジューリングされることを保証できます。
diff --git a/content/ja/docs/tasks/run-application/force-delete-stateful-set-pod.md b/content/ja/docs/tasks/run-application/force-delete-stateful-set-pod.md
index efa6f5a6ae..7d6830a50f 100644
--- a/content/ja/docs/tasks/run-application/force-delete-stateful-set-pod.md
+++ b/content/ja/docs/tasks/run-application/force-delete-stateful-set-pod.md
@@ -21,7 +21,7 @@ weight: 70
StatefulSetの通常の操作では、StatefulSet Podを強制的に削除する必要は**まったく**ありません。StatefulSetコントローラーは、StatefulSetのメンバーの作成、スケール、削除を行います。それは序数0からN-1までの指定された数のPodが生きていて準備ができていることを保証しようとします。StatefulSetは、クラスター内で実行されている特定のIDを持つ最大1つのPodがいつでも存在することを保証します。これは、StatefulSetによって提供される*最大1つの*セマンティクスと呼ばれます。
-手動による強制削除は、StatefulSetに固有の最大1つのセマンティクスに違反する可能性があるため、慎重に行う必要があります。StatefulSetを使用して、安定したネットワークIDと安定した記憶域を必要とする分散型およびクラスター型アプリケーションを実行できます。これらのアプリケーションは、固定IDを持つ固定数のメンバーのアンサンブルに依存する構成を持つことがよくあります。同じIDを持つ複数のメンバーを持つことは悲惨なことになり、データの損失につながる可能性があります（例：定足数ベースのシステムでのスプリットブレインシナリオ）。
+手動による強制削除は、StatefulSetに固有の最大1つのセマンティクスに違反する可能性があるため、慎重に行う必要があります。StatefulSetを使用して、安定したネットワークIDと安定した記憶域を必要とする分散型およびクラスター型アプリケーションを実行できます。これらのアプリケーションは、固定IDを持つ固定数のメンバーのアンサンブルに依存する構成を持つことがよくあります。同じIDを持つ複数のメンバーを持つことは悲惨なことになり、データの損失につながる可能性があります(例：定足数ベースのシステムでのスプリットブレインシナリオ)。
## Podの削除
@@ -33,13 +33,13 @@ kubectl delete pods
上記がグレースフルターミネーションにつながるためには、`pod.Spec.TerminationGracePeriodSeconds`に0を指定しては**いけません**。`pod.Spec.TerminationGracePeriodSeconds`を0秒に設定することは安全ではなく、StatefulSet Podには強くお勧めできません。グレースフル削除は安全で、kubeletがapiserverから名前を削除する前に[Podが適切にシャットダウンする](/ja/docs/concepts/workloads/pods/pod/#termination-of-pods)ことを保証します。
-Kubernetes（バージョン1.5以降）は、Nodeにアクセスできないという理由だけでPodを削除しません。到達不能なNodeで実行されているPodは、[タイムアウト](/docs/admin/node/#node-condition)の後に`Terminating`または`Unknown`状態になります。到達不能なNode上のPodをユーザーが適切に削除しようとすると、Podはこれらの状態に入ることもあります。そのような状態のPodをapiserverから削除することができる唯一の方法は以下の通りです:
+Kubernetes(バージョン1.5以降)は、Nodeにアクセスできないという理由だけでPodを削除しません。到達不能なNodeで実行されているPodは、[タイムアウト](/docs/admin/node/#node-condition)の後に`Terminating`または`Unknown`状態になります。到達不能なNode上のPodをユーザーが適切に削除しようとすると、Podはこれらの状態に入ることもあります。そのような状態のPodをapiserverから削除することができる唯一の方法は以下の通りです:
* (ユーザーまたは[Node Controller](/docs/admin/node)によって)Nodeオブジェクトが削除されます。
* 応答していないNodeのkubeletが応答を開始し、Podを終了してapiserverからエントリーを削除します。
* ユーザーによりPodを強制削除します。
-推奨されるベストプラクティスは、1番目または2番目のアプローチを使用することです。Nodeが死んでいることが確認された（例えば、ネットワークから恒久的に切断された、電源が切られたなど）場合、Nodeオブジェクトを削除します。Nodeがネットワークパーティションに苦しんでいる場合は、これを解決するか、解決するのを待ちます。パーティションが回復すると、kubeletはPodの削除を完了し、apiserverでその名前を解放します。
+推奨されるベストプラクティスは、1番目または2番目のアプローチを使用することです。Nodeが死んでいることが確認された(例えば、ネットワークから恒久的に切断された、電源が切られたなど)場合、Nodeオブジェクトを削除します。Nodeがネットワークパーティションに苦しんでいる場合は、これを解決するか、解決するのを待ちます。パーティションが回復すると、kubeletはPodの削除を完了し、apiserverでその名前を解放します。
通常、PodがNode上で実行されなくなるか、管理者によってそのNodeが削除されると、システムは削除を完了します。あなたはPodを強制的に削除することでこれを無効にすることができます。
diff --git a/content/ja/docs/tasks/service-catalog/_index.md b/content/ja/docs/tasks/service-catalog/_index.md
new file mode 100755
index 0000000000..a7d91e4ea7
--- /dev/null
+++ b/content/ja/docs/tasks/service-catalog/_index.md
@@ -0,0 +1,6 @@
+---
+title: "サービスカタログ"
+description: サービスカタログ拡張APIをインストールする
+weight: 150
+---
+
diff --git a/content/ja/docs/tasks/service-catalog/install-service-catalog-using-sc.md b/content/ja/docs/tasks/service-catalog/install-service-catalog-using-sc.md
new file mode 100644
index 0000000000..a0211e2a18
--- /dev/null
+++ b/content/ja/docs/tasks/service-catalog/install-service-catalog-using-sc.md
@@ -0,0 +1,68 @@
+---
+title: SCを使用したサービスカタログのインストール
+content_type: task
+---
+
+
+{{< glossary_definition term_id="service-catalog" length="all" prepend="サービスカタログは" >}}
+
+GCPの[Service Catalog Installer](https://github.com/GoogleCloudPlatform/k8s-service-catalog#installation)ツールを使うと、Kubernetesクラスター上にサービスカタログを簡単にインストール・アンインストールして、Google Cloudのプロジェクトに紐付けることもできます。
+
+サービスカタログ自体は、Google Cloudだけではなく、どのような種類のマネージドサービスでも動作します。
+
+## {{% heading "prerequisites" %}}
+
+* [サービスカタログ](/docs/concepts/service-catalog/)の基本概念を理解してください。
+* [Go 1.6+](https://golang.org/dl/)をインストールして、`GOPATH`を設定してください。
+* SSLに関するファイルを生成するために必要な[cfssl](https://github.com/cloudflare/cfssl)ツールをインストールしてください。
+* サービスカタログを使用するには、Kubernetesクラスターのバージョンが1.7以降である必要があります。
+* [kubectlのインストールおよびセットアップ](/ja/docs/tasks/tools/install-kubectl/)を参考に、v1.7以降のkubectlをインストールし、設定を行ってください。
+* サービスカタログをインストールするためには、kubectlのユーザーが*cluster-admin*ロールにバインドされている必要があります。正しくバインドされていることを確認するには、次のコマンドを実行します。
+
+ kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin --user=
+
+
+## ローカル環境に`sc`をインストールする
+
+インストーラーは、ローカルのコンピューター上で`sc`と呼ばれるCLIツールとして実行します。
+
+`go get`を使用してインストールします。
+
+```shell
+go get github.com/GoogleCloudPlatform/k8s-service-catalog/installer/cmd/sc
+```
+
+これで、`sc`が`GOPATH/bin`ディレクトリー内にインストールされたはずです。
+
+## Kubernetesクラスターにサービスカタログをインストールする
+
+まず、すべての依存関係がインストールされていることを確認します。次のコマンドを実行してください。
+
+```shell
+sc check
+```
+
+チェックが成功したら、次のように表示されるはずです。
+
+```
+Dependency check passed. You are good to go.
+```
+
+次に、バックアップに使用したい`storageclass`を指定して、installコマンドを実行します。
+
+```shell
+sc install --etcd-backup-storageclass "standard"
+```
+
+## サービスカタログのアンインストール
+
+Kubernetesクラスターからサービスカタログをアンインストールしたい場合は、`sc`ツールを使って次のコマンドを実行します。
+
+```shell
+sc uninstall
+```
+
+## {{% heading "whatsnext" %}}
+
+* [サービスブローカーのサンプル](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers)を読む。
+* [kubernetes-incubator/service-catalog](https://github.com/kubernetes-incubator/service-catalog)プロジェクトを探索する。
diff --git a/content/ja/docs/tasks/tools/install-kubectl.md b/content/ja/docs/tasks/tools/install-kubectl.md
index 7c0d08d9c5..e468404469 100644
--- a/content/ja/docs/tasks/tools/install-kubectl.md
+++ b/content/ja/docs/tasks/tools/install-kubectl.md
@@ -5,7 +5,7 @@ weight: 10
card:
name: tasks
weight: 20
- title: Install kubectl
+ title: kubectlのインストール
---
@@ -143,7 +143,7 @@ macOSで[Homebrew](https://brew.sh/)パッケージマネージャーを使用
1. インストールコマンドを実行してください:
```
- brew install kubectl
+ brew install kubectl
```
または
@@ -186,7 +186,7 @@ macOSで[MacPorts](https://macports.org/)パッケージマネージャーを使
curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe
```
- 最新の安定版を入手する際は（たとえばスクリプトで使用する場合）、[https://storage.googleapis.com/kubernetes-release/release/stable.txt](https://storage.googleapis.com/kubernetes-release/release/stable.txt)を参照してください。
+ 最新の安定版を入手する際は(たとえばスクリプトで使用する場合)、[https://storage.googleapis.com/kubernetes-release/release/stable.txt](https://storage.googleapis.com/kubernetes-release/release/stable.txt)を参照してください。
2. バイナリをPATHに追加します
3. `kubectl`のバージョンがダウンロードしたものと同じであることを確認してください:
@@ -202,7 +202,7 @@ macOSで[MacPorts](https://macports.org/)パッケージマネージャーを使
Windowsで[Powershell Gallery](https://www.powershellgallery.com/)パッケージマネージャーを使用していれば、Powershellでkubectlをインストールおよびアップデートすることもできます。
-1. インストールコマンドを実行してください（必ず`DownloadLocation`を指定してください）:
+1. インストールコマンドを実行してください(必ず`DownloadLocation`を指定してください):
```
Install-Script -Name install-kubectl -Scope CurrentUser -Force
@@ -301,7 +301,7 @@ URLのレスポンスが表示されている場合は、kubectlはクラスタ
The connection to the server was refused - did you specify the right host or port?
```
-たとえば、ラップトップ上（ローカル環境）でKubernetesクラスターを起動するような場合、Minikubeなどのツールを最初にインストールしてから、上記のコマンドを再実行する必要があります。
+たとえば、ラップトップ上(ローカル環境)でKubernetesクラスターを起動するような場合、Minikubeなどのツールを最初にインストールしてから、上記のコマンドを再実行する必要があります。
kubectl cluster-infoがURLレスポンスを返したにもかかわらずクラスターにアクセスできない場合は、次のコマンドで設定が正しいことを確認してください:
@@ -315,7 +315,7 @@ kubectl cluster-info dump
kubectlはBashおよびZshの自動補完を提供しています。これにより、入力を大幅に削減することができます。
-以下にBash（LinuxとmacOSの違いも含む）およびZshの自動補完の設定手順を示します。
+以下にBash(LinuxとmacOSの違いも含む)およびZshの自動補完の設定手順を示します。
{{< tabs name="kubectl_autocompletion" >}}
@@ -325,11 +325,11 @@ kubectlはBashおよびZshの自動補完を提供しています。これによ
Bashにおけるkubectlの補完スクリプトは`kubectl completion bash`コマンドで生成できます。シェル内で補完スクリプトをsourceすることでkubectlの自動補完が有効になります。
-ただし、補完スクリプトは[**bash-completion**](https://github.com/scop/bash-completion)に依存しているため、このソフトウェアを最初にインストールしておく必要があります（`type _init_completion`を実行することで、bash-completionがすでにインストールされていることを確認できます）。
+ただし、補完スクリプトは[**bash-completion**](https://github.com/scop/bash-completion)に依存しているため、このソフトウェアを最初にインストールしておく必要があります(`type _init_completion`を実行することで、bash-completionがすでにインストールされていることを確認できます)。
### bash-completionをインストールする
-bash-completionは多くのパッケージマネージャーから提供されています（[こちら](https://github.com/scop/bash-completion#installation)を参照してください）。`apt-get install bash-completion`または`yum install bash-completion`などでインストールできます。
+bash-completionは多くのパッケージマネージャーから提供されています([こちら](https://github.com/scop/bash-completion#installation)を参照してください)。`apt-get install bash-completion`または`yum install bash-completion`などでインストールできます。
上記のコマンドでbash-completionの主要スクリプトである`/usr/share/bash-completion/bash_completion`が作成されます。パッケージマネージャーによっては、このファイルを`~/.bashrc`にて手動でsourceする必要があります。
@@ -382,7 +382,7 @@ Bashにおけるkubectlの補完スクリプトは`kubectl completion bash`コ
ただし、補完スクリプトは[**bash-completion**](https://github.com/scop/bash-completion)に依存しているため、事前にインストールする必要があります。
{{< warning>}}
-bash-completionにはv1とv2のバージョンがあり、v1はBash 3.2（macOSのデフォルト）用で、v2はBash 4.1以降向けです。kubectlの補完スクリプトはbash-completionのv1とBash 3.2では正しく**動作しません**。**bash-completion v2**および**Bash 4.1**が必要になります。したがって、macOSで正常にkubectlの補完を使用するには、Bash 4.1以降をインストールする必要があります([*手順*](https://itnext.io/upgrading-bash-on-macos-7138bd1066ba))。以下の手順では、Bash4.1以降（Bashのバージョンが4.1またはそれより新しいことを指します）を使用することを前提とします。
+bash-completionにはv1とv2のバージョンがあり、v1はBash 3.2(macOSのデフォルト)用で、v2はBash 4.1以降向けです。kubectlの補完スクリプトはbash-completionのv1とBash 3.2では正しく**動作しません**。**bash-completion v2**および**Bash 4.1**が必要になります。したがって、macOSで正常にkubectlの補完を使用するには、Bash 4.1以降をインストールする必要があります([*手順*](https://itnext.io/upgrading-bash-on-macos-7138bd1066ba))。以下の手順では、Bash4.1以降(Bashのバージョンが4.1またはそれより新しいことを指します)を使用することを前提とします。
{{< /warning >}}
### bashのアップグレード
@@ -410,7 +410,7 @@ Homebrewは通常、`/usr/local/bin/bash`にインストールします。
### bash-completionをインストールする
{{< note >}}
-前述のとおり、この手順ではBash 4.1以降であることが前提のため、bash-completion v2をインストールすることになります（これとは逆に、Bash 3.2およびbash-completion v1の場合ではkubectlの補完は動作しません）。
+前述のとおり、この手順ではBash 4.1以降であることが前提のため、bash-completion v2をインストールすることになります(これとは逆に、Bash 3.2およびbash-completion v1の場合ではkubectlの補完は動作しません)。
{{< /note >}}
`type _init_completion`を実行することで、bash-completionがすでにインストールされていることを確認できます。ない場合は、Homebrewを使用してインストールすることもできます:
@@ -452,7 +452,7 @@ export BASH_COMPLETION_COMPAT_DIR="/usr/local/etc/bash_completion.d"
echo 'complete -F __start_kubectl k' >>~/.bashrc
```
-- kubectlをHomwbrewでインストールした場合（[前述](#homebrewを使用してmacosへインストールする)のとおり）、kubectlの補完スクリプトはすでに`/usr/local/etc/bash_completion.d/kubectl`に格納されているでしょう。この場合、なにも操作する必要はありません。
+- kubectlをHomwbrewでインストールした場合([前述](#homebrewを使用してmacosへインストールする)のとおり)、kubectlの補完スクリプトはすでに`/usr/local/etc/bash_completion.d/kubectl`に格納されているでしょう。この場合、なにも操作する必要はありません。
{{< note >}}
Homebrewでインストールしたbash-completion v2は`BASH_COMPLETION_COMPAT_DIR`ディレクトリ内のすべてのファイルをsourceするため、後者の2つの方法が機能します。
diff --git a/content/ja/docs/tasks/tools/install-minikube.md b/content/ja/docs/tasks/tools/install-minikube.md
index 51e6cd8417..30b15718ca 100644
--- a/content/ja/docs/tasks/tools/install-minikube.md
+++ b/content/ja/docs/tasks/tools/install-minikube.md
@@ -29,7 +29,7 @@ grep -E --color 'vmx|svm' /proc/cpuinfo
```
sysctl -a | grep -E --color 'machdep.cpu.features|VMX'
```
-出力に`VMX`が表示されている場合（色付けされているはずです）、VT-x機能がマシンで有効になっています。
+出力に`VMX`が表示されている場合(色付けされているはずです)、VT-x機能がマシンで有効になっています。
{{% /tab %}}
{{% tab name="Windows" %}}
diff --git a/content/ja/docs/tutorials/kubernetes-basics/_index.html b/content/ja/docs/tutorials/kubernetes-basics/_index.html
index 99174c2b21..3f31b8d5bc 100644
--- a/content/ja/docs/tutorials/kubernetes-basics/_index.html
+++ b/content/ja/docs/tutorials/kubernetes-basics/_index.html
@@ -39,7 +39,7 @@ card:
-
Kubernetesはどんなことができるの?
+
Kubernetesはどんなことができるの？
モダンなWebサービスでは、ユーザはアプリケーションが24時間365日利用可能であることを期待しており、開発者はそれらのアプリケーションの新しいバージョンを1日に数回デプロイすることを期待しています。コンテナ化は、パッケージソフトウェアがこれらの目標を達成するのを助け、アプリケーションをダウンタイムなしで簡単かつ迅速にリリース、アップデートできるようにします。Kubernetesを使用すると、コンテナ化されたアプリケーションをいつでもどこでも好きなときに実行できるようになり、それらが機能するために必要なリソースとツールを見つけやすくなります。Kubernetesは、コンテナオーケストレーションにおけるGoogleのこれまでの経験と、コミュニティから得られた最善のアイデアを組み合わせて設計された、プロダクションレディなオープンソースプラットフォームです。
diff --git a/content/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html b/content/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
index c9d25cd3fb..9b59db721b 100644
--- a/content/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
+++ b/content/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
@@ -20,7 +20,7 @@ weight: 20
- Podは、Kubernetesアプリケーションの基本的な実行単位です。各Podは、クラスターで実行されているワークロードの一部を表します。Podの詳細はこちらです。。
+ Podは、Kubernetesアプリケーションの基本的な実行単位です。各Podは、クラスターで実行されているワークロードの一部を表します。Podの詳細はこちらです。
diff --git a/content/ja/docs/tutorials/services/_index.md b/content/ja/docs/tutorials/services/_index.md
new file mode 100755
index 0000000000..2a2a0eb7b6
--- /dev/null
+++ b/content/ja/docs/tutorials/services/_index.md
@@ -0,0 +1,5 @@
+---
+title: "Service"
+weight: 70
+---
+
diff --git a/content/ja/docs/tutorials/services/source-ip.md b/content/ja/docs/tutorials/services/source-ip.md
new file mode 100644
index 0000000000..69c626d532
--- /dev/null
+++ b/content/ja/docs/tutorials/services/source-ip.md
@@ -0,0 +1,421 @@
+---
+title: 送信元IPを使用する
+content_type: tutorial
+min-kubernetes-server-version: v1.5
+---
+
+
+
+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を保持することに関わるトレードオフを理解する
+
+
+
+## `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 2h v1.13.0
+kubernetes-node-cx31 Ready 2h v1.13.0
+kubernetes-node-jj1t Ready 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 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: 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: 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/)方法について学ぶ。
+
+
diff --git a/content/ja/docs/tutorials/stateful-application/_index.md b/content/ja/docs/tutorials/stateful-application/_index.md
new file mode 100755
index 0000000000..421915d42c
--- /dev/null
+++ b/content/ja/docs/tutorials/stateful-application/_index.md
@@ -0,0 +1,5 @@
+---
+title: "ステートフルアプリケーション"
+weight: 50
+---
+
diff --git a/content/ja/docs/tutorials/stateful-application/basic-stateful-set.md b/content/ja/docs/tutorials/stateful-application/basic-stateful-set.md
new file mode 100644
index 0000000000..d8a0acbdf6
--- /dev/null
+++ b/content/ja/docs/tutorials/stateful-application/basic-stateful-set.md
@@ -0,0 +1,1026 @@
+---
+title: StatefulSetの基本
+content_type: tutorial
+weight: 10
+---
+
+
+このチュートリアルでは、{{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}を使用したアプリケーションを管理するための基本を説明します。StatefulSetのPodを作成、削除、スケール、そして更新する方法について紹介します。
+
+## {{% heading "prerequisites" %}}
+
+このチュートリアルを始める前に、以下のKubernetesの概念について理解しておく必要があります。
+
+* [Pod](/ja/docs/concepts/workloads/pods/)
+* [Cluster DNS](/ja/docs/concepts/services-networking/dns-pod-service/)
+* [Headless Service](/ja/docs/concepts/services-networking/service/#headless-services)
+* [PersistentVolume](/ja/docs/concepts/storage/persistent-volumes/)
+* [PersistentVolumeのプロビジョニング](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/)
+* [StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/)
+* [kubectl](/docs/reference/kubectl/kubectl/)コマンドラインツール
+
+{{< note >}}
+このチュートリアルでは、クラスターがPersistentVolumeの動的なプロビジョニングが行われるように設定されていることを前提としています。クラスターがそのように設定されていない場合、チュートリアルを始める前に1GiBのボリュームを2つ手動でプロビジョニングする必要があります。
+{{< /note >}}
+
+## {{% heading "objectives" %}}
+
+StatefulSetはステートフルアプリケーションや分散システムで使用するために存在します。しかし、Kubernetes上のステートフルアプリケーションや分散システムは、広範で複雑なトピックです。StatefulSetの基本的な機能を示すという目的のため、また、ステートフルアプリケーションを分散システムと混同しないようにするために、ここでは、Statefulsetを使用する単純なウェブアプリケーションのデプロイを行います。
+
+このチュートリアルを終えると、以下のことが理解できるようになります。
+
+* StatefulSetの作成方法
+* StatefulSetがどのようにPodを管理するのか
+* StatefulSetの削除方法
+* StatefulSetのスケール方法
+* StatefulSetが管理するPodの更新方法
+
+
+
+## StatefulSetを作成する {#ordered-pod-creation}
+
+はじめに、以下の例を使ってStatefulSetを作成しましょう。これは、コンセプトの[StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/)のページで使ったものと同じような例です。`nginx`という[headless Service](/ja/docs/concepts/services-networking/service/#headless-services)を作成し、`web`というStatefulSet内のPodのIPアドレスを公開します。
+
+{{< codenew file="application/web/web.yaml" >}}
+
+上の例をダウンロードして、`web.yaml`という名前で保存します。
+
+ここでは、ターミナルウィンドウを2つ使う必要があります。1つ目のターミナルでは、[`kubectl get`](/ja/docs/reference/generated/kubectl/kubectl-commands/#get)を使って、StatefulSetのPodの作成を監視します。
+
+```shell
+kubectl get pods -w -l app=nginx
+```
+
+2つ目のターミナルでは、[`kubectl apply`](/ja/docs/reference/generated/kubectl/kubectl-commands/#apply)を使って、`web.yaml`に定義されたheadless ServiceとStatefulSetを作成します。
+
+```shell
+kubectl apply -f web.yaml
+```
+```
+service/nginx created
+statefulset.apps/web created
+```
+
+上のコマンドを実行すると、2つのPodが作成され、それぞれのPodで[NGINX](https://www.nginx.com)ウェブサーバーが実行されます。`nginx`Serviceを取得してみましょう。
+```shell
+kubectl get service nginx
+```
+```
+NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
+nginx ClusterIP None 80/TCP 12s
+```
+そして、`web`StatefulSetを取得して、2つのリソースの作成が成功したことも確認します。
+```shell
+kubectl get statefulset web
+```
+```
+NAME DESIRED CURRENT AGE
+web 2 1 20s
+```
+
+### 順序付きPodの作成
+
+_n_ 個のレプリカを持つStatefulSetは、Podをデプロイするとき、1つずつ順番に作成し、 _{0..n-1}_ という順序付けを行います。1つ目のターミナルで`kubectl get`コマンドの出力を確認しましょう。最終的に、以下の例のような出力が表示されるはずです。
+
+```shell
+kubectl get pods -w -l app=nginx
+```
+```
+NAME READY STATUS RESTARTS AGE
+web-0 0/1 Pending 0 0s
+web-0 0/1 Pending 0 0s
+web-0 0/1 ContainerCreating 0 0s
+web-0 1/1 Running 0 19s
+web-1 0/1 Pending 0 0s
+web-1 0/1 Pending 0 0s
+web-1 0/1 ContainerCreating 0 0s
+web-1 1/1 Running 0 18s
+```
+
+`web-0`Podが _Running_ ([Pod Phase](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)を参照)かつ _Ready_ ([Pod Conditions](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-conditions)の`type`を参照)の状態になるまでは、`web-1`Podが起動していないことに注目してください。
+
+## StatefulSet内のPod
+
+StatefulSet内のPodは、ユニークな順序インデックスと安定したネットワーク識別子を持ちます。
+
+### Podの順序インデックスを確かめる
+
+StatefulSetのPodを取得します。
+
+```shell
+kubectl get pods -l app=nginx
+```
+```
+NAME READY STATUS RESTARTS AGE
+web-0 1/1 Running 0 1m
+web-1 1/1 Running 0 1m
+```
+
+[StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/)のコンセプトで説明したように、StatefulSet内のPodは安定したユニークな識別子を持ちます。この識別子は、StatefulSet{{< glossary_tooltip term_id="controller" text="コントローラー">}}によって各Podに割り当てられる、ユニークな順序インデックスに基づいて付けられます。Podの名前は、`-<順序インデックス>`という形式です。`web`StatefulSetは2つのレプリカを持つため、`web-0`と`web-1`という2つのPodを作成します。
+
+### 安定したネットワーク識別子の使用
+
+各Podは、順序インデックスに基づいた安定したホスト名を持ちます。[`kubectl exec`](/ja/docs/reference/generated/kubectl/kubectl-commands/#exec)を使用して、各Pod内で`hostname`コマンドを実行してみましょう。
+
+```shell
+for i in 0 1; do kubectl exec "web-$i" -- sh -c 'hostname'; done
+```
+```
+web-0
+web-1
+```
+
+[`kubectl run`](/ja/docs/reference/generated/kubectl/kubectl-commands/#run)を使用して、`dnsutils`パッケージの`nslookup`コマンドを提供するコンテナを実行します。Podのホスト名に対して`nslookup`を実行すると、クラスター内のDNSアドレスが確認できます。
+
+```shell
+kubectl run -i --tty --image busybox:1.28 dns-test --restart=Never --rm
+```
+これにより、新しいシェルが起動します。新しいシェルで、次のコマンドを実行します。
+```shell
+# このコマンドは、dns-testコンテナのシェルで実行してください
+nslookup web-0.nginx
+```
+出力は次のようになります。
+```
+Server: 10.0.0.10
+Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
+
+Name: web-0.nginx
+Address 1: 10.244.1.6
+
+nslookup web-1.nginx
+Server: 10.0.0.10
+Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
+
+Name: web-1.nginx
+Address 1: 10.244.2.6
+```
+
+(コンテナのシェルを終了するために、`exit`コマンドを実行してください。)
+
+headless serviceのCNAMEは、SRVレコードを指しています(1つのレコードがRunningかつReadyのPodに対応します)。SRVレコードは、PodのIPアドレスを含むAレコードを指します。
+
+1つ目のターミナルで、StatefulSetのPodを監視します。
+
+```shell
+kubectl get pod -w -l app=nginx
+```
+2つ目のターミナルで、[`kubectl delete`](/ja/docs/reference/generated/kubectl/kubectl-commands/#delete)を使用して、StatefulSetのすべてのPodを削除します。
+
+```shell
+kubectl delete pod -l app=nginx
+```
+```
+pod "web-0" deleted
+pod "web-1" deleted
+```
+
+StatefulSetがPodを再起動して、2つのPodがRunningかつReadyの状態に移行するのを待ちます。
+
+```shell
+kubectl get pod -w -l app=nginx
+```
+```
+NAME READY STATUS RESTARTS AGE
+web-0 0/1 ContainerCreating 0 0s
+NAME READY STATUS RESTARTS AGE
+web-0 1/1 Running 0 2s
+web-1 0/1 Pending 0 0s
+web-1 0/1 Pending 0 0s
+web-1 0/1 ContainerCreating 0 0s
+web-1 1/1 Running 0 34s
+```
+
+`kubectl exec`と`kubectl run`コマンドを使用して、Podのホスト名とクラスター内DNSエントリーを確認します。まず、Podのホスト名を見てみましょう。
+
+```shell
+for i in 0 1; do kubectl exec web-$i -- sh -c 'hostname'; done
+```
+```
+web-0
+web-1
+```
+その後、次のコマンドを実行します。
+```
+kubectl run -i --tty --image busybox:1.28 dns-test --restart=Never --rm /bin/sh
+```
+これにより、新しいシェルが起動します。新しいシェルで、次のコマンドを実行します。
+```shell
+# このコマンドは、dns-testコンテナのシェルで実行してください
+nslookup web-0.nginx
+```
+出力は次のようになります。
+```
+Server: 10.0.0.10
+Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
+
+Name: web-0.nginx
+Address 1: 10.244.1.7
+
+nslookup web-1.nginx
+Server: 10.0.0.10
+Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
+
+Name: web-1.nginx
+Address 1: 10.244.2.8
+```
+
+(コンテナのシェルを終了するために、`exit`コマンドを実行してください。)
+
+Podの順序インデックス、ホスト名、SRVレコード、そしてAレコード名は変化していませんが、Podに紐付けられたIPアドレスは変化する可能性があります。このチュートリアルで使用しているクラスターでは、IPアドレスは変わりました。このようなことがあるため、他のアプリケーションがStatefulSet内のPodに接続するときには、IPアドレスで指定しないことが重要です。
+
+StatefulSetの有効なメンバーを探して接続する必要がある場合は、headless ServiceのCNAME(`nginx.default.svc.cluster.local`)をクエリしなければなりません。CNAMEに紐付けられたSRVレコードには、StatefulSet内のRunnningかつReadyなPodだけが含まれます。
+
+アプリケーションがlivenessとreadinessをテストするコネクションのロジックをすでに実装している場合、PodのSRVレコード(`web-0.nginx.default.svc.cluster.local`、`web-1.nginx.default.svc.cluster.local`)をPodが安定しているものとして使用できます。PodがRunning and Readyな状態に移行すれば、アプリケーションはPodのアドレスを発見できるようになります。
+
+### 安定したストレージへの書き込み {#writing-to-stable-storage}
+
+`web-0`および`web-1`のためのPersistentVolumeClaimを取得しましょう。
+
+```shell
+kubectl get pvc -l app=nginx
+```
+出力は次のようになります。
+```
+NAME STATUS VOLUME CAPACITY ACCESSMODES AGE
+www-web-0 Bound pvc-15c268c7-b507-11e6-932f-42010a800002 1Gi RWO 48s
+www-web-1 Bound pvc-15c79307-b507-11e6-932f-42010a800002 1Gi RWO 48s
+```
+
+StatefulSetコントローラーは、2つの{{< glossary_tooltip text="PersistentVolume" term_id="persistent-volume" >}}にバインドされた2つの{{< glossary_tooltip text="PersistentVolumeClaim" term_id="persistent-volume-claim" >}}を作成しています。
+
+このチュートリアルで使用しているクラスターでは、PersistentVolumeの動的なプロビジョニングが設定されているため、PersistentVolumeが自動的に作成されてバインドされています。
+
+デフォルトでは、NGINXウェブサーバーは`/usr/share/nginx/html/index.html`に置かれたindexファイルを配信します。StatefulSetの`spec`内の`volumeMounts`フィールドによって、`/usr/share/nginx/html`ディレクトリがPersistentVolume上にあることが保証されます。
+
+Podのホスト名を`index.html`ファイルに書き込むことで、NGINXウェブサーバーがホスト名を配信することを検証しましょう。
+
+```shell
+for i in 0 1; do kubectl exec "web-$i" -- sh -c 'echo "$(hostname)" > /usr/share/nginx/html/index.html'; done
+
+for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done
+```
+```
+web-0
+web-1
+```
+
+{{< note >}}
+上記のcurlコマンドに対して代わりに**403 Forbidden**というレスポンスが返ってくる場合、`volumeMounts`でマウントしたディレクトリのパーミッションを修正する必要があります(これは、[hostPathボリュームを使用したときに起こるバグ](https://github.com/kubernetes/kubernetes/issues/2630)が原因です)。この問題に対処するには、上の`curl`コマンドを再実行する前に、次のコマンドを実行します。
+
+`for i in 0 1; do kubectl exec web-$i -- chmod 755 /usr/share/nginx/html; done`
+{{< /note >}}
+
+1つ目のターミナルで、StatefulSetのPodを監視します。
+
+```shell
+kubectl get pod -w -l app=nginx
+```
+
+2つ目のターミナルで、StatefulSetのすべてのPodを削除します。
+
+```shell
+kubectl delete pod -l app=nginx
+```
+```
+pod "web-0" deleted
+pod "web-1" deleted
+```
+1つ目のターミナルで`kubectl get`コマンドの出力を確認して、すべてのPodがRunningかつReadyの状態に変わるまで待ちます。
+
+```shell
+kubectl get pod -w -l app=nginx
+```
+```
+NAME READY STATUS RESTARTS AGE
+web-0 0/1 ContainerCreating 0 0s
+NAME READY STATUS RESTARTS AGE
+web-0 1/1 Running 0 2s
+web-1 0/1 Pending 0 0s
+web-1 0/1 Pending 0 0s
+web-1 0/1 ContainerCreating 0 0s
+web-1 1/1 Running 0 34s
+```
+
+ウェブサーバーがホスト名を配信し続けていることを確認します。
+
+```
+for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done
+```
+```
+web-0
+web-1
+```
+
+もし`web-0`および`web-1`が再スケジュールされたとしても、Podは同じホスト名を配信し続けます。これは、PodのPersistentVolumeClaimに紐付けられたPersistentVolumeが、Podの`volumeMounts`に再マウントされるためです。`web-0`と`web-1`がどんなノードにスケジュールされたとしても、PodのPersistentVolumeは適切なマウントポイントにマウントされます。
+
+## StatefulSetをスケールする
+
+StatefulSetのスケールとは、レプリカ数を増減することを意味します。これは、`replicas`フィールドを更新することによって実現できます。StatefulSetのスケールには、[`kubectl scale`](/ja/docs/reference/generated/kubectl/kubectl-commands/#scale)と
+[`kubectl patch`](/ja/docs/reference/generated/kubectl/kubectl-commands/#patch)のどちらも使用できます。
+
+### スケールアップ
+
+1つ目のターミナルで、StatefulSet内のPodを監視します。
+
+```shell
+kubectl get pods -w -l app=nginx
+```
+
+2つ目のターミナルで、`kubectl scale`を使って、レプリカ数を5にスケールします。
+
+```shell
+kubectl scale sts web --replicas=5
+```
+```
+statefulset.apps/web scaled
+```
+
+1つ目のターミナルの`kubectl get`コマンドの出力を確認して、3つの追加のPodがRunningかつReadyの状態に変わるまで待ちます。
+
+```shell
+kubectl get pods -w -l app=nginx
+```
+```
+NAME READY STATUS RESTARTS AGE
+web-0 1/1 Running 0 2h
+web-1 1/1 Running 0 2h
+NAME READY STATUS RESTARTS AGE
+web-2 0/1 Pending 0 0s
+web-2 0/1 Pending 0 0s
+web-2 0/1 ContainerCreating 0 0s
+web-2 1/1 Running 0 19s
+web-3 0/1 Pending 0 0s
+web-3 0/1 Pending 0 0s
+web-3 0/1 ContainerCreating 0 0s
+web-3 1/1 Running 0 18s
+web-4 0/1 Pending 0 0s
+web-4 0/1 Pending 0 0s
+web-4 0/1 ContainerCreating 0 0s
+web-4 1/1 Running 0 19s
+```
+
+StatefulSetコントローラーはレプリカ数をスケールします。
+[StatefulSetを作成する](#ordered-pod-creation)で説明したように、StatefulSetコントローラーは各Podを順序インデックスに従って1つずつ作成し、次のPodを起動する前に、1つ前のPodがRunningかつReadyの状態になるまで待ちます。
+
+### スケールダウン {#scaling-down}
+
+1つ目のターミナルで、StatefulSetのPodを監視します。
+
+```shell
+kubectl get pods -w -l app=nginx
+```
+
+2つ目のターミナルで、`kubectl patch`コマンドを使用して、StatefulSetを3つのレプリカにスケールダウンします。
+
+```shell
+kubectl patch sts web -p '{"spec":{"replicas":3}}'
+```
+```
+statefulset.apps/web patched
+```
+
+`web-4`および`web-3`がTerminatingの状態になるまで待ちます。
+
+```shell
+kubectl get pods -w -l app=nginx
+```
+```
+NAME READY STATUS RESTARTS AGE
+web-0 1/1 Running 0 3h
+web-1 1/1 Running 0 3h
+web-2 1/1 Running 0 55s
+web-3 1/1 Running 0 36s
+web-4 0/1 ContainerCreating 0 18s
+NAME READY STATUS RESTARTS AGE
+web-4 1/1 Running 0 19s
+web-4 1/1 Terminating 0 24s
+web-4 1/1 Terminating 0 24s
+web-3 1/1 Terminating 0 42s
+web-3 1/1 Terminating 0 42s
+```
+
+### 順序付きPodを削除する
+
+コントローラーは、順序インデックスの逆順に1度に1つのPodを削除し、次のPodを削除する前には、各Podが完全にシャットダウンするまで待機しています。
+
+StatefulSetのPersistentVolumeClaimを取得しましょう。
+
+```shell
+kubectl get pvc -l app=nginx
+```
+```
+NAME STATUS VOLUME CAPACITY ACCESSMODES AGE
+www-web-0 Bound pvc-15c268c7-b507-11e6-932f-42010a800002 1Gi RWO 13h
+www-web-1 Bound pvc-15c79307-b507-11e6-932f-42010a800002 1Gi RWO 13h
+www-web-2 Bound pvc-e1125b27-b508-11e6-932f-42010a800002 1Gi RWO 13h
+www-web-3 Bound pvc-e1176df6-b508-11e6-932f-42010a800002 1Gi RWO 13h
+www-web-4 Bound pvc-e11bb5f8-b508-11e6-932f-42010a800002 1Gi RWO 13h
+
+```
+
+まだ、5つのPersistentVolumeClaimと5つのPersistentVolumeが残っています。[安定したストレージへの書き込み](#writing-to-stable-storage)を読むと、StatefulSetのPodが削除されても、StatefulSetのPodにマウントされたPersistentVolumeは削除されないと書かれています。このことは、StatefulSetのスケールダウンによってPodが削除された場合にも当てはまります。
+
+## StatefulSetsを更新する
+
+Kubernetes 1.7以降では、StatefulSetコントローラーは自動アップデートをサポートしています。使われる戦略は、StatefulSet APIオブジェクトの`spec.updateStrategy`フィールドによって決まります。この機能はコンテナイメージのアップグレード、リソースのrequestsやlimits、ラベル、StatefulSet内のPodのアノテーションの更新時に利用できます。有効なアップデートの戦略は、`RollingUpdate`と`OnDelete`の2種類です。
+
+`RollingUpdate`は、StatefulSetのデフォルトのアップデート戦略です。
+
+### RollingUpdate
+
+`RollingUpdate`アップデート戦略は、StatefulSetの保証を尊重しながら、順序インデックスの逆順にStatefulSet内のすべてのPodをアップデートします。
+
+`web`StatefulSetにpatchを当てて、`RollingUpdate`アップデート戦略を適用しましょう。
+
+```shell
+kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate"}}}'
+```
+```
+statefulset.apps/web patched
+```
+
+1つ目のターミナルで、`web`StatefulSetに再度patchを当てて、コンテナイメージを変更します。
+
+```shell
+kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"gcr.io/google_containers/nginx-slim:0.8"}]'
+```
+```
+statefulset.apps/web patched
+```
+
+2つ目のターミナルで、StatefulSet内のPodを監視します。
+
+```shell
+kubectl get pod -l app=nginx -w
+```
+出力は次のようになります。
+```
+NAME READY STATUS RESTARTS AGE
+web-0 1/1 Running 0 7m
+web-1 1/1 Running 0 7m
+web-2 1/1 Running 0 8m
+web-2 1/1 Terminating 0 8m
+web-2 1/1 Terminating 0 8m
+web-2 0/1 Terminating 0 8m
+web-2 0/1 Terminating 0 8m
+web-2 0/1 Terminating 0 8m
+web-2 0/1 Terminating 0 8m
+web-2 0/1 Pending 0 0s
+web-2 0/1 Pending 0 0s
+web-2 0/1 ContainerCreating 0 0s
+web-2 1/1 Running 0 19s
+web-1 1/1 Terminating 0 8m
+web-1 0/1 Terminating 0 8m
+web-1 0/1 Terminating 0 8m
+web-1 0/1 Terminating 0 8m
+web-1 0/1 Pending 0 0s
+web-1 0/1 Pending 0 0s
+web-1 0/1 ContainerCreating 0 0s
+web-1 1/1 Running 0 6s
+web-0 1/1 Terminating 0 7m
+web-0 1/1 Terminating 0 7m
+web-0 0/1 Terminating 0 7m
+web-0 0/1 Terminating 0 7m
+web-0 0/1 Terminating 0 7m
+web-0 0/1 Terminating 0 7m
+web-0 0/1 Pending 0 0s
+web-0 0/1 Pending 0 0s
+web-0 0/1 ContainerCreating 0 0s
+web-0 1/1 Running 0 10s
+```
+
+StatefulSet内のPodは、順序インデックスの逆順に更新されました。StatefulSetコントローラーは各Podを終了させ、次のPodを更新する前に、新しいPodがRunningかつReadyの状態に変わるまで待機します。ここで、StatefulSetコントローラーは順序インデックスの前のPodがRunningかつReadyの状態になるまで次のPodの更新を始めず、現在の状態へのアップデートに失敗したPodがあった場合、そのPodをリストアすることに注意してください。
+
+すでにアップデートを受け取ったPodは、アップデートされたバージョンにリストアされます。まだアップデートを受け取っていないPodは、前のバージョンにリストアされます。このような方法により、もし途中で失敗が起こっても、コントローラはアプリケーションが健全な状態を保ち続けられるようにし、更新が一貫したものになるようにします。
+
+Podを取得して、コンテナイメージを確認してみましょう。
+
+```shell
+for p in 0 1 2; do kubectl get pod "web-$p" --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'; echo; done
+```
+```
+k8s.gcr.io/nginx-slim:0.8
+k8s.gcr.io/nginx-slim:0.8
+k8s.gcr.io/nginx-slim:0.8
+
+```
+
+現在、StatefulSet内のすべてのPodは、前のコンテナイメージを実行しています。
+
+{{< note >}}
+`kubectl rollout status sts/`を使って、StatefulSetへのローリングアップデートの状態を確認することもできます。
+{{< /note >}}
+
+#### ステージングアップデート {#staging-an-update}
+
+`RollingUpdate`アップデート戦略に`partition`パラメーターを使用すると、StatefulSetへのアップデートをステージングすることができます。ステージングアップデートを利用すれば、StatefulSet内のすべてのPodを現在のバージョンにしたまま、StatefulSetの`.spec.template`を変更することが可能になります。
+
+`web`StatefulSetにpatchを当てて、`updateStrategy`フィールドにpartitionを追加しましょう。
+
+```shell
+kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":3}}}}'
+```
+```
+statefulset.apps/web patched
+```
+
+StatefulSetに再度patchを当てて、コンテナイメージを変更します。
+
+```shell
+kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"k8s.gcr.io/nginx-slim:0.7"}]'
+```
+```
+statefulset.apps/web patched
+```
+
+StatefulSet内のPodを削除します。
+
+```shell
+kubectl delete pod web-2
+```
+```
+pod "web-2" deleted
+```
+
+PodがRunningかつReadyになるまで待ちます。
+
+```shell
+kubectl get pod -l app=nginx -w
+```
+```
+NAME READY STATUS RESTARTS AGE
+web-0 1/1 Running 0 4m
+web-1 1/1 Running 0 4m
+web-2 0/1 ContainerCreating 0 11s
+web-2 1/1 Running 0 18s
+```
+
+Podのコンテナイメージを取得します。
+
+```shell
+kubectl get pod web-2 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'
+```
+```
+k8s.gcr.io/nginx-slim:0.8
+```
+
+アップデート戦略が`RollingUpdate`であっても、StatefulSetが元のコンテナを持つPodをリストアしたことがわかります。これは、Podの順序インデックスが`updateStrategy`で指定した`partition`より小さいためです。
+
+#### カナリア版をロールアウトする {#rolling-out-a-canary}
+
+[ステージングアップデート](#staging-an-update)のときに指定した`partition`を小さくすることで、変更をテストするためのカナリア版をロールアウトできます。
+
+StatefulSetにpatchを当てて、partitionを小さくします。
+
+```shell
+kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":2}}}}'
+```
+```
+statefulset.apps/web patched
+```
+
+`web-2`がRunningかつReadyの状態になるまで待ちます。
+
+```shell
+kubectl get pod -l app=nginx -w
+```
+```
+NAME READY STATUS RESTARTS AGE
+web-0 1/1 Running 0 4m
+web-1 1/1 Running 0 4m
+web-2 0/1 ContainerCreating 0 11s
+web-2 1/1 Running 0 18s
+```
+
+Podのコンテナを取得します。
+
+```shell
+kubectl get pod web-2 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'
+```
+```
+k8s.gcr.io/nginx-slim:0.7
+
+```
+
+`partition`を変更すると、StatefulSetコントローラーはPodを自動的に更新します。Podの順序インデックスが`partition`以上の値であるためです。
+
+`web-1`Podを削除します。
+
+```shell
+kubectl delete pod web-1
+```
+```
+pod "web-1" deleted
+```
+
+`web-1`PodがRunningかつReadyになるまで待ちます。
+
+```shell
+kubectl get pod -l app=nginx -w
+```
+出力は次のようになります。
+```
+NAME READY STATUS RESTARTS AGE
+web-0 1/1 Running 0 6m
+web-1 0/1 Terminating 0 6m
+web-2 1/1 Running 0 2m
+web-1 0/1 Terminating 0 6m
+web-1 0/1 Terminating 0 6m
+web-1 0/1 Terminating 0 6m
+web-1 0/1 Pending 0 0s
+web-1 0/1 Pending 0 0s
+web-1 0/1 ContainerCreating 0 0s
+web-1 1/1 Running 0 18s
+```
+
+`web-1`Podのコンテナイメージを取得します。
+
+```shell
+kubectl get pod web-1 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'
+```
+```
+k8s.gcr.io/nginx-slim:0.8
+```
+
+Podの順序インデックスがpartitionよりも小さいため、`web-1`は元の設定のコンテナイメージにリストアされました。partitionを指定すると、StatefulSetの`.spec.template`が更新されたときに、順序インデックスがそれ以上の値を持つすべてのPodがアップデートされます。partitionよりも小さな順序インデックスを持つPodが削除されたり終了されたりすると、元の設定のPodにリストアされます。
+
+#### フェーズロールアウト
+
+[カナリア版](#rolling-out-a-canary)をロールアウトするのと同じような方法でパーティションされたローリングアップデートを使用すると、フェーズロールアウト(例: 線形、幾何級数的、指数関数的ロールアウト)を実行できます。フェーズロールアウトを実行するには、コントローラーがアップデートを途中で止めてほしい順序インデックスを`partition`に設定します。
+
+現在、partitionは`2`に設定されています。partitionを`0`に設定します。
+
+```shell
+kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":0}}}}'
+```
+```
+statefulset.apps/web patched
+```
+
+StatefulSet内のすべてのPodがRunningかつReadyの状態になるまで待ちます。
+
+```shell
+kubectl get pod -l app=nginx -w
+```
+出力は次のようになります。
+```
+NAME READY STATUS RESTARTS AGE
+web-0 1/1 Running 0 3m
+web-1 0/1 ContainerCreating 0 11s
+web-2 1/1 Running 0 2m
+web-1 1/1 Running 0 18s
+web-0 1/1 Terminating 0 3m
+web-0 1/1 Terminating 0 3m
+web-0 0/1 Terminating 0 3m
+web-0 0/1 Terminating 0 3m
+web-0 0/1 Terminating 0 3m
+web-0 0/1 Terminating 0 3m
+web-0 0/1 Pending 0 0s
+web-0 0/1 Pending 0 0s
+web-0 0/1 ContainerCreating 0 0s
+web-0 1/1 Running 0 3s
+```
+
+StatefulSet内のPodのコンテナイメージの詳細を取得します。
+
+```shell
+for p in 0 1 2; do kubectl get pod "web-$p" --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'; echo; done
+```
+```
+k8s.gcr.io/nginx-slim:0.7
+k8s.gcr.io/nginx-slim:0.7
+k8s.gcr.io/nginx-slim:0.7
+```
+
+`partition`を`0`に移動することで、StatefulSetがアップデート処理を続けられるようにできます。
+
+### OnDelete
+
+`OnDelete`アップデート戦略は、(1.6以前の)レガシーな動作を実装しています。このアップデート戦略を選択すると、StatefulSetの`.spec.template`フィールドへ変更を加えても、StatefulSetコントローラーが自動的にPodを更新しなくなります。この戦略を選択するには、`.spec.template.updateStrategy.type`に`OnDelete`を設定します。
+
+## StatefulSetを削除する
+
+StatefulSetは、非カスケードな削除とカスケードな削除の両方をサポートしています。非カスケードな削除では、StatefulSetが削除されても、StatefulSet内のPodは削除されません。カスケードな削除では、StatefulSetとPodが一緒に削除されます。
+
+### 非カスケードな削除
+
+1つ目のターミナルで、StatefulSet内のPodを監視します
+
+```
+kubectl get pods -w -l app=nginx
+```
+
+[`kubectl delete`](/ja/docs/reference/generated/kubectl/kubectl-commands/#delete)を使用して、StatefulSetを削除します。このとき、`--cascade=false`パラメーターをコマンドに与えてください。このパラメーターは、Kubernetesに対して、StatefulSetだけを削除して配下のPodは削除しないように指示します。
+
+```shell
+kubectl delete statefulset web --cascade=false
+```
+```
+statefulset.apps "web" deleted
+```
+
+Podを取得して、ステータスを確認します。
+
+```shell
+kubectl get pods -l app=nginx
+```
+```
+NAME READY STATUS RESTARTS AGE
+web-0 1/1 Running 0 6m
+web-1 1/1 Running 0 7m
+web-2 1/1 Running 0 5m
+```
+
+`web`が削除されても、すべてのPodはまだRunningかつReadyの状態のままです。`web-0`を削除します。
+
+```shell
+kubectl delete pod web-0
+```
+```
+pod "web-0" deleted
+```
+
+StatefulSetのPodを取得します。
+
+```shell
+kubectl get pods -l app=nginx
+```
+```
+NAME READY STATUS RESTARTS AGE
+web-1 1/1 Running 0 10m
+web-2 1/1 Running 0 7m
+```
+
+`web`StatefulSetはすでに削除されているため、`web-0`は再起動しません。
+
+1つ目のターミナルで、StatefulSetのPodを監視します。
+
+```shell
+kubectl get pods -w -l app=nginx
+```
+
+2つ目のターミナルで、StatefulSetを再作成します。もし`nginx`Serviceを削除しなかった場合(この場合は削除するべきではありませんでした)、Serviceがすでに存在することを示すエラーが表示されます。
+
+```shell
+kubectl apply -f web.yaml
+```
+```
+statefulset.apps/web created
+service/nginx unchanged
+```
+
+このエラーは無視してください。このメッセージは、すでに存在する _nginx_ というheadless Serviceを作成しようと試みたということを示しているだけです。
+
+1つ目のターミナルで、`kubectl get`コマンドの出力を確認します。
+
+```shell
+kubectl get pods -w -l app=nginx
+```
+```
+NAME READY STATUS RESTARTS AGE
+web-1 1/1 Running 0 16m
+web-2 1/1 Running 0 2m
+NAME READY STATUS RESTARTS AGE
+web-0 0/1 Pending 0 0s
+web-0 0/1 Pending 0 0s
+web-0 0/1 ContainerCreating 0 0s
+web-0 1/1 Running 0 18s
+web-2 1/1 Terminating 0 3m
+web-2 0/1 Terminating 0 3m
+web-2 0/1 Terminating 0 3m
+web-2 0/1 Terminating 0 3m
+```
+
+ `web`StatefulSetが再作成されると、最初に`web-0`を再実行します。`web-1`はすでにRunningかつReadyの状態であるため、`web-0`がRunningかつReadyの状態に移行すると、StatefulSetは単純にこのPodを選びます。StatefulSetを`replicas`を2にして再作成したため、一度`web-0`が再作成されて、`web-1`がすでにRunningかつReadyの状態であることが判明したら、`web-2`は停止されます。
+
+Podのウェブサーバーが配信している`index.html`ファイルのコンテンツをもう一度見てみましょう。
+
+```shell
+for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done
+```
+```
+web-0
+web-1
+```
+
+たとえStatefulSetと`web-0`Podの両方が削除されても、Podは最初に`index.html`ファイルに書き込んだホスト名をまだ配信しています。これは、StatefulSetがPodに紐付けられたPersistentVolumeを削除しないためです。StatefulSetを再作成して`web-0`を再実行すると、元のPersistentVolumeが再マウントされます。
+
+### カスケードな削除
+
+1つ目のターミナルで、StatefulSet内のPodを監視します。
+
+```shell
+kubectl get pods -w -l app=nginx
+```
+
+2つ目のターミナルで、StatefulSetをもう一度削除します。今回は、`--cascade=false`パラメーターを省略します。
+
+```shell
+kubectl delete statefulset web
+```
+```
+statefulset.apps "web" deleted
+```
+
+1つ目のターミナルで実行している`kubectl get`コマンドの出力を確認し、すべてのPodがTerminatingの状態に変わるまで待ちます。
+
+```shell
+kubectl get pods -w -l app=nginx
+```
+```
+NAME READY STATUS RESTARTS AGE
+web-0 1/1 Running 0 11m
+web-1 1/1 Running 0 27m
+NAME READY STATUS RESTARTS AGE
+web-0 1/1 Terminating 0 12m
+web-1 1/1 Terminating 0 29m
+web-0 0/1 Terminating 0 12m
+web-0 0/1 Terminating 0 12m
+web-0 0/1 Terminating 0 12m
+web-1 0/1 Terminating 0 29m
+web-1 0/1 Terminating 0 29m
+web-1 0/1 Terminating 0 29m
+
+```
+
+[スケールダウン](#scaling-down)のセクションで見たように、順序インデックスの逆順に従って、Podは一度に1つずつ終了します。StatefulSetコントローラーは、次のPodを終了する前に、前のPodが完全に終了するまで待ちます。
+
+{{< note >}}
+カスケードな削除ではStatefulSetがPodとともに削除されますが、StatefulSetと紐付けられたheadless Serviceは削除されません。そのため、`nginx`Serviceは手動で削除する必要があります。
+{{< /note >}}
+
+
+```shell
+kubectl delete service nginx
+```
+```
+service "nginx" deleted
+```
+
+さらにもう一度、StatefulSetとheadless Serviceを再作成します。
+
+```shell
+kubectl apply -f web.yaml
+```
+```
+service/nginx created
+statefulset.apps/web created
+```
+
+StatefulSet上のすべてのPodがRunningかつReadyの状態に変わったら、Pod上の`index.html`ファイルのコンテンツを取得します。
+
+```shell
+for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done
+```
+```
+web-0
+web-1
+```
+
+StatefulSetを完全に削除して、すべてのPodが削除されたとしても、PersistentVolumeがマウントされたPodが再生成されて、`web-0`と`web-1`はホスト名の配信を続けます。
+
+最後に、`web`StatefulSetを削除します。
+
+```shell
+kubectl delete service nginx
+```
+```
+service "nginx" deleted
+```
+そして、`nginx`Serviceも削除します。
+```shell
+kubectl delete statefulset web
+```
+```
+statefulset "web" deleted
+```
+
+## Pod管理ポリシー
+
+分散システムによっては、StatefulSetの順序の保証が不必要であったり望ましくない場合もあります。こうしたシステムでは、一意性と同一性だけが求められます。この問題に対処するために、Kubernetes 1.7でStatefulSet APIオブジェクトに`.spec.podManagementPolicy`が導入されました。
+
+### OrderedReadyのPod管理
+
+`OrderedReady`のPod管理はStatefulSetのデフォルトの設定です。StatefulSetコントローラーに対して、これまでに紹介したような順序の保証を尊重するように指示します。
+
+### ParallelのPod管理
+
+`Parallel`のPod管理では、StatefulSetコントローラーに対して、PodがRunningかつReadyの状態や完全に停止するまで待たないように指示し、すべてのPodを並列に起動または停止させるようにします。
+
+{{< codenew file="application/web/web-parallel.yaml" >}}
+
+上の例をダウンロードして、`web-parallel.yaml`という名前でファイルに保存してください。
+
+このマニフェストは、`.spec.podManagementPolicy`が`Parallel`に設定されている以外は、前にダウンロードした`web`StatefulSetと同一です。
+
+1つ目のターミナルで、StatefulSet内のPodを監視します。
+
+```shell
+kubectl get pod -l app=nginx -w
+```
+
+2つ目のターミナルで、マニフェスト内のStatefulSetとServiceを作成します。
+
+```shell
+kubectl apply -f web-parallel.yaml
+```
+```
+service/nginx created
+statefulset.apps/web created
+```
+
+1つ目のターミナルで実行した`kubectl get`コマンドの出力を確認します。
+
+```shell
+kubectl get pod -l app=nginx -w
+```
+```
+NAME READY STATUS RESTARTS AGE
+web-0 0/1 Pending 0 0s
+web-0 0/1 Pending 0 0s
+web-1 0/1 Pending 0 0s
+web-1 0/1 Pending 0 0s
+web-0 0/1 ContainerCreating 0 0s
+web-1 0/1 ContainerCreating 0 0s
+web-0 1/1 Running 0 10s
+web-1 1/1 Running 0 10s
+```
+
+StatefulSetコントローラーは`web-0`と`web-1`を同時に起動しています。
+
+2つ目のターミナルで、StatefulSetをスケールしてみます。
+
+```shell
+kubectl scale statefulset/web --replicas=4
+```
+```
+statefulset.apps/web scaled
+```
+
+`kubectl get`コマンドを実行しているターミナルの出力を確認します。
+
+```
+web-3 0/1 Pending 0 0s
+web-3 0/1 Pending 0 0s
+web-3 0/1 Pending 0 7s
+web-3 0/1 ContainerCreating 0 7s
+web-2 1/1 Running 0 10s
+web-3 1/1 Running 0 26s
+```
+
+StatefulSetが2つのPodを実行し、1つ目のPodがRunningかつReadyの状態になるのを待たずに2つ目のPodを実行しているのがわかります。
+
+## {{% heading "cleanup" %}}
+
+2つのターミナルが開かれているはずなので、クリーンアップの一部として`kubectl`コマンドを実行する準備ができています。
+
+```shell
+kubectl delete sts web
+# stsは、statefulsetの略です。
+```
+
+`kubectl get`を監視すると、Podが削除されていく様子を確認できます。
+
+```shell
+kubectl get pod -l app=nginx -w
+```
+```
+web-3 1/1 Terminating 0 9m
+web-2 1/1 Terminating 0 9m
+web-3 1/1 Terminating 0 9m
+web-2 1/1 Terminating 0 9m
+web-1 1/1 Terminating 0 44m
+web-0 1/1 Terminating 0 44m
+web-0 0/1 Terminating 0 44m
+web-3 0/1 Terminating 0 9m
+web-2 0/1 Terminating 0 9m
+web-1 0/1 Terminating 0 44m
+web-0 0/1 Terminating 0 44m
+web-2 0/1 Terminating 0 9m
+web-2 0/1 Terminating 0 9m
+web-2 0/1 Terminating 0 9m
+web-1 0/1 Terminating 0 44m
+web-1 0/1 Terminating 0 44m
+web-1 0/1 Terminating 0 44m
+web-0 0/1 Terminating 0 44m
+web-0 0/1 Terminating 0 44m
+web-0 0/1 Terminating 0 44m
+web-3 0/1 Terminating 0 9m
+web-3 0/1 Terminating 0 9m
+web-3 0/1 Terminating 0 9m
+```
+
+削除の間、StatefulSetはすべてのPodを並列に削除し、順序インデックスが1つ前のPodが停止するのを待つことはありません。
+
+`kubectl get`コマンドを実行しているターミナルを閉じて、`nginx`Serviceを削除します。
+
+```shell
+kubectl delete svc nginx
+```
+
+{{< note >}}
+このチュートリアルで使用したPersistentVolumeのための永続ストレージも削除する必要があります。
+
+すべてのストレージが再利用できるようにするために、環境、ストレージの設定、プロビジョニング方法に基づいて必要な手順に従ってください。
+{{< /note >}}
diff --git a/content/ja/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md b/content/ja/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md
new file mode 100644
index 0000000000..7aed33777e
--- /dev/null
+++ b/content/ja/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md
@@ -0,0 +1,241 @@
+---
+title: "例: Persistent Volumeを使用したWordpressとMySQLをデプロイする"
+content_type: tutorial
+weight: 20
+card:
+ name: tutorials
+ weight: 40
+ title: "ステートフルの例: Persistent Volumeを使用したWordpress"
+---
+
+
+このチュートリアルでは、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)
+
+
+
+
+
+## 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 <./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 <>./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 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のインストールをこのページのまま放置してはいけません。もしほかのユーザーがこのページを見つけた場合、その人はインスタンス上にウェブサイトをセットアップして、悪意のあるコンテンツの配信に利用できてしまいます。
ユーザー名とパスワードを決めて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/)方法について学ぶ
+
diff --git a/content/ja/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md b/content/ja/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md
new file mode 100644
index 0000000000..aac1e685cb
--- /dev/null
+++ b/content/ja/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md
@@ -0,0 +1,462 @@
+---
+title: "例: PHP / Redisを使用したゲストブックの例にロギングとメトリクスを追加する"
+content_type: tutorial
+weight: 21
+card:
+ name: tutorials
+ weight: 31
+ title: "例: PHP / Redisを使用したゲストブックの例にロギングとメトリクスを追加する"
+---
+
+
+このチュートリアルは、[Redisを使用したPHPのゲストブック](/ja/docs/tutorials/stateless-application/guestbook)のチュートリアルを前提に作られています。Elasticが開発したログ、メトリクス、ネットワークデータを転送するオープンソースの軽量データシッパーである*Beats*を、ゲストブックと同じKubernetesクラスターにデプロイします。BeatsはElasticsearchに対してデータの収集、分析、インデックス作成を行うため、結果の運用情報をKibana上で表示・分析できるようになります。この例は、以下のコンポーネントから構成されます。
+
+* [Redisを使用したPHPのゲストブック](/ja/docs/tutorials/stateless-application/guestbook)の実行中のインスタンス
+* ElasticsearchとKibana
+* Filebeat
+* Metricbeat
+* Packetbeat
+
+
+
+## {{% heading "objectives" %}}
+
+* Redisを使用したPHPのゲストブックを起動する。
+* kube-state-metricsをインストールする。
+* KubernetesのSecretを作成する。
+* Beatsをデプロイする。
+* ログとメトリクスのダッシュボードを表示する。
+
+
+## {{% heading "prerequisites" %}}
+
+
+{{< include "task-tutorial-prereqs.md" >}}
+{{< version-check >}}
+
+追加で以下の作業が必要です。
+
+* [Redisを使用したPHPのゲストブック](/ja/docs/tutorials/stateless-application/guestbook)チュートリアルの実行。
+
+* ElasticsearchとKibanaのdeploymentの実行。[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 Chart](https://github.com/elastic/helm-charts)が使用できます。
+
+
+
+
+
+## Redisを使用したPHPのゲストブックを起動する
+
+このチュートリアルは、[Redisを使用したPHPのゲストブック](/ja/docs/tutorials/stateless-application/guestbook)のチュートリアルを前提に作られています。もしゲストブックアプリケーションが実行中なら、そのアプリケーションを監視できます。もしまだ実行中のアプリケーションがなければ、ゲストブックのデプロイの手順を行い、**クリーンアップ**のステップは実行しないでください。ゲストブックが起動したら、このページに戻ってきてください。
+
+## Cluster role bindingを追加する
+
+[クラスターレベルのrole binding](/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding)を作成して、kube-state-metricsとBeatsをクラスターレベルで(kube-system内に)デプロイできるようにします。
+
+```shell
+kubectl create clusterrolebinding cluster-admin-binding \
+ --clusterrole=cluster-admin --user=
+```
+
+## kube-state-metricsをインストールする
+
+Kubernetesの[*kube-state-metrics*](https://github.com/kubernetes/kube-state-metrics)は、Kubernetes APIサーバーをlistenして、オブジェクトの状態に関するメトリクスを生成する単純なサービスです。Metricbeatはこれらのメトリクスを報告します。kube-state-metricsをゲストブックが実行されているKubernetesクラスターに追加しましょう。
+
+### kube-state-metricsが起動しているか確認する
+
+```shell
+kubectl get pods --namespace=kube-system | grep kube-state
+```
+
+### 必要に応じて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
+kubectl get pods --namespace=kube-system | grep kube-state-metrics
+```
+
+kube-state-metricsがRunningかつreadyの状態になっていることを確認します。
+
+```shell
+kubectl get pods -n kube-system -l app.kubernetes.io/name=kube-state-metrics
+```
+
+結果は次のようになります。
+
+```shell
+NAME READY STATUS RESTARTS AGE
+kube-state-metrics-89d656bf8-vdthm 1/1 Running 0 21s
+```
+
+## GitHubリポジトリのElasticの例をクローンする
+
+```shell
+git clone https://github.com/elastic/examples.git
+```
+
+これ以降のコマンドは`examples/beats-k8s-send-anywhere`ディレクトリ内のファイルを参照するため、カレントディレクトリを変更します。
+
+```shell
+cd examples/beats-k8s-send-anywhere
+```
+
+## KubernetesのSecretを作成する
+
+Kubernetesの{{< glossary_tooltip text="Secret" term_id="secret" >}}とは、パスワード、トークン、または鍵などの小さなサイズの機密データを含んだオブジェクトのことです。このような機密情報はPodのspecやイメージの中に置くことも不可能ではありませんが、Secretオブジェクトの中に置くことで、情報の使用方法を適切に制御したり、誤って公開してしまうリスクを減らすことができます。
+
+{{< note >}}
+ここでは2種類の手順を紹介します。1つは*セルフマネージド*な(自分のサーバーで実行中またはElastic Helm Chartを使用して構築された)ElasticsearchおよびKibanaのためのもので、もう1つは*マネージドサービス*のElastic CloudのElasticsearch Serviceのための別の手順です。このチュートリアルで使う種類のElasticsearchおよびKibanaのシステムのためのSecretだけを作成してください。
+{{< /note >}}
+
+{{< tabs name="tab_with_md" >}}
+{{% tab name="セルフマネージド" %}}
+
+### セルフマネージド
+
+Elastic Cloud上のElasticsearch Serviceに接続する場合は、**マネージドサービス**タブに切り替えてください。
+
+### クレデンシャルを設定する
+
+セルフマネージドのElasticsearchとKibanaへ接続する場合、KubernetesのSecretを作成するために編集するべきファイルは4つあります(セルフマネージドとは、事実上Elastic Cloud以外で実行されているElasticsearch Serviceを指します)。ファイルは次の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 Chartで作成したnodeGroupの場合。
+
+ ```shell
+ ["http://elasticsearch-master.default.svc.cluster.local:9200"]
+ ```
+
+1. Mac上で単一のElasticsearchノードが実行されており、BeatsがDocker for Macで実行中の場合。
+
+ ```shell
+ ["http://host.docker.internal:9200"]
+ ```
+
+1. 2ノードのElasticsearchがVM上または物理ハードウェア上で実行中の場合。
+
+ ```shell
+ ["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_USERNAME`を編集します。
+
+```shell
+vi ELASTICSEARCH_USERNAME
+```
+
+#### `KIBANA_HOST`
+
+1. Elastic Kibana Helm Chartで作成したKibanaインスタンスが実行中の場合。`default`というサブドメインは、default Namespaceを指します。もしHelm Chartを別のNamespaceにデプロイした場合、サブドメインは異なります。
+
+ ```shell
+ "kibana-kibana.default.svc.cluster.local:5601"
+ ```
+
+1. Mac上でKibanaインスタンスが実行中で、BeatsがDocker for Macで実行中の場合。
+
+ ```shell
+ "host.docker.internal:5601"
+ ```
+
+1. 2つのElasticsearchノードが、VMまたは物理ハードウェア上で実行中の場合。
+
+ ```shell
+ "host1.example.com:5601"
+ ```
+
+`KIBANA_HOST`を編集します。
+
+```shell
+vi KIBANA_HOST
+```
+
+### KubernetesのSecretを作成する
+
+次のコマンドを実行すると、KubernetesのシステムレベルのNamespace(kube-system)に、たった今編集したファイルを元にSecretが作成されます。
+
+ 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="マネージドサービス" %}}
+
+## マネージドサービス
+
+このタブは、Elastic Cloud上のElasticsearch Serviceの場合のみ必要です。もしセルフマネージドのElasticsearchとKibanaのDeployment向けにSecretをすでに作成した場合、[Beatsをデプロイする](#deploy-the-beats)に進んでください。
+
+### クレデンシャルを設定する
+
+Elastic Cloud上のマネージドElasticsearch Serviceに接続する場合、KubernetesのSecretを作成するために編集する必要があるのは、次の2つのファイルです。
+
+1. ELASTIC_CLOUD_AUTH
+1. ELASTIC_CLOUD_ID
+
+Deploymentを作成するときに、Elasticsearch Serviceのコンソールから提供された情報を設定してください。以下に例を示します。
+
+#### ELASTIC_CLOUD_ID
+
+```shell
+devk8s:ABC123def456ghi789jkl123mno456pqr789stu123vwx456yza789bcd012efg345hijj678klm901nop345zEwOTJjMTc5YWQ0YzQ5OThlN2U5MjAwYTg4NTIzZQ==
+```
+
+#### ELASTIC_CLOUD_AUTH
+
+ユーザー名、コロン(`:`)、パスワードだけを書きます。空白やクォートは書かないでください。
+
+```shell
+elastic:VFxJJf9Tjwer90wnfTghsn8w
+```
+
+### 必要なファイルを編集する
+
+```shell
+vi ELASTIC_CLOUD_ID
+vi ELASTIC_CLOUD_AUTH
+```
+
+### KubernetesのSecretを作成する
+
+次のコマンドを実行すると、KubernetesのシステムレベルのNamespace(kube-system)に、たった今編集したファイルを元にSecretが作成されます。
+
+ 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ごとに提供されます。これらのマニフェストファイルは、上で作成したSecretを使用して、BeatsをElasticsearchおよびKibanaサーバーに接続するように設定します。
+
+### Filebeatについて
+
+Filebeatは、Kubernetesのノードと、ノード上で実行している各Pod内のコンテナから、ログを収集します。Filebeatは{{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}}としてデプロイされます。FilebeatはKubernetesクラスター上で実行されているアプリケーションを自動検出することもできます。起動時にFilebeatは既存のコンテナをスキャンし、それらに対して適切な設定を立ち上げ、その後、新しいstart/stopイベントを監視します。
+
+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}"]
+```
+
+この設定により、Filebeatは、`app`ラベルに`redis`という文字列が含まれるコンテナを検出したときに`redis` Filebeatモジュールを適用するようになります。redisモジュールには、input typeとしてdockerを使用することで(このRedisコンテナの標準出力のストリームと関連付けられた、Kubernetesノード上のファイルを読み取ることで)コンテナから`log`ストリームを収集する機能があります。さらに、このモジュールには、コンテナのメタデータとして提供された適切なPodのホストとポートと接続することにより、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と同じ方法で設定します。以下にMetricbeatにおけるRedisコンテナの自動検出の設定を示します。この設定は`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}"]
+```
+
+この設定により、Metricbeatは、`tier`ラベルに`backend`という文字列が含まれるコンテナを検出したときに`redis` Metricbeatモジュールを適用するようになります。redisモジュールには、コンテナのメタデータとして提供された適切なPodのホストとポートと接続することにより、コンテナから`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`内の適切なtypeに追加し、PacketbeatのDaemonSetを削除・再作成してください。
+{{< /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を開き、**Dashboard**アプリケーションを開きます。検索バーでKubernetesと入力して、KubernetesのためのMetricbeatダッシュボードを開きます。このダッシュボードでは、NodeやDeploymentなどの状態のレポートが表示されます。
+
+DashboardページでPacketbeatと検索し、Packetbeat overviewを表示します。
+
+同様に、ApacheおよびRedisのためのDashboardを表示します。それぞれに対してログとメトリクスのDashboardが表示されます。Apache Metricbeat dashboardには何も表示されていないはずです。Apache Filebeat dashboardを表示して、ページの最下部までスクロールしてApacheのエラーログを確認します。ログを読むと、Apacheのメトリクスが表示されない理由が分かります。
+
+Metricbeatを有効にしてApacheのメトリクスを取得するには、mod-status設定ファイルを含んだConfigMapを追加してゲストブックを再デプロイすることで、server-statusを有効にします。
+
+## Deploymentをスケールして新しいPodが監視されるのを確認する
+
+存在するDeploymentを一覧します。
+
+```shell
+kubectl get deployments
+```
+
+出力は次のようになります。
+
+```shell
+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
+```
+
+frontendのPodを2つにスケールダウンします。
+
+```shell
+kubectl scale --replicas=2 deployment/frontend
+```
+
+出力は次のようになります。
+
+```shell
+deployment.extensions/frontend scaled
+```
+
+frontendのPodを再び3つにスケールアップします。
+
+```shell
+kubectl scale --replicas=3 deployment/frontend
+```
+
+## Kibana上で変更を表示する
+
+スクリーンショットを確認し、指定されたフィルターを追加して、ビューにカラムを追加します。赤い枠の右下を見ると、ScalingReplicaSetというエントリーが確認できます。そこからリストを上に見てゆくと、イメージのpull、ボリュームのマウント、Podのスタートなどのイベントが確認できます。
+
+
+
+## {{% 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
+ 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. Podの一覧を問い合わせて、実行中のPodがなくなったことを確認します。
+
+ ```shell
+ kubectl get pods
+ ```
+
+ 結果は次のようになるはずです。
+
+ ```
+ No resources found.
+ ```
+
+## {{% heading "whatsnext" %}}
+
+* [リソースを監視するためのツール](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)について学ぶ。
+* [ロギングのアーキテクチャ](/docs/concepts/cluster-administration/logging/)についてもっと読む。
+* [アプリケーションのイントロスペクションとデバッグ](/ja/docs/tasks/debug-application-cluster/)についてもっと読む。
+* [アプリケーションのトラブルシューティング](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)についてもっと読む。
diff --git a/content/ja/docs/tutorials/stateless-application/guestbook.md b/content/ja/docs/tutorials/stateless-application/guestbook.md
new file mode 100644
index 0000000000..e08abdb62c
--- /dev/null
+++ b/content/ja/docs/tutorials/stateless-application/guestbook.md
@@ -0,0 +1,370 @@
+---
+title: "例: Redisを使用したPHPのゲストブックアプリケーションのデプロイ"
+content_type: tutorial
+weight: 20
+card:
+ name: tutorials
+ weight: 30
+ title: "ステートレスの例: Redisを使用したPHPのゲストブック"
+---
+
+
+このチュートリアルでは、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 >}}
+
+
+
+
+
+## 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 443/TCP 1m
+ redis-master ClusterIP 10.0.0.151 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 443/TCP 2m
+ redis-master ClusterIP 10.0.0.151 6379/TCP 1m
+ redis-slave ClusterIP 10.0.0.223 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 80:31323/TCP 6s
+ kubernetes ClusterIP 10.0.0.1 443/TCP 4m
+ redis-master ClusterIP 10.0.0.151 6379/TCP 2m
+ redis-slave ClusterIP 10.0.0.223 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)についてもっと読む
diff --git a/content/ja/examples/pods/pod-nginx-specific-node.yaml b/content/ja/examples/pods/pod-nginx-specific-node.yaml
new file mode 100644
index 0000000000..401814df92
--- /dev/null
+++ b/content/ja/examples/pods/pod-nginx-specific-node.yaml
@@ -0,0 +1,10 @@
+apiVersion: v1
+kind: Pod
+metadata:
+ name: nginx
+spec:
+ nodeName: foo-node # 特定のノードにPodをスケジューリングする
+ containers:
+ - name: nginx
+ image: nginx
+ imagePullPolicy: IfNotPresent
diff --git a/content/ja/examples/pods/pod-with-toleration.yaml b/content/ja/examples/pods/pod-with-toleration.yaml
new file mode 100644
index 0000000000..79f2756a8c
--- /dev/null
+++ b/content/ja/examples/pods/pod-with-toleration.yaml
@@ -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"
diff --git a/content/ja/examples/service/networking/dual-stack-default-svc.yaml b/content/ja/examples/service/networking/dual-stack-default-svc.yaml
new file mode 100644
index 0000000000..00ed87ba19
--- /dev/null
+++ b/content/ja/examples/service/networking/dual-stack-default-svc.yaml
@@ -0,0 +1,11 @@
+apiVersion: v1
+kind: Service
+metadata:
+ name: my-service
+spec:
+ selector:
+ app: MyApp
+ ports:
+ - protocol: TCP
+ port: 80
+ targetPort: 9376
\ No newline at end of file
diff --git a/content/ja/examples/service/networking/dual-stack-ipv4-svc.yaml b/content/ja/examples/service/networking/dual-stack-ipv4-svc.yaml
new file mode 100644
index 0000000000..a875f44d6d
--- /dev/null
+++ b/content/ja/examples/service/networking/dual-stack-ipv4-svc.yaml
@@ -0,0 +1,12 @@
+apiVersion: v1
+kind: Service
+metadata:
+ name: my-service
+spec:
+ ipFamily: IPv4
+ selector:
+ app: MyApp
+ ports:
+ - protocol: TCP
+ port: 80
+ targetPort: 9376
\ No newline at end of file
diff --git a/content/ja/examples/service/networking/dual-stack-ipv6-lb-svc.yaml b/content/ja/examples/service/networking/dual-stack-ipv6-lb-svc.yaml
new file mode 100644
index 0000000000..2586ec9b39
--- /dev/null
+++ b/content/ja/examples/service/networking/dual-stack-ipv6-lb-svc.yaml
@@ -0,0 +1,15 @@
+apiVersion: v1
+kind: Service
+metadata:
+ name: my-service
+ labels:
+ app: MyApp
+spec:
+ ipFamily: IPv6
+ type: LoadBalancer
+ selector:
+ app: MyApp
+ ports:
+ - protocol: TCP
+ port: 80
+ targetPort: 9376
\ No newline at end of file
diff --git a/content/ja/examples/service/networking/dual-stack-ipv6-svc.yaml b/content/ja/examples/service/networking/dual-stack-ipv6-svc.yaml
new file mode 100644
index 0000000000..2aa0725059
--- /dev/null
+++ b/content/ja/examples/service/networking/dual-stack-ipv6-svc.yaml
@@ -0,0 +1,12 @@
+apiVersion: v1
+kind: Service
+metadata:
+ name: my-service
+spec:
+ ipFamily: IPv6
+ selector:
+ app: MyApp
+ ports:
+ - protocol: TCP
+ port: 80
+ targetPort: 9376
\ No newline at end of file
diff --git a/content/ja/training/_index.html b/content/ja/training/_index.html
index 8c92ea7f22..6762f56dec 100644
--- a/content/ja/training/_index.html
+++ b/content/ja/training/_index.html
@@ -1,7 +1,7 @@
---
title: トレーニング
bigheader: Kubernetesのトレーニングと資格
-abstract: トレーニングプログラム、資格、及びパートナーについて。
+abstract: トレーニングプログラム、資格、およびパートナーについて。
layout: basic
cid: training
class: training
@@ -18,7 +18,7 @@ class: training
Kubeadm is a tool built to provide `kubeadm init` and `kubeadm join` as best-practice “fast paths” for creating Kubernetes clusters.
+
+kubeadm performs the actions necessary to get a minimum viable cluster up and running. By design, it cares only about bootstrapping, not about provisioning machines. Likewise, installing various nice-to-have addons, like the Kubernetes Dashboard, monitoring solutions, and cloud-specific addons, is not in scope.
+
+Instead, we expect higher-level and more tailored tooling to be built on top of kubeadm, and ideally, using kubeadm as the basis of all deployments will make it easier to create conformant clusters.
+
+## How to install
+
+To install kubeadm, see the [installation guide](/docs/setup/production-environment/tools/kubeadm/install-kubeadm).
+
+## {{% heading "whatsnext" %}}
+
+* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init) to bootstrap a Kubernetes control-plane node
+* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join) to bootstrap a Kubernetes worker node and join it to the cluster
+* [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade) to upgrade a Kubernetes cluster to a newer version
+* [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config) if you initialized your cluster using kubeadm v1.7.x or lower, to configure your cluster for `kubeadm upgrade`
+* [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token) to manage tokens for `kubeadm join`
+* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset) to revert any changes made to this host by `kubeadm init` or `kubeadm join`
+* [kubeadm version](/docs/reference/setup-tools/kubeadm/kubeadm-version) to print the kubeadm version
+* [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha) to preview a set of features made available for gathering feedback from the community
diff --git a/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md b/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md
index cb42a34df9..6abc42c131 100644
--- a/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md
+++ b/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md
@@ -15,7 +15,6 @@ However, it might not be obvious _how_ kubeadm does that.
This document provides additional details on what happen under the hood, with the aim of sharing knowledge on Kubernetes cluster best practices.
-
## Core design principles
@@ -518,6 +517,7 @@ Please note that:
- The automatic CSR approval is managed by the csrapprover controller, according with configuration done the `kubeadm init` process
### (optional) Write init kubelet configuration
+
{{< feature-state for_k8s_version="v1.9" state="alpha" >}}
If kubeadm is invoked with `--feature-gates=DynamicKubeletConfig`:
@@ -530,5 +530,3 @@ If kubeadm is invoked with `--feature-gates=DynamicKubeletConfig`:
Please note that:
1. To make dynamic kubelet configuration work, flag `--dynamic-config-dir=/var/lib/kubelet/config/dynamic` should be specified in `/etc/systemd/system/kubelet.service.d/10-kubeadm.conf`
-
-
diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-alpha.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-alpha.md
index c2356ed966..21a6e628a8 100644
--- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-alpha.md
+++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-alpha.md
@@ -3,8 +3,10 @@ reviewers:
- luxas
- jbeda
title: kubeadm alpha
+content_type: concept
weight: 90
---
+
{{< caution >}}
`kubeadm alpha` provides a preview of a set of features made available for gathering feedback
from the community. Please try it out and give us feedback!
@@ -67,7 +69,6 @@ Use the following command to enable the DynamicKubeletConfiguration feature.
{{< tab name="enable-dynamic" include="generated/kubeadm_alpha_kubelet_config_enable-dynamic.md" />}}
{{< /tabs >}}
-
## kubeadm alpha selfhosting pivot {#cmd-selfhosting}
The subcommand `pivot` can be used to convert a static Pod-hosted control plane into a self-hosted one.
@@ -79,8 +80,8 @@ The subcommand `pivot` can be used to convert a static Pod-hosted control plane
{{< tab name="pivot" include="generated/kubeadm_alpha_selfhosting_pivot.md" />}}
{{< /tabs >}}
+## {{% heading "whatsnext" %}}
-## What's next
* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) to bootstrap a Kubernetes control-plane node
* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) to connect a node to the cluster
* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) to revert any changes made to this host by `kubeadm init` or `kubeadm join`
diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-config.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-config.md
index a4b0e501d8..655f9ec875 100644
--- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-config.md
+++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-config.md
@@ -6,6 +6,7 @@ title: kubeadm config
content_type: concept
weight: 50
---
+
During `kubeadm init`, kubeadm uploads the `ClusterConfiguration` object to your cluster
in a ConfigMap called `kubeadm-config` in the `kube-system` namespace. This configuration is then read during
@@ -19,30 +20,31 @@ In Kubernetes v1.13.0 and later to list/pull kube-dns images instead of the Core
the `--config` method described [here](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-addon)
has to be used.
-
-
## kubeadm config view {#cmd-config-view}
+
{{< include "generated/kubeadm_config_view.md" >}}
## kubeadm config print init-defaults {#cmd-config-print-init-defaults}
+
{{< include "generated/kubeadm_config_print_init-defaults.md" >}}
## kubeadm config print join-defaults {#cmd-config-print-join-defaults}
+
{{< include "generated/kubeadm_config_print_join-defaults.md" >}}
## kubeadm config migrate {#cmd-config-migrate}
+
{{< include "generated/kubeadm_config_migrate.md" >}}
## kubeadm config images list {#cmd-config-images-list}
+
{{< include "generated/kubeadm_config_images_list.md" >}}
## kubeadm config images pull {#cmd-config-images-pull}
+
{{< include "generated/kubeadm_config_images_pull.md" >}}
-
-
## {{% heading "whatsnext" %}}
* [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade/) to upgrade a Kubernetes cluster to a newer version
-
diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init-phase.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init-phase.md
index e3fe8c543c..289767e1e1 100644
--- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init-phase.md
+++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init-phase.md
@@ -1,7 +1,9 @@
---
title: kubeadm init phase
weight: 90
+content_type: concept
---
+
`kubeadm init phase` enables you to invoke atomic steps of the bootstrap process.
Hence, you can let kubeadm do some of the work and you can fill in the gaps
if you wish to apply customization.
@@ -80,7 +82,6 @@ Use the following phase to create a local etcd instance based on a static Pod fi
{{< tab name="local" include="generated/kubeadm_init_phase_etcd_local.md" />}}
{{< /tabs >}}
-
## kubeadm init phase upload-config {#cmd-phase-upload-config}
You can use this command to upload the kubeadm configuration to your cluster.
@@ -93,7 +94,6 @@ Alternatively, you can use [kubeadm config](/docs/reference/setup-tools/kubeadm/
{{< tab name="kubelet" include="generated/kubeadm_init_phase_upload-config_kubelet.md" />}}
{{< /tabs >}}
-
## kubeadm init phase upload-certs {#cmd-phase-upload-certs}
Use the following phase to upload control-plane certificates to the cluster.
@@ -103,7 +103,6 @@ By default the certs and encryption key expire after two hours.
{{< tab name="upload-certs" include="generated/kubeadm_init_phase_upload-certs.md" />}}
{{< /tabs >}}
-
## kubeadm init phase mark-control-plane {#cmd-phase-mark-control-plane}
Use the following phase to label and taint the node with the `node-role.kubernetes.io/master=""` key-value pair.
@@ -112,7 +111,6 @@ Use the following phase to label and taint the node with the `node-role.kubernet
{{< tab name="mark-control-plane" include="generated/kubeadm_init_phase_mark-control-plane.md" />}}
{{< /tabs >}}
-
## kubeadm init phase bootstrap-token {#cmd-phase-bootstrap-token}
Use the following phase to configure bootstrap tokens.
@@ -156,7 +154,8 @@ Please note that kube-dns usage with kubeadm is deprecated as of v1.18 and will
For more details on each field in the `v1beta2` configuration you can navigate to our
[API reference pages.] (https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2)
-## What's next
+## {{% heading "whatsnext" %}}
+
* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) to bootstrap a Kubernetes control-plane node
* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) to connect a node to the cluster
* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) to revert any changes made to this host by `kubeadm init` or `kubeadm join`
diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md
index 54729065c6..997240399e 100644
--- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md
+++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md
@@ -9,12 +9,12 @@ weight: 20
This command initializes a Kubernetes control-plane node.
-
{{< include "generated/kubeadm_init.md" >}}
### Init workflow {#init-workflow}
+
`kubeadm init` bootstraps a Kubernetes control-plane node by executing the
following steps:
@@ -166,7 +166,7 @@ to download the certificates when additional control-plane nodes are joining, by
The following phase command can be used to re-upload the certificates after expiration:
-```
+```shell
kubeadm init phase upload-certs --upload-certs --certificate-key=SOME_VALUE --config=SOME_YAML_FILE
```
@@ -175,7 +175,7 @@ If the flag `--certificate-key` is not passed to `kubeadm init` and
The following command can be used to generate a new key on demand:
-```
+```shell
kubeadm alpha certs certificate-key
```
@@ -226,26 +226,26 @@ token distribution for easier automation. To implement this automation, you must
know the IP address that the control-plane node will have after it is started,
or use a DNS name or an address of a load balancer.
-1. Generate a token. This token must have the form `<6 character string>.<16
- character string>`. More formally, it must match the regex:
- `[a-z0-9]{6}\.[a-z0-9]{16}`.
+1. Generate a token. This token must have the form `<6 character string>.<16
+ character string>`. More formally, it must match the regex:
+ `[a-z0-9]{6}\.[a-z0-9]{16}`.
- kubeadm can generate a token for you:
+ kubeadm can generate a token for you:
- ```shell
+ ```shell
kubeadm token generate
- ```
+ ```
-1. Start both the control-plane node and the worker nodes concurrently with this token.
- As they come up they should find each other and form the cluster. The same
- `--token` argument can be used on both `kubeadm init` and `kubeadm join`.
+1. Start both the control-plane node and the worker nodes concurrently with this token.
+ As they come up they should find each other and form the cluster. The same
+ `--token` argument can be used on both `kubeadm init` and `kubeadm join`.
-1. Similar can be done for `--certificate-key` when joining additional control-plane
- nodes. The key can be generated using:
+1. Similar can be done for `--certificate-key` when joining additional control-plane
+ nodes. The key can be generated using:
- ```shell
- kubeadm alpha certs certificate-key
- ```
+ ```shell
+ kubeadm alpha certs certificate-key
+ ```
Once the cluster is up, you can grab the admin credentials from the control-plane node
at `/etc/kubernetes/admin.conf` and use that to talk to the cluster.
@@ -255,8 +255,6 @@ it does not allow the root CA hash to be validated with
`--discovery-token-ca-cert-hash` (since it's not generated when the nodes are
provisioned). For details, see the [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/).
-
-
## {{% heading "whatsnext" %}}
* [kubeadm init phase](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/) to understand more about
@@ -264,4 +262,3 @@ provisioned). For details, see the [kubeadm join](/docs/reference/setup-tools/ku
* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) to bootstrap a Kubernetes worker node and join it to the cluster
* [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade/) to upgrade a Kubernetes cluster to a newer version
* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) to revert any changes made to this host by `kubeadm init` or `kubeadm join`
-
diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join-phase.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join-phase.md
index c26c0a2e4b..c41054b543 100644
--- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join-phase.md
+++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join-phase.md
@@ -1,7 +1,9 @@
---
title: kubeadm join phase
weight: 90
+content_type: concept
---
+
`kubeadm join phase` enables you to invoke atomic steps of the join process.
Hence, you can let kubeadm do some of the work and you can fill in the gaps
if you wish to apply customization.
@@ -56,7 +58,8 @@ Using this phase you can join a node as a control-plane instance.
{{< tab name="mark-control-plane" include="generated/kubeadm_join_phase_control-plane-join_mark-control-plane.md" />}}
{{< /tabs >}}
-## What's next
+## {{% heading "whatsnext" %}}
+
* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) to bootstrap a Kubernetes control-plane node
* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) to connect a node to the cluster
* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) to revert any changes made to this host by `kubeadm init` or `kubeadm join`
diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md
index d83fb98436..28d489cfb6 100644
--- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md
+++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md
@@ -9,7 +9,6 @@ weight: 30
This command initializes a Kubernetes worker node and joins it to the cluster.
-
{{< include "generated/kubeadm_join.md" >}}
@@ -105,18 +104,18 @@ if the `kubeadm init` command was called with `--upload-certs`.
**Advantages:**
- - Allows bootstrapping nodes to securely discover a root of trust for the
- control-plane node even if other worker nodes or the network are compromised.
+- Allows bootstrapping nodes to securely discover a root of trust for the
+ control-plane node even if other worker nodes or the network are compromised.
- - Convenient to execute manually since all of the information required fits
- into a single `kubeadm join` command that is easy to copy and paste.
+- Convenient to execute manually since all of the information required fits
+ into a single `kubeadm join` command that is easy to copy and paste.
**Disadvantages:**
- - The CA hash is not normally known until the control-plane node has been provisioned,
- which can make it more difficult to build automated provisioning tools that
- use kubeadm. By generating your CA in beforehand, you may workaround this
- limitation.
+- The CA hash is not normally known until the control-plane node has been provisioned,
+ which can make it more difficult to build automated provisioning tools that
+ use kubeadm. By generating your CA in beforehand, you may workaround this
+ limitation.
#### Token-based discovery without CA pinning
@@ -134,18 +133,18 @@ kubeadm join --token abcdef.1234567890abcdef --discovery-token-unsafe-skip-ca-ve
**Advantages:**
- - Still protects against many network-level attacks.
+- Still protects against many network-level attacks.
- - The token can be generated ahead of time and shared with the control-plane node and
- worker nodes, which can then bootstrap in parallel without coordination. This
- allows it to be used in many provisioning scenarios.
+- The token can be generated ahead of time and shared with the control-plane node and
+ worker nodes, which can then bootstrap in parallel without coordination. This
+ allows it to be used in many provisioning scenarios.
**Disadvantages:**
- - If an attacker is able to steal a bootstrap token via some vulnerability,
- they can use that token (along with network-level access) to impersonate the
- control-plane node to other bootstrapping nodes. This may or may not be an appropriate
- tradeoff in your environment.
+- If an attacker is able to steal a bootstrap token via some vulnerability,
+ they can use that token (along with network-level access) to impersonate the
+ control-plane node to other bootstrapping nodes. This may or may not be an appropriate
+ tradeoff in your environment.
#### File or HTTPS-based discovery
@@ -158,21 +157,21 @@ In case the discovery file does not contain credentials, the TLS discovery token
**Example `kubeadm join` commands:**
- - `kubeadm join --discovery-file path/to/file.conf` (local file)
+- `kubeadm join --discovery-file path/to/file.conf` (local file)
- - `kubeadm join --discovery-file https://url/file.conf` (remote HTTPS URL)
+- `kubeadm join --discovery-file https://url/file.conf` (remote HTTPS URL)
**Advantages:**
- - Allows bootstrapping nodes to securely discover a root of trust for the
- control-plane node even if the network or other worker nodes are compromised.
+- Allows bootstrapping nodes to securely discover a root of trust for the
+ control-plane node even if the network or other worker nodes are compromised.
**Disadvantages:**
- - Requires that you have some way to carry the discovery information from
- the control-plane node to the bootstrapping nodes. If the discovery file contains credentials
- you must keep it secret and transfer it over a secure channel. This might be possible with your
- cloud provider or provisioning tool.
+- Requires that you have some way to carry the discovery information from
+ the control-plane node to the bootstrapping nodes. If the discovery file contains credentials
+ you must keep it secret and transfer it over a secure channel. This might be possible with your
+ cloud provider or provisioning tool.
### Securing your installation even more {#securing-more}
@@ -194,7 +193,9 @@ After that, `kubeadm join` will block until the admin has manually approved the
```shell
kubectl get csr
```
+
The output is similar to this:
+
```
NAME AGE REQUESTOR CONDITION
node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ 18s system:bootstrap:878f07 Pending
@@ -203,7 +204,9 @@ node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ 18s system:bootstra
```shell
kubectl certificate approve node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ
```
+
The output is similar to this:
+
```
certificatesigningrequest "node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ" approved
```
@@ -211,7 +214,9 @@ certificatesigningrequest "node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ"
```shell
kubectl get csr
```
+
The output is similar to this:
+
```
NAME AGE REQUESTOR CONDITION
node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ 1m system:bootstrap:878f07 Approved,Issued
@@ -232,7 +237,9 @@ it off regardless. Doing so will disable the ability to use the `--discovery-tok
```shell
kubectl -n kube-public get cm cluster-info -o yaml | grep "kubeconfig:" -A11 | grep "apiVersion" -A10 | sed "s/ //" | tee cluster-info.yaml
```
+
The output is similar to this:
+
```
apiVersion: v1
kind: Config
@@ -276,11 +283,8 @@ kubeadm config print join-defaults
For details on individual fields in `JoinConfiguration` see [the godoc](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#JoinConfiguration).
-
-
## {{% heading "whatsnext" %}}
* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) to bootstrap a Kubernetes control-plane node
* [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token/) to manage tokens for `kubeadm join`
* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) to revert any changes made to this host by `kubeadm init` or `kubeadm join`
-
diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-reset-phase.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-reset-phase.md
index 663bb67e24..95c8ea129f 100644
--- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-reset-phase.md
+++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-reset-phase.md
@@ -1,7 +1,9 @@
---
title: kubeadm reset phase
weight: 90
+content_type: concept
---
+
`kubeadm reset phase` enables you to invoke atomic steps of the node reset process.
Hence, you can let kubeadm do some of the work and you can fill in the gaps
if you wish to apply customization.
@@ -47,7 +49,8 @@ Using this phase you can perform cleanup on this node.
{{< tab name="cleanup-node" include="generated/kubeadm_reset_phase_cleanup-node.md" />}}
{{< /tabs >}}
-## What's next
+## {{% heading "whatsnext" %}}
+
* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) to bootstrap a Kubernetes control-plane node
* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) to connect a node to the cluster
* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) to revert any changes made to this host by `kubeadm init` or `kubeadm join`
diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-reset.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-reset.md
index 2664283daa..93d5ce0cbb 100644
--- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-reset.md
+++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-reset.md
@@ -9,7 +9,6 @@ weight: 60
Performs a best effort revert of changes made by `kubeadm init` or `kubeadm join`.
-
{{< include "generated/kubeadm_reset.md" >}}
@@ -36,9 +35,7 @@ etcdctl del "" --prefix
See the [etcd documentation](https://github.com/coreos/etcd/tree/master/etcdctl) for more information.
-
## {{% heading "whatsnext" %}}
* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) to bootstrap a Kubernetes control-plane node
* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) to bootstrap a Kubernetes worker node and join it to the cluster
-
diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-token.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-token.md
index 92a187bb92..6edb87557d 100644
--- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-token.md
+++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-token.md
@@ -14,8 +14,6 @@ the cluster and a control-plane node, as described in [authenticating with boots
`kubeadm init` creates an initial token with a 24-hour TTL. The following commands allow you to manage
such a token and also to create and manage new ones.
-
-
## kubeadm token create {#cmd-token-create}
{{< include "generated/kubeadm_token_create.md" >}}
@@ -29,8 +27,6 @@ such a token and also to create and manage new ones.
## kubeadm token list {#cmd-token-list}
{{< include "generated/kubeadm_token_list.md" >}}
-
## {{% heading "whatsnext" %}}
* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) to bootstrap a Kubernetes worker node and join it to the cluster
-
diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-upgrade-phase.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-upgrade-phase.md
index 6224a18e0e..a7f4b6d1a6 100644
--- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-upgrade-phase.md
+++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-upgrade-phase.md
@@ -1,6 +1,7 @@
---
title: kubeadm upgrade phase
weight: 90
+content_type: concept
---
In v1.15.0, kubeadm introduced preliminary support for `kubeadm upgrade node` phases.
Phases for other `kubeadm upgrade` sub-commands such as `apply`, could be added in the
@@ -18,7 +19,8 @@ be called on a primary control-plane node.
{{< tab name="kubelet-config" include="generated/kubeadm_upgrade_node_phase_kubelet-config.md" />}}
{{< /tabs >}}
-## What's next
+## {{% heading "whatsnext" %}}
+
* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) to bootstrap a Kubernetes control-plane node
* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) to connect a node to the cluster
* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) to revert any changes made to this host by `kubeadm init` or `kubeadm join`
diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md
index 71483aa1d6..5796e7aec7 100644
--- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md
+++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md
@@ -47,8 +47,6 @@ reports of unexpected results.
{{< include "generated/kubeadm_upgrade_node.md" >}}
-
## {{% heading "whatsnext" %}}
* [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config/) if you initialized your cluster using kubeadm v1.7.x or lower, to configure your cluster for `kubeadm upgrade`
-
diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-version.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-version.md
index a4b57e796c..aabd8dd656 100644
--- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-version.md
+++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-version.md
@@ -9,7 +9,5 @@ weight: 80
This command prints the version of kubeadm.
-
{{< include "generated/kubeadm_version.md" >}}
-
diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm.md
deleted file mode 100644
index 8c16518bb2..0000000000
--- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm.md
+++ /dev/null
@@ -1,30 +0,0 @@
----
-reviewers:
-- luxas
-- jbeda
-title: Overview of kubeadm
-weight: 10
-card:
- name: reference
- weight: 40
----
-
+