Apply suggestions from code review
Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>pull/34162/head
Kaito Ii
GitHub
parent
3065803a41
commit
e1d56397ad
|
|
@ -27,7 +27,7 @@ no_list: true
|
|||
|
||||
本サイトのドキュメントは、様々な疑問に対する答えを提供するために構成されています。
|
||||
|
||||
[コンセプト](/ja/docs/concepts/)では、Kubernetesのアーキテクチャーと各コンポーネントの動作について説明し、[セットアップ](/ja/docs/setup/)では、使い始めるための実用的な手順を提供しています。
|
||||
[コンセプト](/ja/docs/concepts/)では、Kubernetesのアーキテクチャと各コンポーネントの動作について説明し、[セットアップ](/ja/docs/setup/)では、使い始めるための実用的な手順を提供しています。
|
||||
[タスク](/ja/docs/tasks/) は、よく使われるタスクの実行方法を示し、 [チュートリアル](/ja/docs/tutorials/)は、実世界の業界特有、またはエンドツーエンドの開発シナリオ、より包括的なウォークスルーとなります。
|
||||
[リファレンス](/ja/docs/reference/)セクションでは、[Kubernetes API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)や[`kubectl`](/docs/reference/kubectl/overview/)などのコマンドラインインターフェース(CLI)に関する詳しいドキュメントが提供されています。
|
||||
|
||||
|
|
|
|||
|
|
@ -137,7 +137,7 @@ Podの`containerPort`がServiceの`targetPort`と一致することを確認し
|
|||
## {{% heading "whatsnext" %}}
|
||||
|
||||
上記のいずれの方法でも問題が解決しない場合は、以下の手順に従ってください。
|
||||
[Serviceのデバッグに関するドキュメント](/ja/docs/tasks/debug/debug-application/debug-service/)で、`Service` が実行されていること、`Endpoints`があること、`Pods`が実際にサービスを提供していること、DNS が機能していること、IPtablesルールがインストールされていること、kube-proxyが誤作動を起こしていないようなことを確認してください。
|
||||
[Serviceのデバッグに関するドキュメント](/ja/docs/tasks/debug/debug-application/debug-service/)で、`Service`が実行されていること、`Endpoints`があること、`Pods`が実際にサービスを提供していること、DNSが機能していること、IPtablesルールがインストールされていること、kube-proxyが誤作動を起こしていないようなことを確認してください。
|
||||
|
||||
[トラブルシューティングドキュメント](/ja/docs/tasks/debug/)に詳細が記載されています。
|
||||
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ content_type: task
|
|||
|
||||
* あなたの{{< glossary_tooltip text="Pod" term_id="pod" >}}は既にスケジュールされ、実行されているはずです。Podがまだ実行されていない場合は、[Troubleshoot Applications](/ja/docs/tasks/debug/debug-application/) から始めてください。
|
||||
|
||||
* いくつかの高度なデバッグ手順では、Podがどのノードで動作しているかを知り、そのノードでコマンドを実行するためのシェルアクセス権を持っていることが必要です。`kubectl` を使用する標準的なデバッグ手順の実行には、そのようなアクセスは必要ではありません。
|
||||
* いくつかの高度なデバッグ手順では、Podがどのノードで動作しているかを知り、そのノードでコマンドを実行するためのシェルアクセス権を持っていることが必要です。`kubectl`を使用する標準的なデバッグ手順の実行には、そのようなアクセスは必要ではありません。
|
||||
|
||||
|
||||
## `kubectl describe pod`を使ってpodの詳細を取得
|
||||
|
|
@ -406,7 +406,7 @@ kubectl logs --previous ${POD_NAME} ${CONTAINER_NAME}
|
|||
|
||||
## container execによるデバッグ {#container-exec}
|
||||
|
||||
もし{{< glossary_tooltip text="container image" term_id="image" >}}がデバッグユーティリティを含んでいれば、LinuxやWindows OSのベースイメージからビルドしたイメージのように、`kubectl exec` で特定のコンテナ内でコマンドを実行することが可能です:
|
||||
もし{{< glossary_tooltip text="container image" term_id="image" >}}がデバッグユーティリティを含んでいれば、LinuxやWindows OSのベースイメージからビルドしたイメージのように、`kubectl exec`で特定のコンテナ内でコマンドを実行することが可能です:
|
||||
|
||||
```shell
|
||||
kubectl exec ${POD_NAME} -c ${CONTAINER_NAME} -- ${CMD} ${ARG1} ${ARG2} ... ${ARGN}
|
||||
|
|
@ -457,11 +457,11 @@ kubectl exec -it ephemeral-demo -- sh
|
|||
OCI runtime exec failed: exec failed: container_linux.go:346: starting container process caused "exec: \"sh\": executable file not found in $PATH": unknown
|
||||
```
|
||||
|
||||
代わりに、`kubectl debug` を使ってデバッグ用のコンテナを追加することができます。
|
||||
代わりに、`kubectl debug`を使ってデバッグ用のコンテナを追加することができます。
|
||||
引数に`-i`/`--interactive`を指定すると、`kubectl`は自動的にエフェメラルコンテナのコンソールにアタッチされます。
|
||||
|
||||
```shell
|
||||
kubectl debug -it ephemeral-demo --image=busybox --target=ephemeral-demo
|
||||
kubectl debug -it ephemeral-demo --image=busybox:1.28 --target=ephemeral-demo
|
||||
```
|
||||
|
||||
```
|
||||
|
|
@ -470,10 +470,10 @@ If you don't see a command prompt, try pressing enter.
|
|||
/ #
|
||||
```
|
||||
|
||||
このコマンドは新しいbusyboxコンテナを追加し、それにアタッチします。`target`パラメーターは、他のコンテナのプロセス名前空間をターゲットにします。これは`kubectl run`が作成するPodで[プロセス名前空間の共有](/ja/docs/tasks/configure-pod-container/share-process-namespace/)を有効にしないため、指定する必要があります。
|
||||
このコマンドは新しいbusyboxコンテナを追加し、それにアタッチします。`--target`パラメーターは、他のコンテナのプロセス名前空間をターゲットにします。これは`kubectl run`が作成するPodで[プロセス名前空間の共有](/ja/docs/tasks/configure-pod-container/share-process-namespace/)を有効にしないため、指定する必要があります。
|
||||
|
||||
{{< note >}}
|
||||
`target` パラメーターは{{< glossary_tooltip text="Container Runtime" term_id="container-runtime" >}}でサポートされている必要があります。サポートされていない場合、エフェメラルコンテナは起動されないか、`ps`が他のコンテナ内のプロセスを表示しないように孤立したプロセス名前空間を使用して起動されます。
|
||||
`--target`パラメーターは{{< glossary_tooltip text="Container Runtime" term_id="container-runtime" >}}でサポートされている必要があります。サポートされていない場合、エフェメラルコンテナは起動されないか、`ps`が他のコンテナ内のプロセスを表示しないように孤立したプロセス名前空間を使用して起動されます。
|
||||
{{< /note >}}
|
||||
|
||||
新しく作成されたエフェメラルコンテナの状態は`kubectl describe`を使って見ることができます:
|
||||
|
|
@ -510,15 +510,15 @@ kubectl delete pod ephemeral-demo
|
|||
|
||||
Podの設定オプションによって、特定の状況でのトラブルシューティングが困難になることがあります。
|
||||
例えば、コンテナイメージにシェルが含まれていない場合、またはアプリケーションが起動時にクラッシュした場合は、`kubectl exec`を実行してトラブルシューティングを行うことができません。
|
||||
このような状況では、`kubectl debug` を使用してデバッグを支援するために設定値を変更したPodのコピーを作ることができます。
|
||||
このような状況では、`kubectl debug`を使用してデバッグを支援するために設定値を変更したPodのコピーを作ることができます。
|
||||
|
||||
### 新しいコンテナを追加しながらPodをコピーします
|
||||
|
||||
新しいコンテナを追加することは、アプリケーションが動作しているが期待通りの動作をせず、トラブルシューティングユーティリティをPodに追加したい場合に便利な場合があります。
|
||||
例えば、アプリケーションのコンテナイメージは`busybox`上にビルドされているが、`busybox`に含まれていないデバッグユーティリティが必要な場合があります。このシナリオは `kubectl run` を使ってシミュレーションすることができます。
|
||||
新しいコンテナを追加することは、アプリケーションは動作しているが期待通りの動作をせず、トラブルシューティングユーティリティをPodに追加したい場合に便利です。
|
||||
例えば、アプリケーションのコンテナイメージは`busybox`上にビルドされているが、`busybox`に含まれていないデバッグユーティリティが必要な場合があります。このシナリオは`kubectl run`を使ってシミュレーションすることができます。
|
||||
|
||||
```shell
|
||||
kubectl run myapp --image=busybox --restart=Never -- sleep 1d
|
||||
kubectl run myapp --image=busybox:1.28 --restart=Never -- sleep 1d
|
||||
```
|
||||
|
||||
このコマンドを実行すると、`myapp`のコピーに`myapp-debug`という名前が付き、デバッグ用の新しいUbuntuコンテナが追加されます。
|
||||
|
|
@ -538,7 +538,7 @@ root@myapp-debug:/#
|
|||
|
||||
* `i`フラグを指定すると、デフォルトで`kubectl debug`が新しいコンテナにアタッチされます。これを防ぐには、`--attach=false`を指定します。セッションが切断された場合は、`kubectl attach`を使用して再接続することができます。
|
||||
|
||||
* `share-processes` を指定すると、Pod 内のコンテナからプロセスを参照することができます。この仕組みについて詳しくは、[Pod内のコンテナ間でプロセス名前空間を共有する](/ja/docs/tasks/configure-pod-container/share-process-namespace/)を参照してください。
|
||||
* `--share-processes`を指定すると、このPod内のコンテナが、Pod内の他のコンテナのプロセスを参照することができます。この仕組みについて詳しくは、[Pod内のコンテナ間でプロセス名前空間を共有する](/ja/docs/tasks/configure-pod-container/share-process-namespace/)を参照してください。
|
||||
{{< /note >}}
|
||||
|
||||
デバッグが終わったら、Podの後始末をするのを忘れないでください。
|
||||
|
|
@ -549,14 +549,14 @@ kubectl delete pod myapp myapp-debug
|
|||
|
||||
### Podのコマンドを変更しながらコピーします
|
||||
|
||||
デバッグフラグを追加するためや、アプリケーションがクラッシュするためなど、コンテナのコマンドを変更すると便利な場合があります。
|
||||
例えば、デバッグフラグを追加する場合や、アプリケーションがクラッシュしている場合などでは、コンテナのコマンドを変更すると便利なことがあります。
|
||||
アプリケーションのクラッシュをシミュレートするには、`kubectl run`を使用して、すぐに終了するコンテナを作成します:
|
||||
|
||||
```
|
||||
kubectl run --image=busybox myapp -- false
|
||||
kubectl run --image=busybox:1.28 myapp -- false
|
||||
```
|
||||
|
||||
`kubectl describe pod myapp` を使用すると、このコンテナがクラッシュしていることがわかります:
|
||||
`kubectl describe pod myapp`を使用すると、このコンテナがクラッシュしていることがわかります:
|
||||
|
||||
```
|
||||
Containers:
|
||||
|
|
@ -586,9 +586,9 @@ If you don't see a command prompt, try pressing enter.
|
|||
これで、ファイルシステムのパスのチェックやコンテナコマンドの手動実行などのタスクを実行するために使用できる対話型シェルが完成しました。
|
||||
|
||||
{{< note >}}
|
||||
* 特定のコンテナのコマンドを変更するには、そのコンテナ名を`--container`で指定する必要があり、そうしないと`kubectl debug`が代わりに指定したコマンドを実行する新しいコンテナを作成します。
|
||||
* 特定のコンテナのコマンドを変更するには、そのコンテナ名を`--container`で指定する必要があります。そうしなければ、指定したコマンドを実行するための新しいコンテナを、`kubectl debug`が代わりに作成します。
|
||||
|
||||
* ` i` フラグは、デフォルトで `kubectl debug` がコンテナにアタッチされるようにします。これを防ぐには、`--attach=false`を指定します。セッションが切断された場合は、`kubectl attach` を使用して再接続することができます。
|
||||
* `-i`フラグは、デフォルトで`kubectl debug`がコンテナにアタッチされるようにします。これを防ぐには、`--attach=false`を指定します。セッションが切断された場合は、`kubectl attach`を使用して再接続することができます。
|
||||
{{< /note >}}
|
||||
|
||||
デバッグが終わったら、Podの後始末をするのを忘れないでください:
|
||||
|
|
@ -599,12 +599,12 @@ kubectl delete pod myapp myapp-debug
|
|||
|
||||
### コンテナイメージを変更してPodをコピーします
|
||||
|
||||
状況によっては、動作不良のPodを通常のプロダクション用のイメージから、デバッグ・ビルドや追加ユーティリティを含むイメージに変更したい場合があります。
|
||||
状況によっては、動作不良のPodを通常のプロダクション用のコンテナイメージから、デバッグビルドや追加ユーティリティを含むイメージに変更したい場合があります。
|
||||
|
||||
例として、`kubectl run`を使用してPodを作成します:
|
||||
|
||||
```
|
||||
kubectl run myapp --image=busybox --restart=Never -- sleep 1d
|
||||
kubectl run myapp --image=busybox:1.28 --restart=Never -- sleep 1d
|
||||
```
|
||||
|
||||
ここで、`kubectl debug`を使用してコピーを作成し、そのコンテナイメージを`ubuntu`に変更します:
|
||||
|
|
@ -613,17 +613,18 @@ kubectl run myapp --image=busybox --restart=Never -- sleep 1d
|
|||
kubectl debug myapp --copy-to=myapp-debug --set-image=*=ubuntu
|
||||
```
|
||||
|
||||
`set-image`の構文は、`kubectl set image`と同じ`container_name=image`の構文を使用します。`*=ubuntu`は、全てのコンテナのイメージを`ubuntu`に変更することを意味します。
|
||||
`--set-image`の構文は、`kubectl set image`と同じ`container_name=image`の構文を使用します。`*=ubuntu`は、全てのコンテナのイメージを`ubuntu`に変更することを意味します。
|
||||
|
||||
デバッグが終わったら、Podの後始末をするのを忘れないでください:
|
||||
|
||||
```shell kubectl delete pod myapp myapp-debug
|
||||
```shell
|
||||
kubectl delete pod myapp myapp-debug
|
||||
```
|
||||
|
||||
## ノード上のシェルによるデバッグ {#node-shell-session}
|
||||
|
||||
いずれの方法でもうまくいかない場合は、Podが動作しているノードを探し出し、ホストの名前空間で動作する特権Podを作成します。
|
||||
ノード上で `kubectl debug` を使って対話型のシェルを作成するには、以下を実行します:
|
||||
ノード上で`kubectl debug`を使って対話型のシェルを作成するには、以下を実行します:
|
||||
|
||||
```shell
|
||||
kubectl debug node/mynode -it --image=ubuntu
|
||||
|
|
@ -637,7 +638,7 @@ root@ek8s:/#
|
|||
|
||||
ノードでデバッグセッションを作成する場合、以下の点に注意してください:
|
||||
|
||||
* `kubectl debug`はノードの名前に基づいて新しい Pod の名前を自動的に生成します。
|
||||
* `kubectl debug`はノードの名前に基づいて新しいPodの名前を自動的に生成します。
|
||||
* コンテナはホストのIPC、Network、PIDネームスペースで実行されます。
|
||||
* ノードのルートファイルシステムは`/host`にマウントされます。
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,6 @@
|
|||
---
|
||||
content_type: concept
|
||||
title: 監査
|
||||
weight: 30
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
|
|
|||
Loading…
Reference in New Issue