名前空間とK8S namespace単離リソースには、デフォルトでは、同じ名前空間のサービスは、互いに通信し、副分離その逆ができます。

サービスサービス

1.1サービス

Kubernetesアプリケーションサービスインスタンス有する1つ以上の（ポッドは、ポッド複数のレプリカは、RSを介して確立することができる）、各インスタンスネットワークダイナミック・ランダム・プラグ（IPアドレス変更後のポッドの再起動によって割り当てられたIPアドレスの（POD））。これらの動的ロードバランシングとマルチインスタンスの例の後端部をシールドするために変更、サービス・リソース・オブジェクトの導入、次の通り：

apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
  labels:
    app: nginx
spec:
  type: ClusterIP
  ports:
    - port: 80
       targetPort: 80
  selector:  #service通过selector和pod建立关联
    app: nginx

タイプを作成するサービスの種類に応じて、4つのモードに分けることができます。

ClusterIP：デフォルト。生成されたCLUSTERIPは、通常のサービスとヘッドレスサービスのカテゴリに分けることができるかどうかに応じて：
- 通常のサービス：アクセスサービスの内部クラスタのKubernetesを割り当てることで固定虚拟IP、クラスタへのアクセスを実現するために、（クラスタIP）。これは、最も一般的な方法です。
- ヘッドレスサービス：サービスは、クラスタIPを割り当て、またリバースプロキシおよびロードバランシングKUBE-プロキシを行いません。しかし、直接podIPリストに解決されるアクセスバックエンドDNSのヘッドレスサービスにDNSにより、安定したネットワークIDを提供します。StatefulSetのための主な用途。
NodePort：からクラスタIPを使用するだけでなく、クラスタ内の各ノードの同じポート1つのポートにマッピングすることによって、サービスnodeIPによって実装,: nodePortに加えて集群外访问服サービス。
LoadBalancer：NodePort等が、クラスタIPとnodePort外部の使用に加えて、だけでなく、パブリッククラウドへのクラスタの外側から、（リアロードバランサnodePortがすべてのノードにマッピングされた）ロードバランサを適用するために使用され、アクセスLBによって達成されます。サービス。
ExternalName：サービスは特殊なケースです。このモードは、主に、サービスは、外部K8Sクラスタにマッピングされ、クラスタ内でサービスを提供する（例えば、名前空間属性を含む）K8S内の機能およびサービスの数を含むことができるを通じてクラスタの外部で実行サービスを、配向されています。このモードは、KUBE-DNSのバージョン1.7以上が必要です。このモデルと（ヘッドレスサービスを除く）前者3つのモードが最大の違いはむしろKUBEプロキシよりも、依存DNSリダイレクトレベルです。
例えば、値が「my.database.example.com」サービス定義externalNameで指定します：

DNSサービスで、このサービス名で、クラスタ内K8Sクラスタ化されます。 CNAMEレコードを作成.svc.cluster.local、「my.database.example.com」の値を指定します。
K8Sクラスタではmy-service.prod.svc.cluster.localを追跡すると、クラスタのDNSサービスは、CNAMEレコード「foo.bar.example.com」のマップを返します。

注：
最初の三つのモデル、サービスがポッドセレクタに対応する場合に、サービスを指定することによって定義されるが、バックエンドサービスとしてエンドポイントのアドレスポッドを作成し、エンドポイントコントローラメンテナンスエンドポイント情報を、対応する、サービスおよびポッドの変化を見ます。サービスとエンドポイントに従いKUBE-プロキシは、ローカルルーティングルールを維持します。エンドポイントの変更、即ちサービスポッドと関連付けられた変更は、各ノードに更新KUBEプロキシのiptablesは、層のロードバランシングを達成する場合。
モードセレクタを指定しないExternalName、該当するポートおよびエンドポイントが存在しません。
HeadlesサービスでExternalNameとCLUSTERIPは2例ヘッドレスサービスに属しています。ヘッドレスサービスは、主に割り当てないサービスIPを参照し、KUBE-プロキシ経由でリバースプロキシと負荷分散サービスを行いません。

1.2ポート

サービスは、主に3つのポートが含まれます* portポートは、ここCLUSTERIPポート上で公開されたサービスを表すclusterIP:Port 是提供给集群内部入り口アクセスkubernetesサービスを。

TARGETPORT
containerPort、TARGETPORTは、ポッドのポートであるポートからの着信データとnodePort KUBEプロキシTARGETPORTを容器にポッドの後端部に流れ、最終的に後。
nodePort
nodeIP：nodePortは、外部kubernetesクラスタサービスからのアクセスの入り口に提供されます。

全体として、元ポート及びnodePortすべてのサービスポートは、クラスタサービスの外部からのアクセスに露出しているクラスタサービス、内部からのアクセスにさらされます。これら二つのポートの着信データは、容器内にポッドを入力するために、特定のポッドの後端部に流入するリバースプロキシtargetPortのKUBEプロキシを通過する必要があります。

1.3 IP

使用Serviceサービスは、いくつかのIPが含まれます。

CLUSTERIP
ポッドIPアドレスは、このアドレスを運ぶないネットワークデバイス上で（仮想デバイスとすることができる）ネットワークカードに実際に存在しないが、CLUSTERIP同じではありません。それは、そのローカルポート、平衡-再びポッドをリダイレクトするためにKUBE-プロキシiptablesルールによって使用される、仮想アドレスです。KUBE-プロキシが新しいサービスを発見した場合、それは、ローカル・ノード上のランダムなポートを開き、新しいポートに適切なiptablesのルール、CLUSTERIPリダイレクトサービスおよびポートを作成し、サービス接続の到着を受け入れるようになりました。
ポッドIP
IPのポッド、各ポッドは、開始それは容器モデル鏡像gcr.io/google_containers/pause容器、内部ネットワークモードポッド他の容器の使用を作成し、コンテナIDポーズとして指定され、すなわち：network_mode ：「コンテナ：休止コンテナID」は、そう容器休止ポッド内のすべてのコンテナがネットワークを共有していることが、コンテナプロキシの外部と通信それを介して、IP休止容器はまた、ポッドIP呼ばれてもよいです。
ノードIP
ノード-IPは、サービスが内部アプリケーションとサービスのレベルは、非常に適切である場合にのみ、内部でアクセス可能なIPのプールに割り当てられた範囲のクラスタIP内のオブジェクト。クラスタ外の顧客にサービスを提供する準備ができて、フロントエンドサービスとしてこのサービス、場合、我々は、パブリックIPにこのサービスを提供する必要があります。指定spec.type = NodePortのサービス、サービスのこのタイプは、システムがそれをプロキシポートのクラスタ内の各ノード上のノード・レベルを割り当てます、代理ノードクライアントへのアクセスは、サービスへのアクセスには、このポートにアクセスすることができます。

K8S〜K8Sサービスサービス中

サービスサービス

1.1サービス

1.2ポート

1.3 IP

おすすめ