記事ディレクトリ
I.はじめに
1. Kubernetes の概要
ubernetes は、コンテナーのデプロイ、スケーリング、およびアップグレードを自動的に管理できるオープンソースのコンテナー オーケストレーション プラットフォームです。開発者の負担を軽減し、アプリケーションの信頼性とスケーラビリティを向上させます。Kubernetes が成功した理由の 1 つは、その自動化されたフェイルオーバーと自己修復機能であり、クラウドネイティブ アプリケーション開発の頼りになるプラットフォームの 1 つとなっています。
2. フェイルオーバーと自己修復機能の重要性
故障转移功能Kubernetes がコンテナー、ノード、ポッド、およびクラスター環境全体の障害を検出できるようにします。障害が検出されると、コンテナーを自動的に再起動するか、ポッドを再スケジュールして、アプリケーションの可用性を確保します。この自動化されたフェイルオーバー メカニズムにより、システムの信頼性が大幅に向上し、アプリケーションのダウンタイムが短縮されます。
自愈能力これは、Kubernetes が問題のあるノード、コンテナー、およびポッドを自動的に修復できるようにする、Kubernetes のもう 1 つの重要な機能です。ノードまたはポッドに障害が発生すると、Kubernetes はそれらをクラスターから自動的に一時的に削除し、再作成してアプリケーションの可用性を確保します。同様に、ノードまたはコンテナに障害が発生した場合、Kubernetes はそれらを自動的に別のノードに移動したり、再起動したりできます。
これらの機能により、手動介入の必要性が大幅に減少し、アプリケーションの信頼性と可用性が大幅に向上します。また、企業により優れた運用および保守サポートを提供し、管理コストを削減することもできます。さらに、自動化された障害検出と転送により、他のサービスとの統合およびコラボレーション機能も強化され、システムの全体的なパフォーマンスと信頼性がさらに向上します。
クラウド コンピューティングの時代では、アプリケーションの信頼性とスケーラビリティが技術アーキテクチャにおいて不可欠になります。Kubernetes を使用すると、開発者の効率とシステムの信頼性が大幅に向上し、障害の問題やサービスの中断の可能性が減少します。したがって、Kubernetes は、新世代のコンテナ オーケストレーション システムとして、現代の企業にとって不可欠な要素となっています。
2. Kubernetes の概要
1. Kubernetes アーキテクチャ
Kubernetes アーキテクチャには、次のコンポーネントが含まれています。
- マスター ノード:
クラスター全体のステータスとプロセスを制御し、アプリケーションをスケジュールします。 - ワーカー ノード:
コンテナー インスタンスを実行します。 - etcd:
クラスター全体の状態情報を保存します。
Kubernetes アーキテクチャでは、マスター ノードはクラスター全体の管理と監視を担当するコンポーネントです。これには、次のコア コンポーネントが含まれます。
- API サーバー:
クラスターのステータス情報と、REST API インターフェースを介して操作できるインターフェースを公開します。すべての Kubernetes 制御コマンドは、API サーバーによって対応するコンポーネントに転送されます。 - etcd:
クラスターの状態情報を格納します。これは、クラスター全体の構成、状態、およびメタデータを格納するために Kubernetes によって使用される、信頼性が高くスケーラブルなキー値ストア システムです。 - コントローラー マネージャー:
クラスターの状態を監視し、システムの予想される状態が実際の状態と一致していることを確認します。この目標は、レプリケーション コントローラーやエンドポイント コントローラーなどの複数のコントローラーによって達成されます。 - スケジューラー:
アプリケーションをワーカー ノードに割り当て、スケジューリング ポリシーに従ってコンテナー インスタンスの場所を調整します。
ワーカー ノードは、コンテナー インスタンスを実行し、これらのコンテナー インスタンスの監視を担当する Kubernetes クラスター内のコンピューティング ノードです。次のコンポーネントが含まれています。
- kubelet:
コンテナ インスタンスの実行ステータスを監視し、ステータス情報をマスター ノードに報告します。また、コンテナーの仕様情報を解析して、コンテナーが正しく構成されていることを確認し、コンテナー内でアプリケーションを実行します。 - kube-proxy:
ネットワーク プロキシ。クラスター ネットワーク ルールを維持し、ネットワーク リクエストを送信先にルーティングします。iptables を介して内部負荷分散を実装し、ICMP プロトコルを使用して外部負荷分散装置からの「ヘルス」チェック要求に応答します。
2. Kubernetes のコンポーネントと機能
Kubernetes は、コンテナー化されたアプリケーションの管理と操作を改善するために、次のコンポーネントと機能を提供します。
- Pod:
Pod は Kubernetes の最も基本的な単位であり、1 つ以上のコンテナーのコレクションです。Pod は個別の IP アドレスと独立した環境を持ち、ネットワーク空間はコンテナー間で共有され、IPC や Volum などのリソースを介して共有できます。 - サービス:
サービスは、コンテナ間のネットワーク通信メカニズムであり、同じタイプのコンテナのグループをマッピングし、負荷分散やサービス検出などの機能を提供する場合があります。サービスは、ClusterIP、NodePort、および LoadBalancer を通じてさまざまなサービス タイプを提供します。 - ボリューム:
ボリュームはコンテナーのストレージ抽象化であり、永続データまたは共有ストレージに使用できます。 - ReplicaSet:
ReplicaSet は、グループ内の Pod の数が指定された数のレプリカを常に満たしていることを保証します。これは、障害が発生した場合のアプリケーションの自己修復と可用性を確保するために使用できます。 - 展開:
展開は、ローリング アップグレードやロールバックなどの機能を提供する ReplicaSet の拡張機能です。 - StatefulSet:
StatefulSet は Pod のシーケンスです. 各 Pod には独立したネットワーク識別子があり、識別可能です. 永続的なストレージ、秩序ある展開、または統合ストレージ システムを必要とするアプリケーションに使用できます. - ConfigMap と Secret:
ConfigMap と Secret は、構成とパスワードの情報をアプリケーションのソース コードから分離するオブジェクトであり、環境変数やコードにさらされることなくコンテナー インスタンスにマウントできます。
一般に、Kubernetes は、コンテナー化されたアプリケーションのデプロイおよび運用と保守をより便利にする多くの機能を提供します。Kubernetes を使用すると、アプリケーションのスケーリング、負荷分散の実現、高可用性の確保、ローリング アップデートやロールバックなどの操作の実行を簡単に行うことができます。さらに、コンテナー化されたアプリケーションの機能と効率は、ISTIO や Operator Framework などの他のクラウドネイティブ ツールやプラットフォームとの高度な統合によってさらに強化できます。
3.フェイルオーバー
1. フェイルオーバーの定義方法
フェイルオーバーとは、システムまたはアプリケーションに障害が発生した場合に、ワークロードを他の使用可能なノードまたはインスタンスに自動的に転送または再分散して、サービスの可用性と継続性を維持することを意味します。フェールオーバーは、クラウド コンピューティングと分散システムの重要な機能であり、アプリケーションが機能を維持し、スムーズな運用を確保するのに役立ちます。
フェールオーバー メカニズムには、アプリケーション ノードのステータスの調整と監視、およびサービスの信頼性の維持に失敗した場合の通常の動作への自動復元が含まれます。フェイルオーバーを実現するために、システムとアプリケーションは、バックアップ ストレージやフォールト トレラント システムなどのバックアップおよび冗長性戦略を採用できます。
2. Kubernetes のフェイルオーバー メカニズム
Kubernetes は、コンテナー化されたアプリケーションの展開、スケーリング、および管理を自動化するために使用できるオープン ソースのコンテナー オーケストレーション システムです。さまざまなフェールオーバー メカニズムを提供して、障害が発生した場合でもアプリケーションを引き続き使用して実行できるようにします。
以下は、Kubernetes のフェイルオーバー メカニズムです。
2.1 ヘルスチェック
ヘルス チェックは、Kubernetes フェイルオーバー メカニズムの中核部分です。コンテナ内のアプリケーションまたは Pod のステータスを定期的にチェックして、時間内に障害またはクラッシュを検出し、障害が発生した Pod を自動的に再起動または再構築します。
ヘルスチェックには次の 3 種類があります。
- livenessProbe: コンテナー内のアプリケーションが生きていて、要求に応答するかどうかを確認します。
- readinessProbe: コンテナー内のアプリケーションがネットワーク トラフィックを受け入れる準備ができているかどうかを確認します。
- startupProbe: コンテナ内のアプリケーションが起動しているかどうかを確認し、起動が完了するまでしばらく待ちます。
2.2 Pod と ReplicaSet
ポッドは、Kubernetes の最小のデプロイ ユニットです。1 つ以上のコンテナーを保持でき、ストレージとネットワーク リソースを共有するための環境を提供します。
ReplicaSet は、Kubernetes のもう 1 つの重要な概念です。Pod のレプリカを管理し、必要な数の Pod が常に実行されていることを確認するために使用されます。
Pod が失敗または終了した場合、ReplicaSet は新しい Pod を自動的に開始して、Pod を置き換えます。これにより、コンテナー アプリケーションが実行時に常に利用できるようになります。
2.3 コントローラーとフェイルオーバー
Kubernetes では、コントローラーは Pod と ReplicaSet を管理し、アプリケーションが期待どおりに動作するようにするために使用される高レベルの抽象化です。Kubernetes は、Deployment、StatefulSet、DaemonSet など、さまざまな種類のコントローラーを提供します。
コントローラーは、Pod と ReplicaSet のステータスを監視し、必要に応じてそれらをフェイルオーバーまたは再作成できます。たとえば、Deployment コントローラーは、Pod の数を自動的にスケールアップまたはスケールダウンして、アプリケーションに十分なリソースがあることを確認できます。
3. Pod と ReplicaSet の関係
Pod は Kubernetes の最小のデプロイ ユニットであり、1 つ以上のコンテナーを保持し、ストレージとネットワーク リソースを共有するための環境を提供できます。ReplicaSet は、Pod レプリカを管理し、必要な数の Pod が実行されていることを確認するための抽象化です。
Pod と ReplicaSet の関係は次のとおりです。
- 各 Pod は ReplicaSet によって管理され、作成時に ReplicaSet を割り当てる必要があります。
- ReplicaSet は必要な Pod の数を決定し、必要に応じて Pod を自動的に作成、削除、および再構築します。
- ReplicaSet は、失敗した Pod を即座に見つけて、新しい Pod に置き換えることができます。
4. コントローラーとフェイルオーバー
Kubernetes では、コントローラーは Pod と ReplicaSet を管理し、アプリケーションが期待どおりに動作するようにするために使用される高レベルの抽象化です。Kubernetes は、Deployment、StatefulSet、DaemonSet など、さまざまな種類のコントローラーを提供します。
コントローラーは、Pod と ReplicaSet のステータスを監視し、必要に応じてフェイルオーバーまたは再作成を実行できます。たとえば、Pod に障害が発生したり削除されたりした場合、Deployment コントローラーは自動的に新しい Pod を作成し、実行中のアプリケーションが引き続き使用できるようにします。
さらに、コントローラーはローリング展開機能を使用して、サービスを中断することなくアプリケーションを更新できます。可用性と負荷分散ポリシーに基づいてポッドの新しいバージョンを切り替えて、アプリケーションのアップグレード中に障害が発生しないようにします。
4. 自己治癒力
1. 自己治癒能力の定義方法
自己修復機能とは、システムまたはアプリケーションがそれ自体を監視および修復して、システムの可用性と信頼性を向上させる機能を指します。障害または異常な状況が発生した場合、自己修復機能が問題を自動的に検出して対処できるため、手動介入の必要性が減り、通常の動作状態を迅速に復元できます。これにより、システムの可用性が向上し、システムの継続的かつ安定した運用が保証されます。
自己修復機能は、最新の分散アプリケーションの基盤です。クラウド コンピューティング、コンテナー テクノロジ、マイクロサービス アーキテクチャなどの分野では、大規模で複雑なアプリケーションが標準になっています。これらのアプリケーションには、複雑な依存関係を持つ多くのコンポーネントとサービスが含まれています。コンポーネントまたはサービスの 1 つに障害が発生すると、アプリケーション全体の通常の動作に影響を与える可能性があります。
したがって、自己修復機能は、最新のアプリケーションに不可欠な機能になっています。この機能により、人間の介入の必要性が減り、アプリケーションの可用性と安定性が向上します。
2. Kubernetes の自己修復メカニズム
Kubernetes は、コンテナー アプリケーションの可用性と信頼性を確保するための一連の自己修復メカニズムを提供する、人気のあるコンテナー オーケストレーション システムです。以下は、いくつかの一般的な Kubernetes 自己修復メカニズムです。
2.1 自動ローリング アップグレード
ローリング更新は、Kubernetes でアプリケーションを更新する方法です。2 つのバージョンのアプリケーションを使用してすべてのコンテナーを段階的に更新し、サービスの一時的な中断や障害を回避します。ローリング更新では、アプリケーション コンテナーの新しいバージョンが開始され、すべてのコンテナーが更新されるまで古いバージョンが徐々に停止されます。
2.2 自動伸縮
Kubernetes は、アプリケーションの負荷に応じてレプリカの数を自動的に調整して、システムの可用性を確保できます。負荷が高くなると、レプリカの数が自動的に増加し、負荷が非常に低くなると、レプリカの数が自動的に減少します。この適応拡張および収縮メカニズムにより、システムの安定性と可用性が保証されます。
2.3 自動耐障害性
Kubernetes には、Pod の再起動、コンテナの再起動、ノードの再起動など、一連のフォールト トレランス メカニズムがあります。これらのメカニズムにより、障害が発生した場合にアプリケーションが迅速に通常の状態に回復できるようになります。
2.4 自動更新の設定
Kubernetes は、アプリケーションの構成を自動的に更新して、アプリケーションが実行時に最新の構成を持つようにすることができます。この更新プロセスは非常に安全です。これにより、すべての Pod が正常に開始され、プロセス中にリクエストが中断されたり失われたりすることがないことが保証されます。
2.5 自動修復
Kubernetes には、ポッドの障害や異常な状態を自動的に検出して修復できる自己修復メカニズムがいくつかあります。これらのメカニズムには、Liveness および Readiness プローブ、Pod ヘルス チェックなどが含まれます。
3.ポッドのヘルスモニタリング
Kubernetes でのPodヘルス Pod 内の各コンテナのヘルスをモニタリングすることを指します。コンテナーが異常な場合、Kubernetes は構成に従ってコンテナーまたは Pod 全体を自動的に再起動します。このヘルス モニタリング メカニズムにより、障害が発生した場合に、アプリケーションが迅速に通常の状態に回復できるようになります。
Pod 内のコンテナに障害があると Kubernetes が判断すると、自己修復メカニズムを介してコンテナを自動的に再起動し、できるだけ多くのコンテナを通常の操作に復元します。リカバリが不可能な場合、Pod インスタンス全体が強制終了されます。このメカニズムにより、操作および保守担当者による手動介入の必要性が回避され、自動化がより完全になります。
4. liveness プローブと readiness プローブとは
Livenessプローブはコンテナーがまだ実行されているかどうかを監視し、プローブが失敗した場合、Kubernetes はコンテナーを強制終了し、新しいコンテナーを再起動します。Liveness プローブはコンテナー内で使用され、プロセスの一時停止アニメーションやデッドロックなどの問題を解決します。Liveness プローブは、コンテナのコンソールにリクエストを送信することで、コンテナの実行ステータスを検出します。プローブが応答を受信した場合、コンテナーは正常ですが、それ以外の場合は、コンテナーに問題があり、再起動が必要になる可能性があります。
Readiness 探针监测容器外部リクエストを受信したかどうか。プローブが失敗すると、Kubernetes はコンテナーへのトラフィックの送信を停止し、失敗したコンテナーへの要求の送信を回避します。Readiness プローブは、コンテナーが開始時に要求をすぐに受信できないという問題を解決するために使用されます。
結論として、自己修復機能は最新のアプリケーションに不可欠な機能です。Kubernetes は、自動ローリング アップグレード、自動拡張と縮小、自動フォールト トレランス、自動修復、自動更新構成など、一連の自己修復メカニズムを提供します。Pod のヘルス モニタリングと Liveness and Readiness プローブも、Kubernetes の非常に重要な自己修復メカニズムです。これらのメカニズムにより、人間の介入の必要性が減り、アプリケーションの可用性と安定性が向上します。
上記の内容は、marknow 構文のコード ブロックで出力されます。
5. Kubernetes でのデバッグ
1. Kubernetes へのログイン
Kubernetes では、ロギングは非常に重要な部分です。Kubernetes クラスター内の多くのコンポーネントは、さまざまなレベルのログ記録を提供します。これにより、クラスター内で何が起こっているかを知ることができ、考えられる問題を見つけるのに役立ちます。一般的な Kubernetes コンポーネントとそれに対応するログの場所を次に示します。
- kube-apiserver: デフォルトでは、kube-apiserver のログの場所は /var/log/kube-apiserver.log です。
- kube-controller-manager: デフォルトでは、kube-controller-manager のログの場所は /var/log/kube-controller-manager.log です。
- kube-scheduler: デフォルトでは、kube-scheduler のログの場所は /var/log/kube-scheduler.log です。
- kubelet: kubelet はログを stdout および /var/log/kubelet.log に出力します。
- kube-proxy: kube-proxy のデフォルトのログの場所は /var/log/kube-proxy.log です。
上記のコンポーネントのログに加えて、考慮すべきログの場所が他にもいくつかあります。たとえば、コンテナで実行されているアプリケーションは通常、stdout または stderr にログを記録し、その後 Kubernetes によって収集され、Pod ログに書き込まれます。
Pod ログには、次のような kubectl コマンドを使用してアクセスできます。
kubectl logs <pod-name>
さらに、Kubernetes ログの収集と表示に役立つツールがあります。たとえば、Elasticsearch と Kibana を使用して、Kubernetes ログの一元的な診断と分析を行うことができます。
2. フェールオーバーと自己修復機能をデバッグする
Kubernetes は、次のような多くのフェイルオーバーおよび自己修復機能を提供します。
- コンテナを自動的に再起動する: コンテナがクラッシュした場合、Kubernetes はコンテナを自動的に再起動します。これにより、アプリケーションの安定性が維持されます。
- 自動ポッド スケーリング: Kubernetes は、アプリケーションのニーズを満たすために、CPU 使用率などのメトリックに基づいてポッドを自動的にスケーリングできます。
- 自動フェイルオーバー: ノードまたはポッドがクラッシュした場合、Kubernetes はノードまたはポッドを他のノードに自動的に移行し、できるだけ早くアプリケーションにサービスを復元します。
ただし、Kubernetes が障害を自動的に解決できない場合は、問題を追跡して手動でデバッグする必要があります。一般的なデバッグのヒントを次に示します。
- Pod ステータスの表示: kubectl コマンドを使用して、Pod のステータスを表示できます。次に例を示します。
kubectl get pods
これにより、すべての Pod とその現在のステータスが一覧表示されます。
- イベントの表示: kubectl コマンドを使用して、クラスターで発生するイベントを表示できます。次に例を示します。
kubectl get events
これにより、クラスターで発行されたすべてのイベントが一覧表示されます。
- Pod ログのエクスポート: Pod が異常な状態にある場合、kubectl コマンドを使用して Pod ログをエクスポートできます。次に例を示します。
kubectl logs <pod-name> > pod.log
これにより、Pod ログが pod.log ファイルにエクスポートされ、分析が容易になります。
- コンテナーのデバッグ: kubectl exec コマンドを使用して、コンテナー内でコマンドを実行できます。次に例を示します。
kubectl exec <pod-name> <container-name> -- <command>
これにより、コンテナ内でコマンドが実行されます。
Kubernetes では、フェールオーバーと自己修復機能のログ記録とデバッグが非常に重要です。クラスター内のログとイベントを監視することで、問題をすばやく特定し、アプリケーションをデバッグできます。Kubernetes の自動フェイルオーバーと自己修復機能は、アプリケーションの安定性を維持するのに役立ちますが、Kubernetes が問題を自動的に解決できない場合は、問題を手動で追跡してデバッグする必要があります。
6. フェイルオーバーと自己修復機能を改善する
1. ベスト プラクティスとツール
Kubernetes では、フェイルオーバーと自己修復機能を改善するために、次のベスト プラクティスとツールを採用できます。
1.1 ヘルスチェックを使用する:
コンテナに Liveness Probe と Readiness Probe を設定することで、定期的にコンテナのヘルスステータスをチェックし、状況に応じてコンテナを再起動または終了することができます。これにより、1 つのコンテナーの障害によってアプリケーション全体がダウンするのを防ぐことができます。
ヘルスチェックを使用するには:
-
Kubernetes デプロイメントまたはポッドを作成します。
-
デプロイまたはポッドでヘルス チェックを定義します。
-
デプロイまたはポッドを実行します。
1.1.1 HTTP ヘルス チェックを使用したデプロイのサンプル コード:
apiVersion: apps/v1
kind: Deployment
metadata:
name: example-deployment
spec:
replicas: 3
selector:
matchLabels:
app: example
template:
metadata:
labels:
app: example
spec:
containers:
- name: example-container
image: example-image
ports:
- containerPort: 80
livenessProbe:
httpGet:
path: /healthz
port: 80
periodSeconds: 5
initialDelaySeconds: 15
この例では、example-container という名前のコンテナーをそれぞれ含む 3 つのレプリカを作成する、example-deployment という名前のデプロイを定義します。コンテナーは image: example-image を使用し、ポート 80 でリッスンします。さらに、コンテナーの /healthz エンドポイントが使用可能であることを確認する HTTP ヘルス チェックを定義します。livenessProbe は、コンテナーの正常性を 5 秒ごとにチェックし、コンテナーが開始してから 15 秒後まで開始しないように Kubernetes に指示します。
- kubectl コマンド ライン ツールを使用して、上記のデプロイを実行できます。
kubectl apply -f example-deployment.yaml
この時点で、Kubernetes は 3 つのポッドと 1 つのサービスを含むデプロイを作成します。その後、Kubernetes はコンテナーの正常性のチェックを開始し、正常でない場合はコンテナーを再起動します。
1.2 複数のコピーを実行する:
Kubernetes は、複数のレプリカを実行することで、アプリケーションの可用性と信頼性を向上させることができます。これは、ポッドに障害が発生した場合、Kubernetes が自動的にレプリカをスケールアップして新しいポッドを開始できることを意味し、アプリケーションがクラスター内で常に稼働していることを保証します。
1.1.2 Kubernetes を使用して複数のレプリカを実行するための操作手順:
-
Deployment または StatefulSet を作成します。
-
YAML ファイルでレプリカの数を定義します。
-
Deployment または StatefulSet を実行します。
以下は、3 つのレプリカを持つ Deployment のサンプル コードです。
apiVersion: apps/v1
kind: Deployment
metadata:
name: example-deployment
spec:
replicas: 3
selector:
matchLabels:
app: example
template:
metadata:
labels:
app: example
spec:
containers:
- name: example-container
image: example-image
ports:
- containerPort: 80
この例では、example-deployment という Deployment を定義し、そのレプリカ数を仕様で 3 と指定します。次に、image: example-image を使用し、ポート 80 でリッスンする example-container というコンテナーを定義します。
- kubectl コマンド ライン ツールを使用して、上記のデプロイを実行できます。
kubectl apply -f example-deployment.yaml
Kubernetes は、それぞれが example-container コンテナーを含む 3 つのレプリカを開始します。その後、Kubernetes は自動的にワークロードを転送して、スケジューリング セットが障害なく実行されるようにします. Pod の 1 つが正常に実行されない場合、Kubernetes は新しい Pod を開始してそれを置き換えます.
これは、複数のレプリカを実行するだけで、Kubernetes がアプリケーションの可用性と信頼性を向上させる方法です。
1.3 自動拡張を使用する:
Kubernetes の自動スケーリング機能は、高トラフィック、高同時実行、およびその他の負荷に対処するのに役立ち、アプリケーションが常に最高のパフォーマンスで実行されるようにします。
1.1.3 Kubernetes を使用して容量を自動的に拡張するための操作手順:
-
Deployment または StatefulSet を作成します。
-
YAML ファイルで CPU やメモリのしきい値を定義します。
-
Auto Scaling ルールを構成します。
-
Deployment または StatefulSet を実行します。
以下は、CPU 使用率に基づいて自動的にスケールアップするデプロイのサンプル コードです。
apiVersion: apps/v1
kind: Deployment
metadata:
name: example-deployment
spec:
replicas: 3
selector:
matchLabels:
app: example
template:
metadata:
labels:
app: example
spec:
containers:
- name: example-container
image: example-image
ports:
- containerPort: 80
resources:
limits:
cpu: "500m"
requests:
cpu: "200m"
readinessProbe:
httpGet:
path: /healthz
port: 80
periodSeconds: 5
initialDelaySeconds: 15
livenessProbe:
httpGet:
path: /healthz
port: 80
periodSeconds: 5
initialDelaySeconds: 15
autoscaler:
targetCPUUtilizationPercentage: 80
minReplicas: 3
maxReplicas: 10
この例では、example-deployment という名前の Deployment を定義し、仕様でレプリカの数を 3 と指定します。次に、image: example-image を使用し、ポート 80 でリッスンするコンテナーを定義します。コンテナーに加えて、CPU 使用率に基づいてレプリカの数を調整する自動スケーリング ルールを構成する HorizontalPodAutoscaler オブジェクトも定義します。
オートスケーラーの targetCPUUtilizationPercentage フィールドは CPU 使用率の目標値を 80% に設定し、minReplicas は Pod インスタンスの最小数を 3 に設定し、maxReplicas は Pod インスタンスの最大数を 10 に設定します。これは、CPU 使用率が 80% を超えると、Kubernetes が 3 つの Pod インスタンスにわたってデプロイを自動的にスケーリングし、最大 10 のレプリカに到達することを意味します。
- kubectl コマンド ライン ツールを使用して、上記のデプロイを実行できます。
kubectl apply -f example-deployment.yaml
Kubernetes は 3 つのレプリカをスピンアップし、負荷の増加に応じて展開を自動的にスケーリングするため、アプリケーションが常に最適に実行されるようになります。
1.4 グレースケール リリース:
グレースケール ロールアウトは、アプリケーションの新しいバージョンを本番環境に段階的に導入する方法です。これにより、障害のリスクを軽減し、アプリケーションの可用性を向上させることができます。Kubernetes は、グレースケール リリースの実装に使用できる Deployment や Service などのリソース オブジェクトを提供します。
1.1.4 Kubernetes グレースケール リリースを使用するための操作手順:
-
2 つの Deployment を作成します。1 つは古いアプリケーション用で、もう 1 つは新しいアプリケーション用です。
-
ロード バランサーで Service を定義し、それを古い Deployment の Pod にポイントします。
-
Service が新しい Deployment の Pod を指すように段階的に変更して、新しいアプリケーションの機能とパフォーマンスを順次テストします。
以下は、グレースケールを使用して公開されたサンプル コードです。
apiVersion: apps/v1
kind: Deployment
metadata:
name: old-app
spec:
replicas: 3
selector:
matchLabels:
app: old-app
template:
metadata:
labels:
app: old-app
spec:
containers:
- name: old-app-container
image: old-app-image
ports:
- containerPort: 80
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: new-app
spec:
replicas: 1
selector:
matchLabels:
app: new-app
template:
metadata:
labels:
app: new-app
spec:
containers:
- name: new-app-container
image: new-app-image
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: app-service
spec:
type: LoadBalancer
selector:
app: old-app
ports:
- name: http
port: 80
targetPort: 80
この例では、2 つの Deployment を定義します。1 つは old-app という名前の古いアプリケーション用で、もう 1 つは new-app という名前の新しいアプリケーション用です。また、app-service という Service を定義し、それをロード バランサー タイプとして設定し、それを old-app の Pod にポイントします。これにより、すべてのトラフィックが古いアプリケーションのポッドに送信されます。
次に、Service の定義を段階的に変更して、新しいアプリケーションの Pod を指すようにします。これは、kubectl コマンド ライン ツールを使用して実行できます。
この例では、2 つの Deployment を定義します。1 つは old-app という名前の古いアプリケーション用で、もう 1 つは new-app という名前の新しいアプリケーション用です。また、app-service という Service を定義し、それをロード バランサー タイプとして設定し、それを old-app の Pod にポイントします。これにより、すべてのトラフィックが古いアプリケーションのポッドに送信されます。
次に、Service の定義を段階的に変更して、新しいアプリケーションの Pod を指すようにします。これは、kubectl コマンド ライン ツールを使用して実行できます。
kubectl apply -f new-service.yaml
これにより、新しい定義の Service を使用して、トラフィックが新しいアプリケーションの Pod に転送されます。時間が経つにつれて、新しいアプリケーションのレプリカの数を徐々に増やし、トラフィックを新しいアプリケーションにシフトして、そのパフォーマンスと機能をより完全にテストできます。
1.5 構成のバックアップと復元:
Kubernetes は、ConfigMap と Secret を Pod にマッピングすることで、アプリケーション構成の簡単なバックアップと復元をサポートします。これにより、復元時のエラーを回避できます。
1.1.5 Kubernetes 構成のバックアップとリカバリーを使用するための操作手順:
Kubernetes 構成のバックアップと復元は、予期しない状況が発生した場合に、アプリケーションと構成データをより適切に保護するのに役立ちます。Kubernetes を使用してバックアップと復元を構成する手順は次のとおりです。
-
構成ファイルを作成します。
-
構成ファイルをバックアップします。
-
構成ファイルを復元します。
基本的な構成ファイルの例を次に示します。
apiVersion: v1
kind: ConfigMap
metadata:
name: app-config
data:
app.properties: |
database.url=jdbc:mysql://localhost/mydb
database.username=admin
database.password=secret
この例では、app-config という名前の ConfigMap オブジェクトを定義します。これには、アプリケーション、データベース URL、ユーザー名とパスワードなどの構成の詳細を含む app.properties と呼ばれるキーと値のペアが含まれています。
構成ファイルをバックアップするには、kubectl コマンドライン ツールを使用して ConfigMap オブジェクトを YAML ファイルにバックアップします。
kubectl get configmaps app-config -o yaml > app-config.yaml
これにより、 app-config という名前の ConfigMap オブジェクトが app-config.yaml ファイルにエクスポートされ、後で復元できるようになります。必要に応じて、Deployment や StatefulSet などのその他のリソースをバックアップできます。
構成ファイルを復元するには、kubectl コマンド ライン ツールを使用してバックアップ ファイルを Kubernetes にインポートします。
kubectl apply -f app-config.yaml
これにより、新しい ConfigMap オブジェクトが作成され、app-config.yaml ファイルで定義されたキーと値のペアがオブジェクトにインポートされます。
1.6 ストレージ クラスを使用する:
Kubernetes は、Persistent Volume や StorageClass などのさまざまなタイプのストレージ クラスを提供します。これらを使用して、コンテナー間で永続的なストレージとデータ共有を実装できます。アプリケーションの移行やノード障害からデータを保護するのに役立ちます。
1.1.6 Kubernetes を使用してストレージ クラスを使用するための操作手順:
以下は、ストレージ クラスを使用する基本的な操作プロセスです。
- ストレージ クラスを作成します。
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: my-storage-class
provisioner: my-provisioner
ここで、my-storage-class はストレージ クラスの名前で、my-provisioner は動的ボリューム サブシステムの名前です。
- Pod でストレージ クラスを使用します。
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: my-container
image: nginx
volumeMounts:
- mountPath: "/usr/share/nginx/html"
name: my-volume
volumes:
- name: my-volume
persistentVolumeClaim:
claimName: my-claim
my-claim は、ストレージ クラスを使用した永続ボリューム クレームの名前です。
- ストレージ クラスを使用して永続ストレージを提供する永続ボリューム要求オブジェクトを作成します。
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: my-claim
spec:
storageClassName: my-storage-class
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
ここで、my-claim は永続ボリューム クレームの名前で、my-storage-class は使用されるストレージ クラスの名前です。
2. Kubernetes を介してアプリケーションを実行すると、システムの信頼性が向上します
Kubernetes は、分散システムでアプリケーションを管理および実行する自動コンテナー化テクノロジーです。この手法の主な利点は次のとおりです。
- ノードの自動構成、サービス検出、障害復旧などの機能。
- 水平拡張をサポートすることで、システムのフォールト トレランスと負荷容量を向上させます。
- ローリング アップデートを使用してコードをデプロイできるため、アプリケーションの停止やダウンタイムを回避できます。
- 自動化されたロード バランサとサービス ディスカバリを提供して、ネットワーク トラフィックとルーティングを最適化します。
- 複数の監視ツールを統合して、アプリケーションのエラーと障害をリアルタイムで検出して解決します。
7. 結論
1. 要点をまとめる
全体として、この記事では、ヘルス チェックの使用、複数のレプリカの実行、自動スケーリングとグレースケール ロールアウト、バックアップと復旧の構成など、Kubernetes がフェールオーバーと自己修復機能を改善できる多くの方法について説明します。これらの方法は、アプリケーションが常に使用可能であり、障害が発生したときに自動的に回復できるように設計されています。
クラウド コンピューティングの発展とアプリケーションの複雑化に伴い、アプリケーションの可用性と回復力を向上させることがますます重要になっています。Kubernetes が提供するこれらの方法を使用することで、企業はアプリケーションとデータをより適切に管理および保護し、ユーザーのニーズと要件をより適切に満たすことができます。
2. 未来を考える
将来、テクノロジーが進歩し続け、アプリケーションが進化するにつれて、Kubernetes はますますインテリジェントになり、フェイルオーバーと自己修復機能を改善するために、より適応性の高い自己修復アプローチを採用する可能性があります。変化するアプリケーションやテクノロジー環境に対応するために、企業や個人が Kubernetes によって提供されるこれらの方法を理解し、習得することがますます重要になります。
