私はKubernetesを学んでいますが、現在は高可用性に没頭しています。高可用性のコントロールプレーン（APIサーバ、コントローラ、スケジューラ）をローカル（またはリモート）etcdsと高可用性（Kubernetes自体を通して）ミニオンのセット、私はまだこのコンセプトサービスがどこに位置しているか分からない。サービスはKubernetesにどこに住んでいますか？
コントロールプレーンに居住している場合：いいえ、私はそれらを高可用性に設定できます。
特定のノードに住んでいる場合は次のようになります。ただし、ノードが停止したり他の方法で使用できなくなった場合はどうなりますか？
私が理解しているように、ロードバランスだけでなく、インターネットにポッドを公開するサービスが必要です。 HAサービスがないので、私は自分のアプリケーションに到達することができない危険性があります（システムの他の面でも非常に高い可用性があります）。
KubernetesサービスはK8Sクラスタ内の別のRESTオブジェクトです。サービスには以下の種類があります。それらのそれぞれは、クラスタ内で異なる目的を果たします。ポッドへのゲートウェイの単一のポイントを提供するサービス
基本的な目的
それは、単一のソースであるとして、これらのオブジェクトは、がetcdに格納されていますクラスター内の真実。
これらのオブジェクトを作成するのはKube-proxyです。セレクタとラベルを使用します。
たとえば、各ポッドオブジェクトにラベルが付いているため、サービスオブジェクトにはこれらのラベルに一致するセレクタがあります。さらに、各ポッドにはエンドポイントがあるので、基本的にkube-proxyはこれらのエンドポイント（IP：Port）にサービス（IP：Port）を割り当てます.Kube-proxyはIP-Tablesルールを使用してこの魔法を実行します。
Kube-Proxyは、各クラスタノードにDaemonSetとして配備されているため、etcdを使用して相互に認識しています。
サービスは、内部（場合によっては外部）のロードバランサと考えることができます。定義はKubernetes APIサーバに保存されていますが、そこに存在するという事実は、何かが実装していない場合は何も意味しません。サービスで動作する最も一般的なコンポーネントは、iptablesを使用するノード上でサービスを実装するkube-proxyです（つまり、すべてのノードにローカルiptablesルールが実装されています）。 APIからのサービスコンセプトを使用してエンドポイントを見つけ、それらにトラフィックを誘導し、効果的にiptablesの実装をスキップするIngress Controller実装。最終的には、linkerdまたはistioのようなサービスメッシュソリューションがあり、サービス定義を独自に活用することができます。
ほとんどの実装では、ポッド間の負荷バランスがとられています。つまり、バッキングポッドが1つしかなくても十分な容量を持つ限り、「サービス」が応答します（HAを取得する、とりわけサービスから不健康なポッドを削除しますライブネスプローブ）
Kubernetes Serviceドキュメントはその
にかなり良い洞察を提供
Okですが、kubernetes.io/docs/concepts/services-networking/service/...に従って私のサービスのために単一のIPアドレスを要求することができます。これは私の理解では、特定のノード上のkube-proxyが1つだけになります。あるいは、これはサービスのラベルセレクタと一致するノード上で実行されているすべてのkube-proxyにapi-serverで実際にマップされますか？ –
Kube-proxyとKubeletは、現在の状態をすべてEtcdに保存しているKube-api Serverと通信します。一例をあげて理解しましょう.3つのノードにkubeletの助けを借りて3つのポッドが稼働しています。これらのすべてにエンドポイントがあります。ここでサービスマニフェストを展開する場合、kube-proxyはServiceエンドポイントがIPTABLESマジックのPodエンドポイントと揃っていることを確認します。 Kube-proxyはapi-serverと通信し、etcdを更新します。 –
Kube-proxyは、名前の代わりにラベルを使用してポッドを検索します。したがってセレクタとラベルはk8の強力なものです。さらに、Kube-proxyはKube-apiサーバーと通信して、ポッドの状態やサービスの変更をチェックします。 –