KubernetesのClusterIP、NodePort、LoadBalancerサービスタイプの違いは何ですか？

1-ドキュメントを読んでいますが、表現が少し混乱しています。それは言う：

ClusterIP：サービスをクラスター内部IPで公開します。この値を選択すると、サービスはクラスター内からのみ到達可能になります。これはデフォルトのServiceTypeです

NodePort：静的ポート（NodePort）で各ノードのIP上のサービスを公開します。NodePortサービスがルーティングするClusterIPサービスが自動的に作成されます。をリクエストすることにより、クラスターの外部からNodePortサービスに接続できます<NodeIP>:<NodePort>。

LoadBalancer：クラウドプロバイダーのロードバランサーを使用して、サービスを外部に公開します。外部ロードバランサーがルーティングするNodePortおよびClusterIPサービスは自動的に作成されます。

NodePortサービスタイプは引き続き使用しますが、ClusterIP外部クライアントに開かれている別のポートでのみ使用しますか？したがって、この場合と<NodeIP>:<NodePort>同じ<ClusterIP>:<NodePort>ですか？

それとも、NodeIP実行時に実際に見つかったkubectl get nodesIPであり、ClusterIPサービスタイプに使用されている仮想IPではないのでしょうか。

2-以下のリンクからの図でも：

http://kubernetes.io/images/docs/services-iptables-overview.svg

Clientが内部にある特別な理由はありますNodeか？ClusterClusterIPサービスタイプの場合、内部にある必要があると想定しました。

NodePortについて同じ図が描かれた場合、両方の外側に完全にクライアントを描画することは有効ですかNode、Clusterまたは私は完全にポイントを逃していますか？

ClusterIPは以下を公開します。

• spec.clusterIp:spec.ports[*].port

このサービスには、クラスター内でのみアクセスできます。spec.clusterIpポートからアクセスできます。spec.ports[*].targetPortが設定されている場合、ポートからtargetPortにルーティングされます。呼び出し時に取得するCLUSTER-IP kubectl get servicesは、クラスター内でこのサービスに内部的に割り当てられたIPです。

NodePortは以下を公開します。

• <NodeIP>:spec.ports[*].nodePort
• spec.clusterIp:spec.ports[*].port

ノードの外部IPからnodePortでこのサービスにアクセスすると、リクエストspec.clusterIp:spec.ports[*].portがにルーティングされ、spec.ports[*].targetPort設定されている場合はリクエストがにルーティングされます。このサービスには、ClusterIPと同じ方法でアクセスすることもできます。

NodeIPは、ノードの外部IPアドレスです。からサービスにアクセスできません<ClusterIP>:spec.ports[*].nodePort。

LoadBalancerは以下を公開します：

• spec.loadBalancerIp:spec.ports[*].port
• <NodeIP>:spec.ports[*].nodePort
• spec.clusterIp:spec.ports[*].port

このサービスには、ロードバランサーのIPアドレスからアクセスできます。このIPアドレスは、リクエストをnodePortにルーティングします。nodePortは、リクエストをclusterIPポートにルーティングします。NodePortまたはClusterIPサービスと同じように、このサービスにアクセスできます。

より単純なレベルで3の違いは何かを探している人のために明確にするため。最小限のClusterIp（k8sクラスター内）でサービスを公開するか、NodePort（k8sクラスターの外部クラスター内）またはLoadBalancer（外部ワールドまたはLBで定義したもの）でサービスを公開できます。

ClusterIp公開<NodePort公開<LoadBalancer公開

• CLUSTERIP
  を通じてサービスを公開K8Sクラスタでip/name:port
• k8sの外部の内部ネットワークVM
  を介したNodePort Exposeサービスip/name:port
• LoadBalancer
  Exposeサービス（外部の世界またはLBで定義したもの）

