知らないかもしれないKubernetesのヒント13選

確立されたエコシステムを備えた Kubernetes は、コンテナ化されたアプリケーションの管理、スケーラビリティ、セキュリティを大幅に強化できる多くの機能を提供します。以下に 13 のヒントを示します。それぞれに詳細な説明、使用例、状況に応じた適用、注意すべき注意事項が記載されています。

1. PreStopフックを使用してPodを正常にシャットダウンする

PreStop フックを使用すると、Pod が終了する直前に特定のコマンドまたはスクリプトを実行できます。この機能は、アプリケーションが正常にシャットダウンし、必要に応じて状態を保存し、データの破損を回避してスムーズな再起動を確実にするためにクリーンアップ タスクを実行するために重要です。

例:

 apiVersion: v1 kind: Pod metadata: name: graceful-shutdown-example spec: containers: - name: sample-container image: nginx lifecycle: preStop: exec: command: ["/bin/sh", "-c", "sleep 30 && nginx -s quit"]

この構成により、nginx サーバーはシャットダウンする前に 30 秒以内にリクエストの処理を完了できるようになります。

いつ使うのですか?

サービスの継続性が重要な環境では、PreStop フックを実装して、デプロイメント、スケーリング、または Pod の再起動中にダウンタイムをゼロまたは最小限に抑えます。

知らせ：

Kubernetes では、Pod の終了に猶予期間が設けられています。 PreStop フック スクリプトの実行時間がこの猶予期間を超えると、Kubernetes は Pod を強制的に終了します。

2. Kubelet を使用した自動シークレットローテーション

Kubernetes は、Secret を使用する Pod を再起動せずに Secret の自動ローテーションをサポートします。この機能は、アプリケーションの可用性に影響を与えずにセキュリティ標準を維持し、機密情報を定期的に変更する場合に特に役立ちます。

例:

Kubernetes で Secret を更新したと仮定します。 Kubernetes は、介入なしに Pod にマウントされた Secret を自動的に更新し、手動で更新したり再起動したりすることなく、アプリケーションが常に最新の資格情報を持つことを保証します。

いつ使うのですか?

この機能は、高いレベルのセキュリティ コンプライアンスが要求され、データベース、API キー、TLS 証明書などのシークレットを頻繁にローテーションする必要があるアプリケーションにとって重要です。

知らせ：

アプリケーションは、更新されたシークレットを動的に読み取ることができるように設計する必要があります。一部のアプリケーションは起動時にシークレットをキャッシュするため、再起動しないと更新されたシークレットを認識しません。アプリケーションが Secret の更新を定期的にチェックし、変更に適切に反応するようにしてください。

3. 一時コンテナを使用したポッドのデバッグ

エフェメラル コンテナは、元の仕様を変更せずに、実行中の Pod にデバッグ コンテナを一時的に接続する方法を提供します。これは、サービスを中断することができないため、実稼働環境でのライブの問題をデバッグするのに非常に役立ちます。

例:

 kubectl alpha debug -it podname --image=busybox --target=containername

このコマンドは、既存の Pod に busybox コンテナを追加し、実行状態を変更せずにコマンドを実行して Pod の環境を検査できるようにします。

いつ使うのですか?

ライブ環境で問題を診断する場合、特に標準のログとメトリックでは十分な情報が得られない場合に、一時コンテナを利用できます。これは、生産上の問題をリアルタイムで詳細に分析するための強力なツールです。

知らせ：

一時コンテナは Pod のリソースや機密データにアクセスできるため、本番環境では注意して使用してください。潜在的なセキュリティ リスクを回避するために、許可された担当者のみが一時コンテナを展開できるようにします。

4. カスタムメトリックに基づく水平ポッド自動スケーリング

HPA は、標準の CPU とメモリの使用量だけでなく、カスタム メトリックに基づいて Pod レプリカを調整できます。これは、キューの長さ、リクエストのレイテンシ、カスタム アプリケーション メトリックなど、特定のビジネス メトリックまたはパフォーマンス指標に基づいて調整する必要があるアプリケーションに特に役立ちます。

例:

 apiVersion: autoscaling/v2beta2 kind: HorizontalPodAutoscaler metadata: name: custom-metric-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: your-application minReplicas: 1 maxReplicas: 10 metrics: - type: Pods pods: metric: name: your_custom_metric target: type: AverageValue averageValue: 10

