Service

概念と特徴

クバーネディス群集中では,流動性の高いパードに不変の端点を提供することがサービスの役割である.

サービスのIPとポート番号を直接変更しない限り、絶対に変更しません.

ポンドを生成すると、実際のプロシージャは生成されません.

サービスのIPは仮想IPアドレスであり、pingは飛べない.

サービスの仕組み

クバーネディス静的podにはkube-proxyがある.kube-proxyの役割は、自分が浮遊するノードに入るトラフィックを遮断し、適切な位置でリダイレクトするエージェントです.しかし、これはユーザー空間エージェントモードであり、現在の基本モードはパフォーマンスの良いiptablesエージェントモードである.userspaceエージェントは、ネットワークトラフィックに関連するほとんどの作業がuserspaceのkube-proxyで動作し、ネットワークパケットをユーザーに渡すと、ユーザー空間のパケットがkernel spaceを介してエージェントされるため、コストが高くなります.これに対して、iptablesモードではkernel spaceというnetfilterというモジュールを使用してkube-proxyの作業を完了するため、コストがずっと低くなります.
では、kube-proxyがサービスを作成する際にどのように機能しているかを見てみましょう.

APIサーバ上でサービスが作成されると、仮想IPアドレスがすぐに割り当てられます.

APIサーバは、すべてのkube-proxyに新しいサービスの生成を通知します.

kube-proxyは、ノード上でiptablesを変更して、サービスIPアドレスのパケットをブロックし、適切なパケットに送信する.

エンドポイントオブジェクトはサービス関連(pod IP、ポート)ペアを監視しているため、podが変化するとエンドポイントも変化し、kube-proxyはそれに気づき、iptablesを再修正します.
ここでは、iptablesとnetfilterの概念が混同される可能性があります.実際、カーネル空間のnetfilterはルールに基づいてパケットを処理します.iptablesはuserspaceにあり、netfilterにルールを追加するためのインタフェースです.
原理的に見ると、サービスの特徴の中で、なぜサービスIPでpingを送信できないのか.最終的に、サービスIPは、ネットワークインタフェースに割り当てられず、(サービスIP、ポート)ペアからなるだけである.

NodePort vs LoadBalancer vs Ingress

3つとも外部にサービスを暴露する方法です.しかし、明らかな違いがあり、用途も異なるので、理解したほうがいいです.

NodePort
すべてのノードで特定のポートを開き、外部からトラフィックを受信する方法.これにより、ユーザは、要求を노드 IP:NodePortアドレスに送信することができる.通常はon-premiseでサービスを暴露する際に多く使用される.

apiVersion: v1
kind: Service
metadata:
	name: nodeport
spec:
	type: NodePort
	ports:
	- port: 80
		targetPort: 8080
		nodePort: 30123
	selector:
		app: example

Load Balancer
これはNodePortの拡張バージョンで、gcpやawsなどのクラウドインフラストラクチャにのみ適用されます.基本的に、サービスはノードポートのように、各ノードには特定のポートが開いていますが、外部に露出している点はLoad Bangerが1つしかありません.したがって,ユーザがアクセスする場合,Load BanserのIPアドレスを用いて接続することができる.
しかし、Load Bankerは1つのサービスにしか適用できないため、複数のサービスを暴露するには、それに応じて複数のLoad Bankerを生成する必要があり、これにより多くのコストが発生する.

apiVersion: v1
kind: Service
metadata:
	name: loadbalancer
spec:
	type: LoadBalancer
	ports:
	- port: 80
		targetPort: 8080
	selector:
		app: example

Ingress
主に生産環境に露出する方法である.上のLoad Bangerとは違って、1つのIngressは複数のサービスを暴露することができます.欠点は使い方が複雑だということです.
まず、イングリスがサービスを暴露する方法を見てみましょう.Ingress要求はドメインとuriパス暴露サービスに基づいている.また、Ingressは常にIngressコントローラのように配置する必要があります.Ingressは複数のサービスを暴露する際のルールを定義するだけで,実際のトラフィックを処理するのはIngressコントローラである.

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
	name: example
spec:
	rules:
	- host: example.com
		http:
		paths:
		- path: /
			backend:
				service:
					name: example-service
					port:
						number: 80

ユーザは、要求をexample.comドメインに送信する.

DNSサーバは、example.comをIngressコントローラIP送信要求に変更する.

Ingressコントローラにリクエストすると、タイトルにexampleがあります.comを読み込んで送信します.

Ingressコントローラは,要求を受けたデータに基づいて,Ingress→サービス→エンドポイントを介して,実際に要求を受信する必要があるPARD IPを取得する.

得られたシードIPでIngressコントローラはトラフィックを送信する.
今回は複数のサービスを暴露する場合であり,複数のサービスを暴露すると,異なるドメイン名やuriパスに基づいて暴露する.次の図は、ドメイン名に基づいて複数のサービスを暴露する例です.

uriパスに露出すると、以下のようにIngressを定義できます.

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
	name: example
spec:
	rules:
	- host: example.com
		http:
		paths:
		- path: /foo
			backend:
				service:
					name: foo-example-service
					port:
						number: 80
		- path: /bar
			backend:
				service:
					name: bar-example-service
					port:
						number: 80

この場合、パスが同じ場合にprefixやpathTypeを設定するなど、異なる条件を設定することで、パスが同じ場合に割り当てる必要がなく、サービスを作成することができます.

Reference

[足の翻訳]KubernetesNodePortVS LoadBarancer VS Ingress?いつ何を書けばいいですか。