クラウドネイティブテクノロジーのオープンクラススタディノート：K8sネットワークの概念とポリシー制御、Kubernetesサービス

10.Kubernetesネットワークの概念とポリシー制御

1.Kubernetesの基本的なネットワークモデル

コンテナネットワーク開発の複雑さは、実際にはホストネットワークに寄生しているためです。この観点から、コンテナネットワークソリューションは大きく2つの派閥に分けることができます。アンダーレイ/オーバーレイ：

• アンダーレイの標準は、ホストネットワークと同じレイヤーにあることです。外部から見える機能は、ホストネットワークの同じネットワークセグメント、入出力基本機器、およびコンテナのIPアドレスを使用するかどうかです。ホストネットワークと協力しますか？（同じ中央ディストリビューションまたは統合部門から）。これはアンダーレイです
• オーバーレイの違いは、ホストネットワークのIPM管理コンポーネントからIPを申請する必要がないことです。一般的に、ホストネットワークと競合する必要はなく、このIPは自由に割り当てることができます。

2.Netnsの探索

ネットワーク名前空間でのネットワーク実装のカーネル基盤。狭義には、runCコンテナテクノロジーはハードウェアに依存せず、実行の基礎はカーネルです。プロセスを代表するカーネルはタスクです。分離が必要ない場合は、ホストスペース（名前空間）を使用します。スペース分離データ特別に設定する必要のある構造（nsproxy-名前空間プロキシ）

逆に、独立したネットワークプロキシ、またはマウントプロキシの場合は、実際のプライベートデータを入力する必要があります。表示されるデータ構造は上の図に示されています

感覚的な観点から、分離されたネットワークスペースには独自のネットワークカードまたはネットワーク機器があります。ネットワークカードは仮想でも物理でもかまいません。独自のIPアドレス、IPテーブルとルーティングテーブル、および独自のプロトコルスタック状態があります。これは特に、独自のステータスを持つTCP / Ipプロトコルスタックと独自のiptablesipvsを指します。

全体的な意味から、これは、ホストネットワークから分離された完全に独立したネットワークを持つことと同等です。もちろん、プロトコルスタックのコードはまだ公開されていますが、データ構造は異なります

上の図は、ポッド内のネットの関係を明確に示しています。各ポッドには独立したネットワークスペースがあり、ポッドネットコンテナはこのネットワークスペースを共有します。通常、K8sはループバックインターフェースを使用してポッドネットコンテナ間で通信することを推奨しており、すべてのコンテナはポッドのIPを介して外部サービスを提供します。さらに、ホスト上のルートネットは、そのPidが1であることを除いて、特別なネットワークスペースと見なすことができます。

3.主流のネットワークソリューションの紹介

フランネルスキームは現在最も一般的に使用されています。上の図に示すように、典型的なコンテナネットワークソリューションを見ることができます。最初に解決する必要があるのは、コンテナパッケージがホストに到達する方法です。これが、ブリッジを追加する方法です。そのバックエンドは実際には独立しています。つまり、パッケージがホストを離れる方法、どのカプセル化方法が使用されるか、またはカプセル化を必要としないかは、すべてオプションです。

それでは、3つの主要なバックエンドを紹介しましょう。

• 1つはユーザーモードのudpで、これは最も初期の実装です。
• 次に、カーネルのVxlanがあり、どちらもオーバーレイソリューションと見なされます。Vxlanのパフォーマンスは向上しますが、カーネルのバージョンに対する要件があり、カーネルはVxlanの特性をサポートする必要があります。
• クラスターが十分に大きくなく、同じ第2層ドメインにある場合は、host-gwを使用することもできます。この方法のバックエンドは、基本的にブロードキャストルーティングルールによって開始され、パフォーマンスは比較的高くなります。

4.ネットワークポリシーの有用性

Kubernetesネットワークの基本モデルでは、ポッド間の完全な相互接続が必要であると述べました。これにより、いくつかの問題が発生します。K8sクラスターでは、一部のコールチェーンが直接呼び出されません。たとえば、2つの部門間では、部門Aが部門Bのサービスを訪問しないことを望んでいます。現時点では、戦略の概念を使用できます。

基本的に、そのアイデアは次のとおりです。さまざまなセレクター（タグまたは名前空間）を使用してポッドのグループを検索するか、通信の両端を検索し、ストリームの機能の説明を使用して、ポッドを接続できるかどうかを判断します。、ホワイトリストメカニズムとして理解できます