この HPA 構成は、カスタム メトリック your_custom_metric の平均値に基づいてアプリケーションをスケーリングします。

いつ使うのですか?

従来のリソースベースのメトリックが負荷を正確に反映しない、またはビジネス ニーズに基づいて微調整できるアプリケーションには、カスタム メトリック スケールを使用します。

知らせ：

カスタム メトリックを設定するには、Prometheus などのカスタム メトリックをサポートするメトリック サーバーと統合する必要があります。過剰スケーリングや過小スケーリングを防ぐために、メトリックが負荷の信頼できる指標であることを確認してください。

スクリプトを実行するためにinitコンテナを使用する

Init コンテナは、Pod 内のアプリケーション コンテナの前に実行され、アプリケーションの起動前に完了する必要がある初期化構成スクリプトに最適です。これには、データベースの移行、構成ファイルの作成、外部サービスが利用可能になるまでの待機などのタスクが含まれる場合があります。 init コンテナは一連の初期化タスクを実行し、メイン アプリケーション コンテナが起動される前に各ステップが正常に完了することを保証します。

例:

 apiVersion: v1 kind: Pod metadata: name: myapp-pod spec: containers: - name: myapp-container image: myapp initContainers: - name: init-myservice image: busybox command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;']

この例では、メイン アプリケーション コンテナを起動する前に、init コンテナを使用して、「myservice」というサービスが使用可能になるまで待機します。

いつ使うのですか?

初期化コンテナーは、アプリケーション コンテナーが起動前に外部サービスまたは構成が利用可能であることを必要とする場合に重要です。環境の準備が整ったときにアプリケーションが起動することを保証します。

知らせ：

すべての init コンテナが正常に完了するまで、Pod 全体の起動はブロックされます。 init コンテナが効率的であり、障害を適切に処理して、ボトルネックになったり、Pod の起動に失敗したりしないようにします。

6. 特定のワークロードのスケジューリングのためのノードアフィニティ

ノード アフィニティを使用すると、ノードのラベルに基づいて、ポッドをスケジュールできるノードを制限するルールを指定できます。これは、特定のハードウェア (GPU など) を備えたノードにワークロードを送信したり、データの局所性を確保したり、コンプライアンスやデータ主権の要件を遵守したりするのに役立ちます。

例:

 apiVersion: v1 kind: Pod metadata: name: with-node-affinity spec: containers: - name: with-node-affinity image: nginx affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: disktype operator: In values: - ssd

このポッドはラベルの付いたポッドにのみスケジュールされます  disktype=ssd  ノード上。

いつ使うのですか?

アプリケーションで特定のノード機能が必要な場合は、ノード アフィニティを使用します。

知らせ：

ノード アフィニティを過度に使用すると、クラスターの使用率が低下し、スケジューリングの複雑さが増す可能性があります。リソースの使用効率を維持するために、クラスターにラベルとアフィニティがバランスよく分散されていることを確認してください。

7. ポッドの汚染と許容度の設定

テイントと許容範囲は連携して動作し、ポッドが不適切なノードにスケジュールされないようにします。ノード上の汚染は、汚染を許容しないポッドを撃退します。ポッドに許容範囲が適用され、汚染されたノード上でポッドをスケジュールできるようになります。このメカニズムは、ノードを特定のワークロード (GPU を集中的に使用するアプリケーションなど) 専用にしたり、機密データを含むノードで特定のポッドのみが実行されるようにしたりするために重要です。

例:

 # Applying a taint to a node kubectl taint nodes node1 key=value:NoSchedule

 # Pod specification with toleration apiVersion: v1 kind: Pod metadata: name: mypod spec: containers: - name: mypod image: nginx tolerations: - key: "key" operator: "Equal" value: "value" effect: "NoSchedule"

この構成により、他のポッドが許容できない特定のテイントを使用して、mypod を node1 にスケジュールできるようになります。

いつ使うのですか?

汚染と許容は、セキュリティやパフォーマンス上の理由からワークロードを分離することが重要なマルチテナント クラスターで特に役立ちます。また、専用のリソースを必要とする特殊なワークロードの実行にも役立ちます。

知らせ：

不適切に構成された汚染と許容は、スケジュールの問題が発生し、ポッドが期待どおりにスケジュールされなかったり、一部のノードが効率的に使用されなかったりする可能性があります。汚染と許容値の設定を定期的に確認し、スケジュール要件を満たしていることを確認します。

