Kubernetesサービスの概要と実装方法

Service(サービス)とは何ですか? Service(サービス)は、Kubernetesで最も重要なリソースオブジェクトの1つであり、サービスはアクセスポイントのアドレスを定義し、フロントエンドのアプリケーション(Pod)はこのアクセスポイントを使用してその背後にある一連のPodレプリカで構成されるクラスターインスタンスにアクセスします。 ServiceとそのバックエンドのPodレプリカの間の関係は、ラベルセレクターを使用して “シームレスな接続”を実現します。そして、RCの役割は実際には、Serviceのサービス能力とサービス品質が予想される基準にあることを保証することです。 Kubernetesが提供するマイクロサービスネットワークアーキテクチャ すべてのサービスを分析、識別し、システム内のすべてのサービスをマイクロサービスとしてモデル化することにより—Kubernetesサービス、最終的には、私たちのシステムは異なるビジネス機能を提供し、お互いに独立している複数のマイクロサービスユニットで構成されます。サービス間の通信はTCP/IPを介して行われ、強力な分散能力、弾力性のある拡張能力、耐障害性を備えています。 各Podには個別のIPアドレスが割り当てられ、各Podはクライアントがアクセスするための独自のエンドポイント(Pod IP+コンテナポート)を提供します。現在、複数のPodレプリカがアクセスを提供するためにクラスターを形成しました。 Kubernetesは、各Nodeにkube-proxyをインストールする必要があります。kube-proxyプロセスは実際にはスマートなソフトウェアロードバランサーであり、Serviceへのリクエストをバックエンドの特定のPodインスタンスに転送し、サービスの負荷分散とセッション維持メカニズムを内部で実装します。 Kubernetesは、非常に巧妙なデザインを考案しました。Serviceは負荷分散器のIPアドレスを共有するのではなく、各Serviceにはグローバルでユニークな仮想IPアドレスが割り当てられます。この仮想IPはCluster IPと呼ばれます。これにより、各サービスは”通信ノード”として一意のIPアドレスを持つことになり、サービス呼び出しは最も基本的なTCPネットワーク通信の問題に変わります。 Podのエンドポイントアドレスは、Podが破棄され、再作成されるたびに変更されます。新しいPodアドレスは以前の古いPodとは異なります。一方、Serviceが作成されると、Kubernetesは自動的に使用可能なCluster IPを割り当て、Serviceのライフサイクル全体でそのCluster IPが変更されないようにします。したがって、Serviceの名前とServiceのCluster IPアドレスをDNSドメインマッピングとして使用するだけで問題が解決します。 Serviceの作成例:Serviceの手動作成 パラメーターの解説ポート:ポートは、サービスがクラスターIP(サーバーIP)で公開されるポートを表します。 :ポートは、クラスター内のクライアントがサービスにアクセスするための入り口を提供します。ノードポート:ノードポートは、Kubernetesが外部クライアントがサービスにアクセスするための入り口として提供する方法の1つです(もう1つの方法はLoadBalancerです)。 :ノードポートは、クラスターの外部クライアントがサービスにアクセスするための入り口を提供します。ターゲットポート:ターゲットポートは非常に理解しやすいです。ターゲットポートは、ポッド上のポートであり、ポートとノードポートを通過するデータが最終的にはkube-proxyを介してバックエンドのポッドのターゲットポートに入るためです。作成 サーバーの詳細情報を表示

Read More

KubernetesのPodライフサイクルと再起動ポリシーの理解方法

Podライフサイクルと再起動ポリシー Podは、そのライフサイクル全体でシステムによって定義されたさまざまな状態を経験します。 ステート 説明 Pending APIサーバーがPodを作成しましたが、Pod内の1つ以上のコンテナイメージが正常に作成されていません。 Running Pod内のすべてのコンテナが作成され、少なくとも1つのコンテナが実行中、起動中、または再起動中の状態です。 Succeeded Pod内のすべてのコンテナが正常に終了し、再起動は行われません。 Failed Pod内のすべてのコンテナが終了しましたが、少なくとも1つのコンテナが失敗ステータスで終了しました。 Unknown 何らかの理由でPodの状態を取得できません。ネットワーク通信の問題による可能性があります。 Podの再起動ポリシー PodのRestartPolicyは、Pod内のすべてのコンテナに適用され、Podが存在するノードのkubeletによってのみ判断および再起動されます。コンテナが異常終了した場合やヘルスチェックに失敗した場合、kubeletはRestartPolicyの設定に基づいて適切なアクションを実行します。 PodのRestartPolicyにはAlways、OnFailure、Neverの3つのオプションがあり、デフォルト値はAlwaysです。 失敗したコンテナを再起動するkubeletの時間間隔は、sync-frequencyに2nを乗算して計算されます。たとえば、1、2、4、8倍などです。最大遅延は5分で、成功した再起動後にこの時間が10分後にリセットされます。 PodのRestartPolicyは、その制御方法と密接に関連しています。現在、Podを管理するために使用できるコントローラーには、ReplicationController、Job、DaemonSet、およびkubelet管理(StaticPod)が含まれます。各コントローラーの再起動ポリシーの要件は次のとおりです。 kubeletはPodが失敗したときに自動的に再起動しますが、RestartPolicyの設定に関係なく、Podに対してヘルスチェックは実行しません。

Read More