fix 24484

This commit is contained in:
opeco17
2020-08-25 00:43:25 +09:00
committed by inductor
parent a74f06a0fe
commit 87c0bcadcd
@@ -34,9 +34,9 @@ kubectl exec <POD-NAME> -c <CONTAINER-NAME> -- <COMMAND>
このドキュメントのウォークスルーのために、いくつかのPodを実行しましょう。おそらくあなた自身のServiceをデバッグしているため、あなた自身の詳細に置き換えることもできますし、これに沿って2番目のデータポイントを取得することもできます。 このドキュメントのウォークスルーのために、いくつかのPodを実行しましょう。おそらくあなた自身のServiceをデバッグしているため、あなた自身の詳細に置き換えることもできますし、これに沿って2番目のデータポイントを取得することもできます。
```shell ```shell
kubectl run hostnames --image=k8s.gcr.io/serve_hostname \ kubectl create deployment hostnames --image=k8s.gcr.io/serve_hostname
--replicas=3
``` ```
```none ```none
deployment.apps/hostnames created deployment.apps/hostnames created
@@ -45,6 +45,15 @@ deployment.apps/hostnames created
`kubectl`コマンドは作成、変更されたリソースのタイプと名前を出力するため、この後のコマンドで使用することもできます。 `kubectl`コマンドは作成、変更されたリソースのタイプと名前を出力するため、この後のコマンドで使用することもできます。
Deplymentを3つのreplicaにスケールさせてみましょう。
```shell
kubectl scale deployment hostnames --replicas=3
```
```none
deployment.apps/hostnames scaled
```
これは、次のYAMLでDeploymentを開始した場合と同じです。 これは、次のYAMLでDeploymentを開始した場合と同じです。
```yaml ```yaml
@@ -52,27 +61,29 @@ apiVersion: apps/v1
kind: Deployment kind: Deployment
metadata: metadata:
name: hostnames name: hostnames
labels:
app: hostnames
spec: spec:
selector: selector:
matchLabels: matchLabels:
run: hostnames app: hostnames
replicas: 3 replicas: 3
template: template:
metadata: metadata:
labels: labels:
run: hostnames app: hostnames
spec: spec:
containers: containers:
- name: hostnames - name: hostnames
image: k8s.gcr.io/serve_hostname image: k8s.gcr.io/serve_hostname
``` ```
"run"ラベルは`kubectl run`によって、Deploymentの名前に自動的にセットされます。 "app"ラベルは`kubectl create deployment`によって、Deploymentの名前に自動的にセットされます。
Podが実行されていることを確認できます。 Podが実行されていることを確認できます。
```shell ```shell
kubectl get pods -l run=hostnames kubectl get pods -l app=hostnames
``` ```
```none ```none
NAME READY STATUS RESTARTS AGE NAME READY STATUS RESTARTS AGE
@@ -84,7 +95,7 @@ hostnames-632524106-tlaok 1/1 Running 0 2m
Podが機能していることも確認できます。Pod IP アドレスリストを取得し、直接テストできます。 Podが機能していることも確認できます。Pod IP アドレスリストを取得し、直接テストできます。
```shell ```shell
kubectl get pods -l run=hostnames \ kubectl get pods -l app=hostnames \
-o go-template='{{range .items}}{{.status.podIP}}{{"\n"}}{{end}}' -o go-template='{{range .items}}{{.status.podIP}}{{"\n"}}{{end}}'
``` ```
```none ```none
@@ -106,9 +117,9 @@ done
次のように表示されます。 次のように表示されます。
``` ```
hostnames-0uton hostnames-632524106-bbpiw
hostnames-bvc05 hostnames-632524106-ly40y
hostnames-yp2kp hostnames-632524106-tlaok
``` ```
この時点で期待通りの応答が得られない場合、Podが正常でないか、想定しているポートでリッスンしていない可能性があります。なにが起きているかを確認するために`kubectl logs`が役立ちます。Podに直接に入りデバッグする場合は`kubectl exec`が必要になります。 この時点で期待通りの応答が得られない場合、Podが正常でないか、想定しているポートでリッスンしていない可能性があります。なにが起きているかを確認するために`kubectl logs`が役立ちます。Podに直接に入りデバッグする場合は`kubectl exec`が必要になります。
@@ -312,7 +323,7 @@ kubectl get service hostnames -o json
"resourceVersion": "347189", "resourceVersion": "347189",
"creationTimestamp": "2015-07-07T15:24:29Z", "creationTimestamp": "2015-07-07T15:24:29Z",
"labels": { "labels": {
"run": "hostnames" "app": "hostnames"
} }
}, },
"spec": { "spec": {
@@ -326,7 +337,7 @@ kubectl get service hostnames -o json
} }
], ],
"selector": { "selector": {
"run": "hostnames" "app": "hostnames"
}, },
"clusterIP": "10.0.1.175", "clusterIP": "10.0.1.175",
"type": "ClusterIP", "type": "ClusterIP",
@@ -351,15 +362,15 @@ kubectl get service hostnames -o json
以前に、Podが実行されていることを確認しました。再確認しましょう。 以前に、Podが実行されていることを確認しました。再確認しましょう。
```shell ```shell
kubectl get pods -l run=hostnames kubectl get pods -l app=hostnames
``` ```
```none ```none
NAME READY STATUS RESTARTS AGE NAME READY STATUS RESTARTS AGE
hostnames-0uton 1/1 Running 0 1h hostnames-632524106-bbpiw 1/1 Running 0 1h
hostnames-bvc05 1/1 Running 0 1h hostnames-632524106-ly40y 1/1 Running 0 1h
hostnames-yp2kp 1/1 Running 0 1h hostnames-632524106-tlaok 1/1 Running 0 1h
``` ```
`-l run=hostnames`引数はラベルセレクターで、ちょうど私たちの`Service`に定義されているものと同じです。 `-l app=hostnames`引数はラベルセレクターで、ちょうど私たちの`Service`に定義されているものと同じです。
"AGE"列は、これらのPodが約1時間前のものであることを示しており、それらが正常に実行され、クラッシュしていないことを意味します。 "AGE"列は、これらのPodが約1時間前のものであることを示しており、それらが正常に実行され、クラッシュしていないことを意味します。
@@ -374,7 +385,7 @@ NAME ENDPOINTS
hostnames 10.244.0.5:9376,10.244.0.6:9376,10.244.0.7:9376 hostnames 10.244.0.5:9376,10.244.0.6:9376,10.244.0.7:9376
``` ```
これにより、EndpointsコントローラーがServiceの正しいPodを見つけていることを確認できます。`ENDPOINTS`列が`<none>`の場合、Serviceの`spec.selector`フィールドが実際にPodの`metadata.labels`値を選択していることを確認する必要があります。よくある間違いは、タイプミスまたは他のエラー、たとえばServiceが`app=hostnames`を選択しているのにDeploymentが`run=hostnames`を指定していることです。 これにより、EndpointsコントローラーがServiceの正しいPodを見つけていることを確認できます。`ENDPOINTS`列が`<none>`の場合、Serviceの`spec.selector`フィールドが実際にPodの`metadata.labels`値を選択していることを確認する必要があります。よくある間違いは、1.18以前のバージョンのように、Serviceが`app=hostnames`を選択しているのにDeploymentが`run=hostnames`を指定しているなど、タイプミスやその他のエラーがあることや、`kubectl run`によってDeploymentを作成することです。
## Podは機能しているか? ## Podは機能しているか?
@@ -395,9 +406,9 @@ done
次のように表示されます。 次のように表示されます。
``` ```
hostnames-0uton hostnames-632524106-bbpiw
hostnames-bvc05 hostnames-632524106-ly40y
hostnames-yp2kp hostnames-632524106-tlaok
``` ```
Endpointsリスト内の各Podは、それぞれの自身のホスト名を返すはずです。そうならない(または、あなた自身のPodの正しい振る舞いにならない)場合は、そこで何が起こっているのかを調査する必要があります。 Endpointsリスト内の各Podは、それぞれの自身のホスト名を返すはずです。そうならない(または、あなた自身のPodの正しい振る舞いにならない)場合は、そこで何が起こっているのかを調査する必要があります。
@@ -510,7 +521,7 @@ iptables-save | grep hostnames
curl 10.0.1.175:80 curl 10.0.1.175:80
``` ```
```none ```none
hostnames-0uton hostnames-632524106-bbpiw
``` ```
もしこれが失敗し、あなたがuserspaceプロキシーを使用している場合、プロキシーへの直接アクセスを試してみてください。もしiptablesプロキシーを使用している場合、このセクションはスキップしてください。 もしこれが失敗し、あなたがuserspaceプロキシーを使用している場合、プロキシーへの直接アクセスを試してみてください。もしiptablesプロキシーを使用している場合、このセクションはスキップしてください。
@@ -521,7 +532,7 @@ hostnames-0uton
curl localhost:48577 curl localhost:48577
``` ```
```none ```none
hostnames-yp2kp hostnames-632524106-tlaok
``` ```
もしまだ失敗する場合は、`kube-proxy`ログで次のような特定の行を探してください。 もしまだ失敗する場合は、`kube-proxy`ログで次のような特定の行を探してください。
@@ -534,7 +545,7 @@ Setting endpoints for default/hostnames:default to [10.244.0.5:9376 10.244.0.6:9
### エッジケース: 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/reference/command-line-tools-reference/kubelet/)を公開します。これにより、Serviceのエンドポイントが自身のServiceのVIPにアクセスしようとした場合に、自身への負荷分散を可能にします。`hairpin-mode`フラグは`hairpin-veth`または`promiscuous-bridge`に設定する必要があります。
この問題をトラブルシューティングする一般的な手順は次のとおりです。 この問題をトラブルシューティングする一般的な手順は次のとおりです。
@@ -580,13 +591,11 @@ 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/tasks/debug-application-cluster/troubleshooting/#slack)、[Forum](https://discuss.kubernetes.io)または[GitHub](https://github.com/kubernetes/kubernetes)でお問い合わせください。
## {{% heading "whatsnext" %}} ## {{% heading "whatsnext" %}}
詳細については、[トラブルシューティングドキュメント](/docs/troubleshooting/)をご覧ください。 詳細については、[トラブルシューティングドキュメント](/docs/tasks/debug-application-cluster/troubleshooting/)をご覧ください。