Code change:
This is a Feature Request What would you like to be Translate docs/setup/production-environment/windows/intro-windows-in-kubernetes/ into Japanese Why is this needed This page has not been translated. Comments /language ja /assign
/close
Closing this issue. <detailsIn response to : /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details

Related discussion:
text: ``` <del> For initial troubleshooting, you can use the following flags in [nssm.exe](https://nssm.cc/) to redirect stdout and stderr to a output file: </del> <ins> 最初のトラブルシューティングでは、[nssm.exe](https://nssm.cc/)で次のフラグを使用して、stdoutおよびstderrを出力ファイルにリダイレクトできます。: </ins> ```powershell nssm set <Service Name> AppStdout C:kmysvc.log nssm set <Service Name> AppStderr C:kmysvc.log ``` <del> For additional details, see official [nssm usage](https://nssm.cc/usage) docs. </del> <ins> 詳細については、公式の[nssmの使用法](https://nssm.cc/usage)のドキュメントを参照してください。 </ins> <del> 1. My Windows Pods do not have network connectivity </del> <ins> 1. Windows Podにネットワーク接続がありません </ins> <del> If you are using virtual machines, ensure that MAC spoofing is enabled on all the VM network adapter(s). </del> <ins> 仮想マシンを使用している場合は、すべてのVMネットワークアダプターでMACスプーフィングが有効になっていることを確認してください。 </ins> <del> 1. My Windows Pods cannot ping external resources </del> <ins> 1. Windows Podが外部リソースにpingできません </ins> <del> Windows Pods do not have outbound rules programmed for the ICMP protocol today. However, TCP/UDP is supported. When trying to demonstrate connectivity to resources outside of the cluster, please substitute `ping <IP>` with corresponding `curl <IP>` commands. </del> <ins> 現在、Windows Podには、ICMPプロトコル用にプログラムされた送信ルールはありません。ただし、TCP/UDPはサポートされています。クラスター外のリソースへの接続を実証する場合は、`ping <IP>`に対応する`curl <IP>`コマンドに置き換えてください。 </ins> <del> If you are still facing problems, most likely your network configuration in [cni.conf](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/cni/config/cni.conf) deserves some extra attention. You can always edit this static file. The configuration update will apply to any newly created Kubernetes resources. </del> <ins> それでも問題が解決しない場合は、[cni.conf](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/cni/config/cni.conf)のネットワーク構成に値する可能性があるので、いくつかの特別な注意が必要です。この静的ファイルはいつでも編集できます。構成の更新は、新しく作成されたすべてのKubernetesリソースに適用されます。 </ins> <del> One of the Kubernetes networking requirements (see [Kubernetes model](/ja/docs/concepts/cluster-administration/networking/)) is for cluster communication to occur without NAT internally. To honor this requirement, there is an [ExceptionList](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/cni/config/cni.conf#L20) for all the communication where we do not want outbound NAT to occur. However, this also means that you need to exclude the external IP you are trying to query from the ExceptionList. Only then will the traffic originating from your Windows pods be SNAT'ed correctly to receive a response from the outside world. In this regard, your ExceptionList in `cni.conf` should look as follows: </del> <ins> Kubernetesのネットワーキング要件の1つ(参照[Kubernetesモデル](/ja/docs/concepts/cluster-administration/networking/))は、内部でNATを使用せずにクラスター通信を行うためのものです。この要件を遵守するために、すべての通信に[ExceptionList](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/cni/config/cni.conf#L20)があり、アウトバウンドNATが発生しないようにします。ただし、これは、クエリしようとしている外部IPをExceptionListから除外する必要があることも意味します。そうして初めて、Windows PodからのトラフィックがSNAT処理され、外部からの応答を受信できるようになります。この点で、`cni.conf`のExceptionListは次のようになります。: </ins> ```conf "ExceptionList": [ <del> "10.244.0.0/16",  # Cluster subnet "10.96.0.0/12",   # Service subnet "10.127.130.0/24" # Management (host) subnet </del> <ins> "10.244.0.0/16",  # クラスターのサブネット "10.96.0.0/12",   # Serviceのサブネット "10.127.130.0/24" # 管理 (ホスト) のサブネット </ins> ] ``` <del> 1. My Windows node cannot access NodePort service </del> <ins> 1. WindowsノードがNodePort Serviceにアクセスできません </ins> <del> Local NodePort access from the node itself fails. This is a known limitation. NodePort access works from other nodes or external clients. </del> <ins> ノード自体からのローカルNodePortアクセスは失敗します。これは既知の制限です。NodePortアクセスは、他のノードまたは外部クライアントから行えます。 </ins> <del> 1. vNICs and HNS endpoints of containers are being deleted </del> <ins> 1. コンテナのvNICとHNSエンドポイントが削除されています </ins> <del> This issue can be caused when the `hostname-override` parameter is not passed to [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/). To resolve it, users need to pass the hostname to kube-proxy as follows: </del> <ins> この問題は、`hostname-override`パラメータが[kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/)に渡されない場合に発生する可能性があります。これを解決するには、ユーザーは次のようにホスト名をkube-proxyに渡す必要があります。: </ins> ```powershell C:kkube-proxy.exe --hostname-override=$(hostname) ``` <del> 1. With flannel my nodes are having issues after rejoining a cluster </del> <ins> 1. flannelを使用すると、クラスターに再参加した後、ノードに問題が発生します </ins> <del> Whenever a previously deleted node is being re-joined to the cluster, flannelD tries to assign a new pod subnet to the node. Users should remove the old pod subnet configuration files in the following paths: </del> <ins> 以前に削除されたノードがクラスターに再参加するときはいつも、flannelDは新しいPodサブネットをノードに割り当てようとします。ユーザーは、次のパスにある古いPodサブネット構成ファイルを削除する必要があります。: </ins> ```powershell Remove-Item C:kSourceVip.json Remove-Item C:kSourceVipRequest.json ``` <del> 1. After launching `start.ps1`, flanneld is stuck in "Waiting for the Network to be created" </del> <ins> 1. `start.ps1`を起動した後、flanneldが「ネットワークが作成されるのを待っています」と表示されたままになります </ins> <del> There are numerous reports of this [issue which are being investigated](https://github.com/coreos/flannel/issues/1066); most likely it is a timing issue for when the management IP of the flannel network is set. A workaround is to simply relaunch start.ps1 or relaunch it manually as follows: </del> <ins> この[調査中の問題](https://github.com/coreos/flannel/issues/1066)に関する多数の報告があります。最も可能性が高いのは、flannelネットワークの管理IPが設定されるタイミングの問題です。回避策は、単純にstart.ps1を再起動するか、次のように手動で再起動することです。: </ins> ```powershell PS C:> [Environment]::SetEnvironmentVariable("NODE_NAME", "<Windows_Worker_Hostname>") PS C:> C:flannelflanneld.exe --kubeconfig-file=c:kconfig --iface=<Windows_Worker_Node_IP> --ip-masq=1 --kube-subnet-mgr=1 ``` <del> 1. My Windows Pods cannot launch because of missing `/run/flannel/subnet.env` </del> <ins> 1. `/run/flannel/subnet.env`がないため、Windows Podを起動できません </ins> <del> 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:runflannelsubnet.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: </del> <ins> これは、Flannelが正しく起動しなかったことを示しています。 flanneld.exeの再起動を試みるか、Kubernetesマスターの`/run/flannel/subnet.env`からWindowsワーカーノードの`C:runflannelsubnet.env`に手動でファイルをコピーすることができます。「FLANNEL_SUBNET」行を別の番号に変更します。たとえば、ノードサブネット10.244.4.1/24が必要な場合は以下となります。: </ins> ```env FLANNEL_NETWORK=10.244.0.0/16