ネットワークポリシーを使用する前に、上図に示すように、apiserverがこれらのスイッチをオンにする必要があることに注意してください。もう1つの重要なことは、選択したネットワークプラグインがネットワークポリシーの実装をサポートする必要があるということです。ネットワークポリシーはK8sが提供するオブジェクトであり、実装用の組み込みコンポーネントはありません。選択したコンテナネットワークソリューションがこの標準とその完全性をサポートしているかどうかによって異なります。Flannelなどを選択した場合、実際にはサポートされません。このポリシーが実装されている場合、これを試してみても意味がありません

次に、構成の例、またはネットワークポリシーを設計するときに何をするかについて説明しましょう。

• 最初に行うことは、このインスタンスのスペックパーツと同様に、オブジェクトを制御することです。仕様では、podSelectorまたは名前空間セレクターを介して、特定のポッドのセットを作成して、コントロールを受け入れるように選択できます。
• 2つ目は、流れの方向を明確に考えることです。流入方向と流出方向を制御する必要がありますか？まだ両方向に制御する必要があります
• 最も重要な部分は3番目の部分です。選択した方向にコントロールオブジェクトを追加してそのフローを説明する場合、どのストリームを出し入れできますか？このストリーム機能の5タプルと同様に、いくつかのセレクターを使用して、リモートにすることができるセレクターを決定できます。これがオブジェクトの選択です。IPBlockのメカニズムを使用して、解放できるIPを取得することもできます。最後は、どのプロトコルまたはどのポートです。実際、フロー特性の組み合わせは5タプルであり、特定の許容可能なフローを選択します。

11.Kubernetesサービス

1.需要の源

1）サービスディスカバリが必要な理由

K8sクラスターでは、アプリケーションはポッドを介してデプロイされます。従来のアプリケーションデプロイメントとは異なり、従来のアプリケーションは特定のマシンにデプロイされます。他のマシンのIPアドレスを呼び出す方法を知っています。ただし、K8sクラスター内のアプリケーションはポッドを介してデプロイされ、ポッドのライフサイクルは短命です。ポッドの作成や破棄などのライフサイクル中に、そのIPアドレスが変更されるため、従来の展開方法を使用できず、指定したアプリケーションにアクセスするためにIPを指定できません。

また、K8sのアプリケーション展開では、以前に展開モードを学びましたが、ポッドグループを作成する必要があり、これらのポッドグループは統合アクセスエントリとトラフィック負荷分散の制御方法を提供する必要があります。このグループに。たとえば、テスト環境、プレリリース環境、およびオンライン環境では、展開プロセス中に同じ展開テンプレートとアクセス方法を維持する必要があります。このようにして、同じアプリケーションテンプレートのセットを使用して、異なる環境で直接公開できるためです。

最後に、アプリケーションサービスは、アクセスするために外部に公開する必要があり、呼び出すために外部ユーザーに提供する必要があります。ポッドのネットワークとマシンはネットワークの同じセグメントにないので、ポッドネットワークを外部アクセスに公開するにはどうすればよいですか？サービスディスカバリ

2）サービス：Kubernetesでのサービス検出と負荷分散

K8sでは、サービス検出と負荷分散はK8sサービスです。上の図は、K8sのサービス構造です。K8sサービスは、外部ネットワークとポッドネットワークへのアクセスを提供します。つまり、外部ネットワークはサービスを介してアクセスでき、ポッドネットワークもK8sサービスを介してアクセスできます。

下向きに、K8sは別のポッドのセットに接続されます。つまり、K8sサービスを介してポッドのセットに負荷分散できます。K8sサービスは、サービス検出用の統合アクセスポータルを提供するだけでなく、外部ネットワークへのアクセスも提供します。アクセス異なるポッド間で、統一されたアクセスアドレスを提供します

2.ユースケースの解釈

1）、サービス構文

まず、K8sサービスの文法を見てください。上の図は、実際にはK8sのステートメント構造です。この構造には多くの構文があり、以前に紹介したK8の標準オブジェクトのいくつかと多くの類似点があります。たとえば、いくつかの選択を行うためのセレクター、いくつかのラベルラベルを宣言するためのラベルなど。

ここには、K8sサービスサービス検出用のプロトコルとポートを定義するという新しい知識ポイントがあります。このテンプレートを引き続き確認し、my-serviceという名前のK8sサービスを宣言します。app:my-serviceラベルがあり、app:MyAppバックエンドとしてそのようなラベルポッドを選択します。

