KubernetesのClusterIP、NodePort、およびLoadBalancerサービスタイプの違いは何ですか？
1 - 私はドキュメンテーションを読んでいます、そして私は文言と少し混乱しています。それは言います：
ClusterIP：サービスをクラスタ内部IPに公開します。この値を選択すると、サービスはクラスタ内からのみ到達可能になります。これはデフォルトのServiceTypeです。
NodePort：各ノードのIP上のサービスを静的ポート（NodePort）に公開します。 NodePortサービスのルーティング先となるClusterIPサービスが自動的に作成されます。
<NodeIP>:<NodePort>をリクエストすることで、クラスタの外からNodePortサービスに連絡することができます。LoadBalancer：クラウドプロバイダのロードバランサーを使用してサービスを外部に公開します。外部ロードバランサがルーティングするNodePortおよびClusterIPサービスは自動的に作成されます。
NodePortサービスタイプはまだClusterIPを使用していますが、外部クライアントに開放されている別のポートで使用していますか？それで、この場合<NodeIP>:<NodePort>は<ClusterIP>:<NodePort>と同じですか？
それともNodeIPは実際にはkubectl get nodesを実行したときに見つかったIPであり、ClusterIPサービスタイプに使用される仮想IPではありませんか。
2 - 下のリンクからの図でも：
http://kubernetes.io/images/docs/services-iptables-overview.svg
ClientがNodeの内側にある理由は特にありますか？私はそれがClusterIPサービスタイプの場合にはClusterの中にある必要があると思いました。
NodePortに対して同じ図を描いた場合、クライアントをNodeとClusterの両方の外側に完全に描くことは有効でしょうか。
ClusterIPは次を公開します。
spec.clusterIp:spec.ports[*].port
このサービスには、クラスター内でのみアクセスできます。 spec.clusterIpポートからアクセスできます。 spec.ports[*].targetPortが設定されている場合、ポートからtargetPortにルーティングされます。 kubectl get servicesを呼び出したときに取得するCLUSTER-IPは、クラスター内でこのサービスに内部的に割り当てられたIPです。
NodePortは以下を公開します。
<NodeIP>:spec.ports[*].nodePortspec.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[*].nodePortspec.clusterIp:spec.ports[*].port
ロードバランサーのIPアドレスからこのサービスにアクセスできます。このアドレスは、リクエストをnodePortにルーティングし、nodePortはリクエストをclusterIPポートにルーティングします。 NodePortまたはClusterIPサービスと同様に、このサービスにアクセスできます。
より単純なレベルで3の違いは何ですかを探している人のために明確にすること。最小限のClusterIp（k8sクラスタ内）、またはNodePort（k8sクラスタの外部のクラスタ内）またはLoadBalancer（外部の世界、またはLBで定義したものすべて）を使用してサービスを公開することができます。
ClusterIp exposure < NodePort exposure < LoadBalancer exposure
ClusterIp -> Expose service through **k8s cluster** with ip/name:port
NodePort -> Expose service through **Internal network VM's** also external to k8s ip/name:port
LoadBalancer -> Expose service through **External world** or whatever you defined in your LB.
ClusterIP：サービスはクラスタ内のポッド/サービスから到達可能です
タイプがClusterIPのデフォルト名前空間でmyserviceというサービスを作成すると、そのサービス用に次の予測可能な静的DNSアドレスが作成されます。
myservice.default.svc.cluster.local（または単にmyservice.default、またはデフォルトの名前空間内のpodで "myservice"が機能する）
そのDNS名は、クラスタ内のポッドとサービスによってのみ解決できます。
NodePort：サービスは、同じLAN上のクライアント/ K8sホストノード（およびクラスタ内のポッド/サービス）にpingできるクライアントから到達可能です（セキュリティ上の理由から、k8sホストノードはオンにする必要があります）。プライベートサブネット、つまりインターネット上のクライアントはこのサービスにアクセスできません）
タイプがmynamespaceのネームスペースでmynodeportserviceというサービスを作成すると、3ノードKubernetesクラスタのNodePortになります。次に、タイプがClusterIPのサービスが作成され、次の予測可能な静的DNSアドレスでクラスタ内のクライアントから到達可能になります。
mynodeportservice.mynamespace.svc.cluster.local（または単にmynodeportservice.mynamespace）
Mynodeportserviceが30000から32767の範囲のノードポートでlistenする各ポートに対して、ランダムに選択されます。クラスタの外部にある外部クライアントが、クラスタの内部に存在するそのClusterIPサービスにアクセスできるようにします。私たちの3つのK8sホストノードにはIP10.10.10.1、10.10.10.2、10.10.10.3があり、Kubernetesサービスはポート80でリッスンしており、ランダムに選択されたNodeportは31852でした。
クラスタ外に存在するクライアントは10.10.10.1:31852、10.10.10.2:31852、または10.10.10.3:31852にアクセスできます（NodePortはすべてのKubernetesホストノードによって待機されているため）Kubeproxyはリクエストを転送しますmynodeportserviceのポート80に。
LoadBalancer：インターネットに接続している人なら誰でもサービスにアクセスできます*（共通のアーキテクチャはL4 LBです。インターネット上でDMZに入れるか、またはプライベートおよびパブリックIPとk8sホストノードはプライベートサブネット上にあります）
[注：]これは、ベアメタルKubernetesのように、100％のKubernetes実装では機能しない唯一のサービスタイプです。Kubernetesにクラウドプロバイダの統合がある場合に機能します。）
mylbserviceを作成すると、L4 LB VMが生成されます（クラスタIPサービス、およびNodePortサービスも同様に暗黙的に生成されます）。今回のNodePortは30222です。L4 LBのパブリックIPは1.2.3.4で、プライベートIPアドレスを持つ3 K 8sホストノードにトラフィックをロードバランスして転送するという考えです。 （10.10.10.1:30222、10.10.10.2:30222、10.10.10.3:30222）その後、Kube Proxyはそれをクラスター内に存在するタイプClusterIPのサービスに転送します。
あなたも尋ねました：NodePortサービスタイプはまだClusterIPを使用しますか？はい*
または、NodeIPは実際にはkubectl get nodesを実行したときに見つかったIPですか？はい*
基礎の間に平行線を引きましょう。
容器がポッドの中にあります。ポッドはレプリカセット内にあります。レプリカセットはデプロイメント内にあります。
よく似ています。
ClusterIPサービスは、NodePortサービスの一部です。 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アドレスをタイプすることができます。
2-あなたがあなたのホストマシンからこのnginxポッドにアクセスしたいなら、あなたはNodePortであなたのデプロイメントを公開する必要があるでしょう。例えば：
$ kubectl expose deployment nginxapp --name=nginxnodeport --port=80 --target-port=8080 --type=NodePort
今すぐあなたのホストマシンからあなたはnginxにアクセスすることができます：
私のダッシュボードでは、それらは次のように表示されます。
以下は基本的な関係を示す図です。
- clusterIP：クラスタ内でアクセス可能なIP（dクラスタ内のノード間）。
nodeA : pod1 => clusterIP1, pod2 => clusterIP2
nodeB : pod3 => clusterIP3.
pod3はclusterIPネットワークを介してpod1と通信できます。
- nodeport：nodeIP：nodeportを介してクラスターの外部からpodにアクセスできるようにするために、clusterIPネットワークとして上記のclusterIPを作成/保持します。
nodeA => nodeIPA : nodeportX
nodeB => nodeIPB : nodeportX
nodeIPA：nodeportX OR nodeIPB：nodeportXを介して、pod1のサービスにアクセスできます。 kube-proxy（各ノードにインストールされている）があなたのリクエストを受け取り、clusterIPネットワークを使ってそれを[リダイレクト（iptables term）]してくれるのでどちらの方法でもうまくいきます。
- ロードバランサ
基本的にはLBを前面に置くだけなので、インバウンドトラフィックはnodeIPA：nodeportXとnodeIPB：nodeportXに分配され、その後上記のプロセスフロー番号2に進みます。