[ja] Translate content/en/blog/_posts/2025-10-20-seven-kubernetes-pitfalls-and-how-to-avoid.md into Japanese #53462
Conversation
k8s-ci-robot
added
area/localization
k8s-ci-robot
added
the
sig/docs
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
size/L
✅ Pull request preview available for checkingBuilt without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
※日本語の表現に関わる内容のため日本語でコメントします。 対象記事は全編通して口語的・カジュアルなトーンが多く、そのような表現を使っている箇所では意訳寄りの表現を使っています。 前提としてここの翻訳ポリシーが「原文に忠実に」であることは認識していますが、そのまま直訳すると不自然になると思われる箇所がありました。私の視点で気になっている箇所を示しますので、レビューいただく際にこちらについてご意見をいただけると幸いです（問題なければそのままスルーしていただいて結構です）。 (1) "oops", "facepalm" の訳 それぞれ「しまった」「やってしまった」としています。 (2) セクション3のタイトル
"famous last words" を「これが悲劇の始まり」としています。いわゆる「フラグ」的な自虐ニュアンスの表現と解釈しましたが、直訳で「有名な最後の言葉」とすると日本人には意味がわからないので意訳を加えました。 (3) 最終段落
以下のように訳しています。
「歩んでいる」が原文にない表現です。こちらもニュアンスを解釈した結果このように表現しました。 |
| - `kubectl top pods`やログ/監視ツールを注視して、過剰または過小なプロビジョニングになっていないことを確認します。 | ||
|
|
||
| **私の実体験**: 初期の頃、私はメモリ制限について考えたことがありませんでした。ローカルクラスターでは問題なく見えました。しかし、より大規模な環境では、Podが次々と*OOMKilled*されました。教訓を得ました。 | ||
| コンテナのリソースリクエストとリミットを設定する詳細な手順については、[コンテナおよびPodへのメモリーリソースの割り当て](/ja/docs/tasks/configure-pod-container/assign-memory-resource/)(公式Kubernetesドキュメントの一部)を参照してください。 |
There was a problem hiding this comment.
| コンテナのリソースリクエストとリミットを設定する詳細な手順については、[コンテナおよびPodへのメモリーリソースの割り当て](/ja/docs/tasks/configure-pod-container/assign-memory-resource/)(公式Kubernetesドキュメントの一部)を参照してください。 | |
| コンテナのリソースリクエストとリミットを設定する詳細な手順については、[コンテナおよびPodへのメモリリソースの割り当て](/docs/tasks/configure-pod-container/assign-memory-resource/)(公式Kubernetesドキュメントの一部)を参照してください。 |
|
|
||
| ## 1. リソースrequestsとlimitsの設定を怠る |
There was a problem hiding this comment.
見出し ID があると良いかと思いました。
| ## 1. リソースrequestsとlimitsの設定を怠る | |
| ## 1. リソースrequestsとlimitsの設定を怠る {#1-skipping-resource-requests-and-limits} |
| 1. リソース不足: Podが不十分なリソースしか得られず、パフォーマンスの低下や障害につながる可能性があります。これは、Kubernetesがrequestsの値に基づきPodをスケジュールするためです。requestsがないと、スケジューラーは単一のノードに過剰数のPodを配置する可能性があり、リソースの競合やパフォーマンスのボトルネックにつながります。 | ||
| 2. リソースの占有: 逆に、limitsがないと、あるPodが公平な配分以上のリソースを消費し、同じノード上の他のPodのパフォーマンスと安定性に影響を与える可能性があります。これにより、利用可能なメモリ不足のために他のPodが退避されたり、Out-Of-Memory(OOM)キラーによって強制終了されたりする問題が発生する可能性があります。 | ||
|
|
||
| ### 回避方法: |
There was a problem hiding this comment.
| ### 回避方法: | |
| ### 回避方法: {#how-to-avoid-it} |
| **私の実体験**: 初期の頃、私はメモリ制限について考えたことがありませんでした。ローカルクラスターでは問題なく見えました。しかし、より大規模な環境では、Podが次々と*OOMKilled*されました。教訓を得ました。 | ||
| コンテナのリソースリクエストとリミットを設定する詳細な手順については、[コンテナおよびPodへのメモリーリソースの割り当て](/ja/docs/tasks/configure-pod-container/assign-memory-resource/)(公式Kubernetesドキュメントの一部)を参照してください。 | ||
|
|
||
| ## 2. livenessプローブとreadinessプローブを軽視する |
There was a problem hiding this comment.
| ## 2. livenessプローブとreadinessプローブを軽視する | |
| ## 2. livenessプローブとreadinessプローブを軽視する {#2-underestimating-liveness-and-readiness-probes} |
There was a problem hiding this comment.
過去の翻訳では、Liveness Probe, Readiness Probe, Startup Probe とそのままの表記のようです。
https://kubernetes.io/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
https://kubernetes.io/ja/docs/concepts/configuration/liveness-readiness-startup-probes/
@t-inu
修正すべきか、意見をいただけないでしょうか。
There was a problem hiding this comment.
今のところは既存の日本語ページに合わせて、Liveness Probe、Readiness Probe、Startup Probeの表記にしておくのがよいかなと。
単独でのProbeの場合についても、#21370 (comment) で、そのままにすることになっていました。
とはいえ5年前の話ですが…。
プローブというカタカナ表記は、IT分野でもよく見かけるようになってきているので、このドキュメントもそうしようという意見が多ければ、変えていくのもありだと思います。
cc @kubernetes/sig-docs-ja-reviews
| - **readinessプローブ**は、コンテナがトラフィックを処理する準備ができているかどうかを制御します。readinessプローブが合格するまで、コンテナはServiceエンドポイントから除外されます。 | ||
| - **startupプローブ**は、長い起動時間と実際の障害を区別するのに役立ちます。 | ||
|
|
||
| ### 回避方法: |
There was a problem hiding this comment.
| ### 回避方法: | |
| ### 回避方法: {#how-to-avoid-it-1} |
There was a problem hiding this comment.
https://kubernetes.io/ja/docs/contribute/localization/#basic-policy
日本語文では、文章の途中で改行を行わない。句点「。」もしくは行末のコロン:で改行する
とあり、「。」の後に改行を挟むようにするとベターかと思いました。
|
|
||
| ## 5. 古いリソースを放置する | ||
|
|
||
| **落とし穴**: 未使用または古いリソース—Deployment、Service、ConfigMap、PersistentVolumeClaimなど—をクラスター内で実行したままにする。これは、Kubernetesが明示的に指示されない限りリソースを自動的に削除せず、所有権や有効期限を追跡する組み込みメカニズムがないためによく起こります。時間の経過とともに、これらの忘れられたオブジェクトが蓄積し、クラスターリソースを消費し、クラウドコストを増加させます。特に、古いServiceやLoadBalancerがトラフィックをルーティングし続けていると、運用上の混乱を引き起こす可能性があります。 |
There was a problem hiding this comment.
他の文章と合わせるため、「〜こと」にしました。
| **落とし穴**: 未使用または古いリソース—Deployment、Service、ConfigMap、PersistentVolumeClaimなど—をクラスター内で実行したままにする。これは、Kubernetesが明示的に指示されない限りリソースを自動的に削除せず、所有権や有効期限を追跡する組み込みメカニズムがないためによく起こります。時間の経過とともに、これらの忘れられたオブジェクトが蓄積し、クラスターリソースを消費し、クラウドコストを増加させます。特に、古いServiceやLoadBalancerがトラフィックをルーティングし続けていると、運用上の混乱を引き起こす可能性があります。 | |
| **落とし穴**: 未使用または古いリソース—Deployment、Service、ConfigMap、PersistentVolumeClaimなど—をクラスター内で実行したままにすること。これは、Kubernetesが明示的に指示されない限りリソースを自動的に削除せず、所有権や有効期限を追跡する組み込みメカニズムがないためによく起こります。時間の経過とともに、これらの忘れられたオブジェクトが蓄積し、クラスターリソースを消費し、クラウドコストを増加させます。特に、古いServiceやLoadBalancerがトラフィックをルーティングし続けていると、運用上の混乱を引き起こす可能性があります。 |
|
|
||
| ## 4. 開発環境と本番環境を完全に同じに扱う | ||
|
|
||
| **落とし穴**: 開発、ステージング、本番環境全体で同一の設定を持つ同じKubernetesマニフェストをデプロイする。これは、チームが一貫性と再利用性を目指すものの、環境固有の要因—トラフィックパターン、リソースの可用性、スケーリングのニーズ、またはアクセス制御など—が大きく異なりうることを見落としている場合によく起こります。カスタマイズなしでは、単一の環境向けに最適化された設定が別の環境では不安定性、パフォーマンス低下、またはセキュリティ欠陥を引き起こす可能性があります。 |
There was a problem hiding this comment.
「〜こと」で統一すると、何が「落とし穴」か分かりやすくなる気がしました。
| **落とし穴**: 開発、ステージング、本番環境全体で同一の設定を持つ同じKubernetesマニフェストをデプロイする。これは、チームが一貫性と再利用性を目指すものの、環境固有の要因—トラフィックパターン、リソースの可用性、スケーリングのニーズ、またはアクセス制御など—が大きく異なりうることを見落としている場合によく起こります。カスタマイズなしでは、単一の環境向けに最適化された設定が別の環境では不安定性、パフォーマンス低下、またはセキュリティ欠陥を引き起こす可能性があります。 | |
| **落とし穴**: 開発、ステージング、本番環境全体で同一の設定を持つ同じKubernetesマニフェストをデプロイすること。これは、チームが一貫性と再利用性を目指すものの、環境固有の要因—トラフィックパターン、リソースの可用性、スケーリングのニーズ、またはアクセス制御など—が大きく異なりうることを見落としている場合によく起こります。カスタマイズなしでは、単一の環境向けに最適化された設定が別の環境では不安定性、パフォーマンス低下、またはセキュリティ欠陥を引き起こす可能性があります。 |
|
|
||
| ## 6. ネットワークを早々に深掘りしすぎる | ||
|
|
||
| **落とし穴**: Kubernetesのネイティブなネットワークプリミティブを完全に理解する前に、高度なネットワークソリューション—サービスメッシュ、カスタムCNIプラグインやマルチクラスター通信—を導入する。これは、チームがコアのKubernetesネットワークの仕組み(Pod間通信、ClusterIP Service、DNS解決、基本的なIngressトラフィック処理を含む)を最初に習得せずに、外部ツールを使用してトラフィックルーティング、可観測性、mTLSなどの機能を実装する際によく発生します。結果として、ネットワーク関連の問題のトラブルシューティングが難しくなります(特に、オーバーレイが追加の抽象化や障害点をもたらす場合)。 |
There was a problem hiding this comment.
| **落とし穴**: Kubernetesのネイティブなネットワークプリミティブを完全に理解する前に、高度なネットワークソリューション—サービスメッシュ、カスタムCNIプラグインやマルチクラスター通信—を導入する。これは、チームがコアのKubernetesネットワークの仕組み(Pod間通信、ClusterIP Service、DNS解決、基本的なIngressトラフィック処理を含む)を最初に習得せずに、外部ツールを使用してトラフィックルーティング、可観測性、mTLSなどの機能を実装する際によく発生します。結果として、ネットワーク関連の問題のトラブルシューティングが難しくなります(特に、オーバーレイが追加の抽象化や障害点をもたらす場合)。 | |
| **落とし穴**: Kubernetesのネイティブなネットワークプリミティブを完全に理解する前に、高度なネットワークソリューション—サービスメッシュ、カスタムCNIプラグインやマルチクラスター通信—を導入すること。これは、チームがコアのKubernetesネットワークの仕組み(Pod間通信、ClusterIP Service、DNS解決、基本的なIngressトラフィック処理を含む)を最初に習得せずに、外部ツールを使用してトラフィックルーティング、可観測性、mTLSなどの機能を実装する際によく発生します。結果として、ネットワーク関連の問題のトラブルシューティングが難しくなります(特に、オーバーレイが追加の抽象化や障害点をもたらす場合)。 |
|
|
||
| ## 7. セキュリティとRBACを軽視する | ||
|
|
||
| **落とし穴**: 安全でない設定でワークロードをデプロイする。例えば、rootユーザーとしてコンテナを実行する、`latest`イメージタグを使用する、セキュリティコンテキストを無効にする、`cluster-admin`のような過度に広範なRBACロールを割り当てるなど。これらの慣習が根強く残っているのは、Kubernetesが初期状態では厳格なセキュリティデフォルトを強制せず、プラットフォームが意見を押し付けるのではなく柔軟に設計されているためです。明示的なセキュリティポリシーが設定されていない場合、クラスターはコンテナエスケープ、不正な権限昇格、あるいはバージョン固定されていないイメージによる意図しない本番環境の変更といったリスクにさらされ続ける可能性があります。 |
There was a problem hiding this comment.
| **落とし穴**: 安全でない設定でワークロードをデプロイする。例えば、rootユーザーとしてコンテナを実行する、`latest`イメージタグを使用する、セキュリティコンテキストを無効にする、`cluster-admin`のような過度に広範なRBACロールを割り当てるなど。これらの慣習が根強く残っているのは、Kubernetesが初期状態では厳格なセキュリティデフォルトを強制せず、プラットフォームが意見を押し付けるのではなく柔軟に設計されているためです。明示的なセキュリティポリシーが設定されていない場合、クラスターはコンテナエスケープ、不正な権限昇格、あるいはバージョン固定されていないイメージによる意図しない本番環境の変更といったリスクにさらされ続ける可能性があります。 | |
| **落とし穴**: 安全でない設定でワークロードをデプロイすること。例えば、rootユーザーとしてコンテナを実行する、`latest`イメージタグを使用する、セキュリティコンテキストを無効にする、`cluster-admin`のような過度に広範なRBACロールを割り当てるなど。これらの慣習が根強く残っているのは、Kubernetesが初期状態では厳格なセキュリティデフォルトを強制せず、プラットフォームが意見を押し付けるのではなく柔軟に設計されているためです。明示的なセキュリティポリシーが設定されていない場合、クラスターはコンテナエスケープ、不正な権限昇格、あるいはバージョン固定されていないイメージによる意図しない本番環境の変更といったリスクにさらされ続ける可能性があります。 |
4 participants
Description
Translate content/en/blog/_posts/2025-10-20-seven-kubernetes-pitfalls-and-how-to-avoid.md into Japanese.
original page: https://kubernetes.io/blog/2025/10/20/seven-kubernetes-pitfalls-and-how-to-avoid/
Issue
Closes: #53444
/area localization
/language ja