8. ワークロードのポッドの優先順位付けとプリエンプション

Kubernetes では、Pod に優先順位を割り当てることができます。また、必要に応じて、優先順位の高い Pod が優先順位の低い Pod をプリエンプト (排除) することができます。これにより、非常に混雑したクラスターでも重要なワークロードに必要なリソースが確保されます。

例:

 # PriorityClass definition apiVersion: scheduling.k8s.io/v1 kind: PriorityClass metadata: name: high-priority value: 1000000 globalDefault: false description: "This priority class should be used for XYZ service pods only."

 # Pod specification with priorityClassName apiVersion: v1 kind: Pod metadata: name: high-priority-pod spec: containers: - name: high-priority image: nginx priorityClassName: high-priority

この構成では、優先度の高いクラスを定義してポッドに割り当て、優先度の低い他のポッドを優先できるようにします。

いつ使うのですか?

特にリソース競合の多いクラスター環境で実行している場合は、ポッドの優先順位付けとプリエンプションを使用して、ビジネス運用に重要なアプリケーションを管理します。

知らせ：

不適切に使用すると、二次アプリケーションのリソース不足が発生する可能性があります。さまざまなワークロードのニーズのバランスを取り、クラスターの健全性とアプリケーションのパフォーマンスへの全体的な影響を考慮することが重要です。

9. 動的構成の ConfigMap と Secrets

ConfigMap と Secrets は、構成データを Pod に挿入するためのメカニズムを提供します。これにより構成が外部化され、構成データをハードコーディングしなくてもアプリケーションの構成が容易になります。 ConfigMap は非機密データ用であり、Secret は機密データ用です。

例:

 # ConfigMap Example apiVersion: v1 kind: ConfigMap metadata: name: app-config data: config.json: | { "key": "value", "databaseURL": "http://mydatabase.example.com" }

 # Pod Spec using ConfigMap apiVersion: v1 kind: Pod metadata: name: myapp-pod spec: containers: - name: myapp-container image: myapp volumeMounts: - name: config-volume mountPath: /etc/config volumes: - name: config-volume configMap: name: app-config

この構成により、app-config の内容がポッドに挿入され、アプリケーションが /etc/config/config.json から構成を読み取ることができるようになります。

いつ使うのですか?コンテナ イメージを再構築せずに、アプリケーションの構成または機密データを外部化して、管理、更新、保守を容易にする必要がある場合。

注意: ConfigMap は機密性のないデータを保存するのに最適ですが、秘密にしておく必要のあるデータを ConfigMap に保存することは避けてください。トークン、キー、その他の機密データを保存するときは常に Secrets を使用し、保存時に暗号化するなど、Secrets を保護するためのベスト プラクティスに注意してください。

10. コンテナを直接デバッグするための Kubectl Debug

kubectl debug は、ポッドの一時コピーを作成し、元のコンテナをデバッグ バージョンに置き換えたり、元のポッドに影響を与えずに新しいトラブルシューティング ツールを追加したりする方法を提供します。これは、アプリケーションの実行状態に影響を与えずに、ライブ環境で問題をデバッグするのに非常に役立ちます。

例:

 kubectl debug pod/myapp-pod -it --copy-to=myapp-debug --container=myapp-container --image=busybox

このコマンドは、デバッグの目的で、myapp-pod のコピーを作成し、myapp-container を busybox イメージに置き換えます。

いつ使うのですか?

クラッシュしたポッドや本番環境で期待どおりに動作しないポッドのトラブルシューティングが必要な場合、サービスへの影響を最小限に抑えながらライブ デバッグを実行します。

知らせ：

ポッドをデバッグすると、クラスター全体のリソース割り当てに影響が及ぶ可能性があり、機密データにアクセスする可能性があります。デバッグ コマンドへのアクセスを厳密に制御し、使用後はデバッグ ポッドをクリーンアップするようにしてください。

11. リクエストと制限による効率的なリソース管理

Kubernetes を使用すると、ポッド内の各コンテナの CPU とメモリ (RAM) の要求と制限を指定できます。リクエストは、コンテナーが指定された量のリソースを取得することを保証し、制限はコンテナーが割り当てられた量を超えて使用しないことを保証します。これにより、リソース割り当てを効率的に管理し、単一のアプリケーションがクラスター リソースを独占することを防ぐことができます。