最後は、定義されたサービス検出プロトコルとポートです。この例では、TCPプロトコルが定義されています。ポートは80で、宛先ポートは9376です。その結果、サービスポート80へのアクセスはバックエンドにルーティングされます。 targetPort、つまり、このサービスにアクセスしている限り、ポート80はバックエンドapp:MyAppラベルポッドのポート9376に負荷分散されます。

2）、サービスを作成して表示します

サービスの作成：kubectl apply -f service.yamlまたはkubectl created -f service.yaml

サービス作成後の結果を表示します。kubectl discribe service

サービスが作成されると、その名前がmy-serviceであることがわかります。名前空間、ラベル、セレクターは以前の宣言と同じです。宣言後、IPアドレスが生成されます。このIPアドレスはサービスのIPアドレスです。このIPアドレスは、クラスター内の他のポッドからアクセスできます。これを渡すことと同等ですIPアドレスは、ポッドとサービス検出への統合アクセスを提供します

エンドポイントのプロパティもあります。これは、エンドポイントから確認できます。以前に宣言されたセレクターで選択されたポッドはどれですか。そして、これらのポッドの状態はどうですか？たとえば、セレクターを介して、これらのポッドのIPと、これらのポッドによって宣言されたtargetPortのポートが選択されていることがわかります。

実際のアーキテクチャを上の図に示します。サービスが作成されると、クラスター内に仮想IPアドレスとポートが作成されます。クラスター内では、すべてのポッドとノードがそのようなIPアドレスとポートを介してサービスにアクセスできます。このサービスは、選択したポッドとそのIPアドレスをバックエンドにマウントします。このようにして、サービスのIPアドレスを介してアクセスするときに、これらのバックエンドポッドに負荷分散することができます。

ポッドのライフサイクルが変更された場合、たとえば、ポッドの1つが破壊された場合、サービスはポッドをバックエンドから自動的に削除します。これが達成されます。ポッドのライフサイクルが変更されても、アクセスするエンドポイントは変更されません。

3）クラスター内のサービスへのアクセス

クラスター内で、他のポッドは作成したサービスにどのようにアクセスしますか？3つの方法があります：

• まず、仮想IPサービスアクセスを通過できます。たとえば、作成したばかりのmy-serviceこのサービスを通過するkubectl get svcかkubectl discribe service、仮想IPアドレスが172.29.3.27、ポートが80であることがわかります。次に、この仮想IPを使用してポートポッドでこのサービスのアドレスに直接アクセスします

• 2番目の方法は、DNS解決に依存して、サービス名に直接アクセスすることです。つまり、同じ名前空間内のポッドは、サービス名で宣言されたばかりのサービスに直接アクセスできます。さまざまな名前.空間で、サービスの名前を追加してから、サービスにアクセスするためにサービスが配置されている名前空間を追加できます。たとえば、curlを使用してサービスに直接アクセスします。つまり、my-service：80はサービス。

• 3つ目は、環境変数を介してアクセスすることです。同じ名前空間のポッドが開始されると、K8は、環境変数を介して、いくつかのIPアドレス、ポート、およびサービスのいくつかの単純な構成をK8のポッドに配置します。K8sポッドコンテナの起動後、システムの環境変数を読み取ることで、名前空間内の他のサービスによって設定されたアドレスやそのポート番号などを読み取ることができます。たとえば、クラスター内のポッドでは、curl $を介して環境変数の値を直接取得できます。たとえば、MY_SERVICE_SERVICE_HOSTはそのIPアドレス、MY_SERVICEは先ほど宣言したMY_SERVICE、SERVICE_PORTはそのポート番号です。クラスタ内のサービスMY_SERVICEをリクエストできます

4）、ヘッドレスサービス

特別なサービス形態はヘッドレスサービスです。サービスの作成時に、clusterIP：Noneを指定して、clusterIPが不要であることをK8に通知すると、K8は仮想IPアドレスをサービスに割り当てません。仮想IPなしで負荷分散と統合アクセスを実現するにはどうすればよいですか。住所？

ポッドは、DNSを使用してservice_nameを介してすべてのバックエンドポッドのIPアドレスを直接解決し、DNSのAレコードを介してすべてのバックエンドポッドのアドレスに解決できます。クライアントはバックエンドIPアドレスを選択し、このAレコードはポッドのライフサイクルが変わると、返されるAレコードリストも変わります。これには、クライアントアプリケーションがAレコードからAレコードリストのIPアドレスにすべてのDNSを返す必要があり、クライアントは適切なアドレスを選択します。ポッドにアクセスしてください

