Service

サービスとは,Podをネットワークサービスに暴露し,外部からPodに要求を送信できるようにするオブジェクトである.
このサービスの代わりにPodのIPアドレスを使用することが考えられるが、この方法は、動作段階において非常に非効率であり、管理されない.

Podは常に削除され、再実行されます.

すなわち、IPアドレスは随時変更可能である.

PodのIPアドレスは、ノード上でPodが予め定められた後に割り当てられる.

が再起動したPodのIPアドレスを正確に知ることができません.

負荷バランシングをサポートする必要があります.
ほとんどのサービス呼び出しと同じクライアントは、単一のエンドポイントを呼び出す必要があります.

これらの理由から、Kubernetesはサービスというオブジェクトを提供しています.
このサービスオブジェクトは、外部に露出したIPに割り当てられ、このIP送信要求によって同じサービスによって管理されるPodに要求が割り当てられる.
(サービス管理の意味はlabelセレクタに指定されたpodです.)
サービスメンテナンス中に作成されたIPアドレスは変更されません.

apiVersion: v1
kind: Service
metadata:
  name: kubia
spec:
  ports:
  - port: 80			-- service가 사용할 port
    targetPort: 8080		-- service가 request를 forward할 pod의 port
 selector:
   app: kubia

sessionAffinity
特定のクライアントのすべてのリクエストを同じpodに転送するためのプロパティ.sessionAffinity: ClusterIPとして指定されると、同じクライアントのリクエストが同じpodに渡されます.
クライアントがどのように負荷を分散しても、sessionAffinity: Noneプロパティを使用する必要があります.
session Affinityのプロパティから、クッキーに基づいてルーティングできるかどうかはわかりますが、サービスオブジェクトはHTTPレベルで実行されるオブジェクトではないため、クッキーはサポートされていません.実際のサービスは、TCP、UDPのパケットのみを転送し、負荷、ファーストクラスに関心を持たない.

サービスはどのようにPodのIPアドレスを知っていますか?

サービスのIPは変更されませんが、PodのIPアドレスはいつでも変更される可能性があります.
では、サービスはどのようにして要求を送信するPodのIPアドレスを確定しますか?
Podが実行されると、kubernetesは環境変数を初期化し、この時点で存在する各サービスを示す.
サービスは、この環境変数を参照してpodのIPを取得します.

DNS

kubernetesのDNSサービスを実行すると、クラスタ内で実行されるすべてのpodがDNSサーバを自動的に有効にします.
podでDNSサービスを使用する場合、まずkubernetes内部DNSを使用するので、クラスタ内部でもDNSを使用することができる.

FQDN

クラスタ内で使用可能なDNS.
ドメインのパターンは<serviceName>.<namespace>.svc.cluster.localの形式である.svc.cluster.localはcluterローカルサービスの接尾辞です.

サービスを外部に露出

サービスオブジェクトとEndpointオブジェクトを構成することで、外部からアクセスできるエンドポイントを作成できます.

apiVersion: v1
kind: Endpoints
metadata:
  name: external-service	-- service의 이름과 동일해야한다.
subsets:
  - addresses:
    - ip: 11.11.11.11		-- 서비스에 연결될 IP의 항목
    - ip: 22.22.22.22		-- 서비스에 연결될 IP의 항목
  ports:
  - port: 80

エンドポイントオブジェクトを構成すると、外部で共通IPにドメインを設定し、kubernetes接続を使用できます.
サービスがIPアドレスではなくFQDNを使用する場合、クラスタのDNSを使用してマッピングすることができる.

spec:
  type: ExternalName
  externalName: <FQDN>
  ports:
  - port: 80

ServiceType

外部からアクセス可能なサービスを構成する方法は3つあります.

ClusterIP

クラスタ-内部IPにサービスを暴露し、cluter内部からのアクセスのみを許可します.

NodePort

各ノードからポートを開き、そのポートに送信されたリクエストを各サービスに送信する方法.

LoadBalancer

クラウド環境で使用する方法により、クラウドが提供するloadイコライザをサービスとしてアクセスできます.このとき、NodePortと同様に、LoadBarangerからのリクエストがノードのPortに送信される.クラウド環境で提供されるKubernetes(EKS,AKS)は、サービスオブジェクトの作成時にloadイコライザを自動的に作成してマッピングします.

Ingress

HTTPレベルでの動作対象.Ingressの重要な点は、1つのパブリックIPだけですべてのリクエストを受信して転送できることです.loadイコライザを使用する場合は、各エンドポイントに共通IPを割り当てる必要があります.リクエストをどのサービスに転送するかを判断するためにhostとpathを解析する共通IPが割り当てられる.このインポートがHTTPSをサポートするためには、TLS証明書をクラスタ内に格納するだけでよい.

ExternalName

CNAMEレコードを返し、サービスをexternalNameフィールドにマッピングします.

readiness probe

サービスはいつpodでリクエストを転送できますか?podがまだ完全に動作していない限り、リクエストを転送することはできません.これを防止する概念はreadiness probeである.
すなわち、コンテナがリクエストを処理する準備ができているかどうか、またはリクエストのエンドポイントを処理し続けることができるかどうかがわかります.レディプローブは、アクティブプローブと同様にTCP、HTTP、スクリプトEXECをサポートします.
準備プローブに失敗すると、podのリストがサービスから削除され、リクエストの転送が回避されます.