例:

 apiVersion: v1 kind: Pod metadata: name: resource-demo spec: containers: - name: demo-container image: nginx resources: requests: memory: "64Mi" cpu: "250m" limits: memory: "128Mi" cpu: "500m"

このポッド仕様では、指定された制限を超えないようにしながら、最適なパフォーマンスを実現するために必要なリソースを確保するために、特定の量の CPU とメモリをデモ コンテナーに割り当てることを要求します。

いつ使うのですか?

すべてのコンテナにリクエストと制限を適用して、アプリケーションの予測可能なパフォーマンスを確保し、クラスターで実行されているアプリケーション間のリソース競合を回避します。

注意:制限を低く設定しすぎると、クラスターが要求されたリソースを提供できない場合に、ポッドが終了したり、スケジュールできなくなったりする可能性があります。逆に、設定値が高すぎると、クラスター リソースの使用効率が低下する可能性があります。アプリケーションのパフォーマンスを監視し、必要に応じてリクエストと制限を調整します。

12. Kubernetesを拡張するためのカスタムリソース定義（CRD）

CRD を使用すると、独自の API オブジェクトを使用して Kubernetes を拡張し、ネイティブ Kubernetes オブジェクトのように動作するカスタム リソースを作成できます。これは、クラスターにドメイン固有の機能を追加し、カスタム操作を容易にし、外部システムと統合するのに強力です。

例:

 apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: name: crontabs.stable.example.com spec: group: stable.example.com versions: - name: v1 served: true storage: true scope: Namespaced names: plural: crontabs singular: crontab kind: CronTab shortNames: - ct

この CRD は、クラスター内に新しいリソース タイプ CronTab を定義します。これを使用して、従来の cron ジョブのようにタスクをスケジュールできますが、Kubernetes のネイティブ管理方法が使用されます。

いつ使うのですか? CRD は、ドメイン固有のリソース タイプの導入や外部サービスおよび API との統合など、アプリケーションまたはサービスの特定のニーズを満たすために Kubernetes 機能を拡張するのに最適です。

知らせ：

CRD を設計および管理するには、Kubernetes の内部構造と API メカニズムを深く理解する必要があります。適切に設計されていない CRD はパフォーマンスの問題が発生し、クラスターの管理が複雑になる可能性があります。必ず CRD を徹底的にテストし、クラスターの安定性とパフォーマンスへの影響を考慮してください。

13. 動的なインタラクションと自動化のためのKubernetes API

Kubernetes API を使用すると、クラスターと動的に対話できるため、スケーリング、展開、管理タスクをプログラムで自動化できます。 API を活用することで、クラスターとリアルタイムで対話するスクリプトやアプリケーションを作成でき、静的な構成ファイルや手動コマンドでは実現できない複雑な自動化および統合シナリオが可能になります。

例:

以下は、curl を使用して Kubernetes API と対話し、デフォルトの名前空間内のポッドのリストを取得する基本的な例です。これは、アクセス トークンがあり、https:// で Kubernetes API にアクセスできることを前提としています。

 curl -X GET https://<kubernetes-api-server>/api/v1/namespaces/default/pods \ -H "Authorization: Bearer <your-access-token>" \ -H 'Accept: application/json'

より複雑なやり取りを行うには、HTTP リクエストを抽象化し、Kubernetes API を操作するためのより便利なインターフェースを提供する、さまざまなプログラミング言語 (Go、Python、Java など) で利用可能なクライアント ライブラリの使用を検討してください。

いつ使うのですか?

Kubernetes API は、カスタム自動化、動的スケーリング ポリシー、CI/CD 統合、さらには Kubernetes 機能を拡張するカスタム コントローラーの開発に非常に強力です。これは、Kubernetes 操作を外部システムと統合したり、カスタム デプロイメント ワークフローを作成したりする必要がある場合に特に便利です。

知らせ：

Kubernetes API と対話する場合、認証と承認を慎重に処理する必要があります。スクリプトとアプリケーションが最小権限の原則に準拠し、実行に必要な権限のみを要求するようにしてください。さらに、頻繁なクエリや複雑なクエリを実行する場合は、クラスターのパフォーマンスに影響する可能性があるため、API サーバーの負荷に影響を及ぼす可能性があることに注意してください。セキュリティの脆弱性を回避するために、API クライアントからの入力を常に検証してサニタイズしてください。特に、外部システムやユーザー生成コンテンツとやり取りする場合はそうです。