5）、クラスターの外部にサービスを公開する

前の紹介では、クラスター内のノードまたはポッドがサービスにアクセスしますが、サービスを外部に公開するにはどうすればよいですか？アクセスのためにアプリケーションをパブリックネットワークに実際に公開するにはどうすればよいですか？この問題を解決するためのサービスには、NodePortとLoadBalancerの2種類もあります。

• NodePortの方法は、クラスターのノード上のノード（つまり、クラスターのノードのホスト）のポートを公開することです。これは、ノードのポートでアクセスされた後の転送レイヤーに相当します。 、および上記の仮想IPアドレスへの転送は、ホスト上のサービスの仮想IPアドレスです。

• LoadBalancerタイプは、NodePortの変換のもう1つのレイヤーです。今述べたNodePortは、実際にはクラスター内の各ノードのポートです。LoadBalancerは、すべてのノードの前にロードバランサーを追加することです。たとえば、Slibaba CloudにSLBをハングアップすると、ロードバランサーは統合された入り口を提供し、各クラスターノードのノードポッドにアクセスするすべてのトラフィックの負荷を分散します。次に、ノードポッドがClusterIPに変換され、実際のポッドにアクセスします。

3.操作のデモンストレーション

1）クラスター内のサービスへのアクセス

service.yaml：

apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    run: nginx
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    run: nginx    

server.yaml：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  labels:
    run: nginx
spec:
  replicas: 2
  selector:
   matchLabels:
    run: nginx
  template:
    metadata:
      labels:
        run: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9

hanxiantaodeMBP:yamls hanxiantao$ kubectl create -f server.yaml 
deployment.apps/nginx created
hanxiantaodeMBP:yamls hanxiantao$ kubectl get pod
NAME                     READY   STATUS    RESTARTS   AGE
nginx-79699b7df9-jn5p4   1/1     Running   0          46s
nginx-79699b7df9-th5hj   1/1     Running   0          46s
hanxiantaodeMBP:yamls hanxiantao$ kubectl get pod -o wide -l run=nginx
NAME                     READY   STATUS    RESTARTS   AGE   IP           NODE             NOMINATED NODE   READINESS GATES
nginx-79699b7df9-jn5p4   1/1     Running   0          77s   10.1.0.139   docker-desktop   <none>           <none>
nginx-79699b7df9-th5hj   1/1     Running   0          77s   10.1.0.140   docker-desktop   <none>           <none>

最初にポッドのセットを作成するには、このK8sデプロイメントを作成します。デプロイメントが作成されたら、ポッドが作成されているかどうかを確認しましょう。kubectl get pod -owideを介してIPアドレスを確認できます。-l、つまりラベル、run = nginxでフィルタリングします。これらの2つのポッドはそれぞれIPアドレス10.1.0.139と10.1.0.140であり、どちらにもrun = nginxというラベルが付いています。

hanxiantaodeMBP:yamls hanxiantao$ kubectl create -f service.yaml 
service/nginx created
hanxiantaodeMBP:yamls hanxiantao$ kubectl describe svc
Name:              kubernetes
Namespace:         default
Labels:            component=apiserver
                   provider=kubernetes
Annotations:       <none>
Selector:          <none>
Type:              ClusterIP
IP:                10.96.0.1
Port:              https  443/TCP
TargetPort:        6443/TCP
Endpoints:         192.168.65.3:6443
Session Affinity:  None
Events:            <none>


Name:              nginx
Namespace:         default
Labels:            run=nginx
Annotations:       <none>
Selector:          run=nginx
Type:              ClusterIP
IP:                10.108.96.80
Port:              <unset>  80/TCP
TargetPort:        80/TCP
Endpoints:         10.1.0.139:80,10.1.0.140:80
Session Affinity:  None
Events:            <none>

もう一度K8sサービスを作成しましょう。このサービスの実際のステータスは、kubectl describesvcで確認できます。作成されたnginxサービスの場合、そのセレクターはrun = nginxであり、バックエンドへのポッドアドレスはrun = nginxのセレクターを介して選択されます。これは、先ほど見た2つのポッドのアドレスです：10.1.0.139と10.1.0.140。ここで、K8sがクラスター内に仮想IPアドレスを生成したことがわかります。この仮想IPアドレスを介して、次の2つのポッドに負荷分散できます。

pod1.yaml：