ClusterIP：サービスは、クラスター内のポッド/サービスから到達可能です。クラスター
IPのタイプのデフォルト名前空間でmyserviceというサービスを作成すると、次のサービスの予測可能な静的DNSアドレスが作成されます。

myservice.default.svc.cluster.local（またはmyservice.defaultのみ、またはデフォルトの名前空間のポッドによって「myservice」のみが機能します）

そして、そのDNS名は、クラスター内のポッドとサービスによってのみ解決できます。

NodePort：K8sホストノード（およびクラスター内のポッド/サービス）にpingを送信できる同じLAN /クライアント上のクライアントはサービスに到達できます（セキュリティ上の理由から、k8sホストノードはプライベートサブネット上にある必要があるため、インターネット上のクライアントが勝ちますこのサービスに到達できない）
タイプのmynamespace名前空間でmynodeportserviceというサービスを作成した場合：3ノードKubernetesクラスター上のNodePort。次に、タイプがClusterIPのサービスが作成され、次の予測可能な静的DNSアドレスでクラスター内のクライアントから到達可能になります。

mynodeportservice.mynamespace.svc.cluster.local（または単にmynodeportservice.mynamespace）

mynodeportserviceが30000-32767の範囲のノードポートでリッスンする各ポートについて、ランダムに選択されます。そのため、クラスターの外部にある外部クライアントは、クラスターの内部に存在するClusterIPサービスにアクセスできます。3つのK8ホストノードにIP 10.10.10.1、10.10.10.2、10.10.10.3があり、Kubernetesサービスがポート80でリッスンしていて、ランダムに選択されたノードポートが31852

だったとします。クラスターの外部に存在するクライアントは、 10.10.10.1:31852、10.10.10.2:31852、または10.10.10.3:31852（すべてのKubernetesホストノードがNodePortをリッスンしているため）Kubeproxyはリクエストをmynodeportserviceのポート80に転送します。

LoadBalancer：インターネットに接続しているすべての人がサービスにアクセスできます*（一般的なアーキテクチャは、L4 LBはDMZに配置するか、プライベートIPとパブリックIPの両方を提供することでインターネット上でパブリックにアクセスでき、k8sホストノードはプライベートサブネット上にあります）
（注：これは、ベアメタルKubernetesのように、Kubernetes実装の100％で機能しない唯一のサービスタイプであり、Kubernetesにクラウドプロバイダーの統合がある場合に機能します。

mylbserviceを作成すると、L4 LB VMが生成されます（クラスターIPサービス、およびNodePort Serviceも暗黙的に生成されます）。今回のNodePortは30222です。L4LBには1.2.3.4のパブリックIPがあり、トラフィックをロードバランスして、プライベートIPアドレスを持つ3つのK8sホストノードにトラフィックを転送するという考えです。（10.10.10.1:30222、10.10.10.2:30222、10.10.10.3:30222）その後、Kube Proxyはそれをクラスタ内に存在するタイプClusterIPのサービスに転送します。

あなたも尋ねました：NodePortサービスタイプはClusterIPをまだ使用していますか？はい*
または、kubectl get nodesを実行したときにNodeIPが実際に見つかったIPですか？また、はい*

基礎の間で平行線を描きましょう：
コンテナーはポッド内にあります。ポッドはレプリカセット内にあります。レプリカセットはデプロイメント内にあります。
同様
に、ClusterIP ServiceはNodePort Serviceの一部です。NodePortサービスは、ロードバランサーサービスの一部です。

この図では、クライアントはクラスター内のポッドになります。

ローカルマシンにUbuntu VMを作成したと仮定します。IPアドレスは192.168.1.104です。

VMにログインし、Kubernetesをインストールします。次に、nginxイメージが実行されるポッドを作成しました。

1- VM内でこのnginxポッドにアクセスする場合は、そのポッドにバインドされたClusterIPを作成します。次に例を示します。

$ kubectl expose deployment nginxapp --name=nginxclusterip --port=80 --target-port=8080