apiVersion: v1
kind: Pod
metadata:
  name: nginx1
  namespace: default
  labels:
    env: dev
    tie: front  
spec:
  containers:
  - name : nginx
    image: nginx:1.8
    ports:
    - containerPort: 80      

クライアントポッドを作成して、サービスへのアクセス方法をテストします

hanxiantaodeMBP:yamls hanxiantao$ kubectl create -f pod1.yaml 
pod/nginx1 created
hanxiantaodeMBP:yamls hanxiantao$ kubectl get pod
NAME                     READY   STATUS    RESTARTS   AGE
nginx-79699b7df9-jn5p4   1/1     Running   0          10m
nginx-79699b7df9-th5hj   1/1     Running   0          10m
nginx1                   1/1     Running   0          39s

kubectl exec -it nginx1 shを使用してこのポッドに入り、curlをインストールします

先追加163ソース
ティー/etc/apt/sources.list << EOF
deb http://mirrors.163.com/debian/ jessie main non-ffree contrib
deb http://mirrirs.163.com/dobian/ jessie-主な非無料投稿
EOFを更新します

hanxiantaodeMBP:yamls hanxiantao$ kubectl exec -it nginx1 sh
# apt-get update && apt-get install -y curl

ClusterIPを介したアクセス

# curl http://10.108.96.80:80
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

{サービス名}。{名前空間}経由でアクセス

# curl http://nginx     
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

サービス名によるアクセス

# curl http://nginx.default
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

環境変数を介したアクセス

# env
KUBERNETES_PORT=tcp://10.96.0.1:443
KUBERNETES_SERVICE_PORT=443
HOSTNAME=nginx1
HOME=/root
NGINX_PORT_80_TCP=tcp://10.108.96.80:80
TERM=xterm
KUBERNETES_PORT_443_TCP_ADDR=10.96.0.1
NGINX_VERSION=1.8.1-1~jessie
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
NGINX_SERVICE_HOST=10.108.96.80
KUBERNETES_PORT_443_TCP_PORT=443
KUBERNETES_PORT_443_TCP_PROTO=tcp
NGINX_SERVICE_PORT=80
NGINX_PORT=tcp://10.108.96.80:80
KUBERNETES_SERVICE_PORT_HTTPS=443
KUBERNETES_PORT_443_TCP=tcp://10.96.0.1:443
KUBERNETES_SERVICE_HOST=10.96.0.1
PWD=/
NGINX_PORT_80_TCP_ADDR=10.108.96.80
NGINX_PORT_80_TCP_PORT=80
NGINX_PORT_80_TCP_PROTO=tcp
# curl $NGINX_SERVICE_HOST
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

2）サービスをクラスターの外部に公開する

service.yaml addtype: LoadBalancer

apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    run: nginx
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    run: nginx
  type: LoadBalancer  

hanxiantaodeMBP:yamls hanxiantao$ kubectl apply -f service.yaml 
Warning: kubectl apply should be used on resource created by either kubectl create --save-config or kubectl apply
service/nginx configured
hanxiantaodeMBP:yamls hanxiantao$ kubectl get svc -o wide
NAME         TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE   SELECTOR
kubernetes   ClusterIP      10.96.0.1      <none>        443/TCP        29d   <none>
nginx        LoadBalancer   10.108.96.80   localhost     80:31943/TCP   29m   run=nginx

ここには追加のEXTERNAL-IPがあり、http：// localhost /からサービスにアクセスできます。

3）サービスアクセスアドレスはポッドのライフサイクルとは関係ありません

hanxiantaodeMBP:yamls hanxiantao$ kubectl describe svc nginx
Name:                     nginx
Namespace:                default
Labels:                   run=nginx
Annotations:              <none>
Selector:                 run=nginx
Type:                     LoadBalancer
IP:                       10.108.96.80
LoadBalancer Ingress:     localhost
Port:                     <unset>  80/TCP
TargetPort:               80/TCP
NodePort:                 <unset>  31943/TCP
Endpoints:                10.1.0.139:80,10.1.0.140:80
Session Affinity:         None
External Traffic Policy:  Cluster
Events:
  Type    Reason  Age    From                Message
  ----    ------  ----   ----                -------
  Normal  Type    4m49s  service-controller  ClusterIP -> LoadBalancer

現在、サービスマッピングのバックエンドIPアドレスは10.1.0.139と10.1.0.140です。

hanxiantaodeMBP:yamls hanxiantao$ kubectl get pod
NAME                     READY   STATUS    RESTARTS   AGE
nginx-79699b7df9-jn5p4   1/1     Running   0          35m
nginx-79699b7df9-th5hj   1/1     Running   0          35m
nginx1                   1/1     Running   0          25m
hanxiantaodeMBP:yamls hanxiantao$ kubectl delete pod nginx-79699b7df9-jn5p4
pod "nginx-79699b7df9-jn5p4" deleted
hanxiantaodeMBP:yamls hanxiantao$ kubectl get pod -o wide
NAME                     READY   STATUS    RESTARTS   AGE   IP           NODE             NOMINATED NODE   READINESS GATES
nginx-79699b7df9-bb95z   1/1     Running   0          37s   10.1.0.142   docker-desktop   <none>           <none>
nginx-79699b7df9-th5hj   1/1     Running   0          36m   10.1.0.140   docker-desktop   <none>           <none>
nginx1                   1/1     Running   0          26m   10.1.0.141   docker-desktop   <none>           <none>
hanxiantaodeMBP:yamls hanxiantao$ kubectl describe svc nginx
Name:                     nginx
Namespace:                default
Labels:                   run=nginx
Annotations:              <none>
Selector:                 run=nginx
Type:                     LoadBalancer
IP:                       10.108.96.80
LoadBalancer Ingress:     localhost
Port:                     <unset>  80/TCP
TargetPort:               80/TCP
NodePort:                 <unset>  31943/TCP
Endpoints:                10.1.0.140:80,10.1.0.142:80
Session Affinity:         None
External Traffic Policy:  Cluster
Events:
  Type    Reason  Age   From                Message
  ----    ------  ----  ----                -------
  Normal  Type    6m2s  service-controller  ClusterIP -> LoadBalancer

ポッドの1つを削除すると、ポッドのIPアドレスは10.1.0.140と10.1.0.142になり、サービスマッピングのバックエンドIPアドレスも10.1.0.140と10.1.0.142になります。

4.アーキテクチャ設計

上の図に示すように、K8sサービスディスカバリとK8sサービスはそのような全体的なアーキテクチャです

K8sは、マスターノードとワーカーノードに分けられます。

• マスターの主なコンテンツはK8sコントロールです
• ワーカーノードは、ユーザーアプリケーションが実際に実行される場所です

K8sマスターノードにはAPIServerがあり、すべてのK8sオブジェクトを一律に管理します。すべてのコンポーネントはAPIServerに登録され、このオブジェクトの変更を監視します。たとえば、コンポーネントポッドのライフサイクルの変更は次のとおりです。イベント

3つの主要なコンポーネントがあります。

• 1つはCloudController Managerで、外部アクセス用にLoadBalancerのロードバランサーを構成します。
• もう1つはCorednsで、Corednsを使用してAPIServerのサービスバックエンドポッドの変更を監視し、サービスのDNS解決を構成して、サービスの仮想IPにサービスの名前またはヘッドレスから直接アクセスできるようにします。サービスの種類。IPリストの分析
• 次に、各ノードにkube-proxyコンポーネントがあり、サービスとポッドの変更を監視し、実際にクラスター内のノードポッドまたは仮想IPアドレスへのアクセスを構成します。

実際のアクセスリンクは何ですか？たとえば、クラスター内のクライアントPod3からサービスにアクセスすることは、今示した効果と似ています。クライアントPod3は最初にCorednsを介してServiceIPを解決します。CorednsはServiceNameに対応するサービスIPを返します。このクライアントPod3はこのサービスIPを使用してリクエストを行います。リクエストがホストのネットワークに到達すると、iptablesまたはIPVSになります。 kube-proxyによって構成されたものは、インターセプト処理のレイヤーを実行してから、実際の各バックエンドポッドに負荷分散することで、負荷分散とサービス検出を実現します。

たとえば、外部トラフィックの場合、現在パブリックネットワークを介してアクセスされたリクエスト。外部ロードバランサーのCloudController Managerを使用してサービスの変更を監視し、ロードバランサーを構成してから、ノード上のNodePortに転送します。NodePortもkube-proxyによって構成されます。IptablesはNodePortトラフィックをClusterIPに変換してから、負荷分散とサービス検出のために、バックエンドのポッドのIPアドレスに入力します。これは、K8sサービスディスカバリ全体とK8sサービスの全体的な構造です。

コースアドレス：https：//edu.aliyun.com/roadmap/cloudnative？spm = 5176.11399608.aliyun-edu-index-014.4.dc2c4679O3eIId＃suit