次に、ブラウザで次のようにポート80でnginxclusteripのIPアドレスを入力できます。

http://10.152.183.2:80

2-ホストマシンからこのnginxポッドにアクセスする場合は、NodePortでデプロイメントを公開する必要があります。例えば：

$ kubectl expose deployment nginxapp --name=nginxnodeport --port=80 --target-port=8080 --type=NodePort

これで、ホストマシンから次のようにnginxにアクセスできます。

http://192.168.1.104:31865/

私のダッシュボードでは、次のように表示されます。

以下は、基本的な関係を示す図です。

この質問にすでに回答があったとしても、理解を深めるために、もう1つ質問に写真を追加します。

1. ClusterIPはKubernetesのデフォルトのサービスタイプであり、このタイプはクラスター内のサービスを提供します。これを使用することにより、クラスターの他のアプリケーションはKubernetesプロキシ経由でサービスにアクセスできます。

このタイプのサービスは、プロダクションサービスの公開には使用しないでください。しかし、それはのために使用することができます

• サービス間の統合のデバッグ;
• ビジネスに関連しないデータ（監視ダッシュボード）を公開している内部サービスにアクセスする。

リクエストの方法は次のとおりです。トラフィック-> K8sプロキシ-> K8sサービス（ClusterIP）->ポッドと、次の図に表示されています。

2. NodePortは、外部トラフィックを受け入れ、それをkubernetesサービスに転送する最も基本的な方法です。名前が示すように、NodePortサービスタイプは、実際にKubernetesノードであるすべての仮想マシンで特定のポートを開き、その特定のポートに送信されたトラフィックをサービスに転送できるようにします。

NodePortサービスタイプにはいくつかの欠点があります。

• ポートごとに1つのサービスのみが必要です。
• 仮想マシンのIPを変更する場合、いくつかの変更をクラスターで行う必要があります。
• 3000〜32767のポートのみ使用できます。

リクエストの方法は次のとおりです。トラフィック->仮想マシンで公開されているポート-> K8sサービス（NodePort）->ポッドで、次の図に表示されています。

3. LoadBalancerは、サービスをインターネットに公開する標準的な方法です。サービスと特定のポートのすべてのトラフィックを直接公開してサービスに注意を向けたい場合は、これがその方法です。また、LoadBalancerサービスタイプには、フィルタリングやルーティングは含まれません。また、TCP、UDP、HTTP gRPCトラフィックを送信できます。

欠点：LoadBalancerを介して公開される各サービスには独自のIPアドレスがあり、すべてのサービスは単一のLoadBalancerを介して公開されるため、コストが高くなる可能性があります。

リクエストのパスは次のとおりです。トラフィック-> LoadBalancer-> K8sサービス->ポッド。次の図に表示されています。

1. clusterIP：（dクラスター内のノード間で）クラスター内でアクセス可能なIP。

nodeA : pod1 => clusterIP1, pod2 => clusterIP2
nodeB : pod3 => clusterIP3.

pod3は、clusterIPネットワークを介してpod1と通信できます。

2. nodeport：nodeIP：nodeportを介してクラスターの外部からポッドにアクセスできるようにするために、上記のclusterIPをclusterIPネットワークとして作成/保持します。

nodeA => nodeIPA : nodeportX
nodeB => nodeIPB : nodeportX

nodeIPA：nodeportXまたはnodeIPB：nodeportXのいずれかを介して、pod1のサービスにアクセスできます。（各ノードにインストールされている）kube-proxyがリクエストを受け取り、clusterIPネットワークを使用してノード間でそれを[redirect it（iptables term）]分散するため、どちらの方法でも機能します。

3. ロードバランサー

基本的にLBを前に置くだけで、インバウンドトラフィックがnodeIPA：nodeportXとnodeIPB：nodeportXに分散されるようにしてから、上記のプロセスフロー2を続行します。