マスターすべき「Kubernetes」、Service、Ingress

[[404005]]

この記事はWeChatの公開アカウント「小蔡良基」から転載したもので、著者は蔡歩才です。この記事を転載する場合は、Xiaocailiangji公式アカウントまでご連絡ください。

NameSpace、Pod、PodControllerからVolumeまでk8sを導入しました。読んだ友人たちもきっと満足してくれると思います。ということで、今日も引き続き k8s クラスに進みます。このセクションでは、サービスを構築した後に k8S にアクセスする方法について説明します。

まず、Service と Ingress が何であるかを理解する必要があります。簡単に言えば、これら 2 つのコンポーネントはトラフィックを伝送するために使用されます。では、トラフィック負荷とは何でしょうか?クラスター内のポッドを通じてアプリケーション サービスをデプロイしたら、次に何をすればよいでしょうか?それは、ユーザーが当社のアプリケーション サービスにアクセスできるようにするためです。これが最も重要なことです。そうしないと、導入したとしてもユーザーがアクセスできない場合は役に立たなくなってしまいます。

1. サービス

k8s では、pod がアプリケーションのキャリアとなります。ポッドの IP を通じてアプリケーションにアクセスできますが、ポッドにはライフサイクルがあることはすでにわかっています。ポッドに問題が発生すると、ポッド コントローラーはポッドを破棄して再作成します。するとこの時点でポッドの IP が変更されるため、ポッド IP を使用してアプリケーションにアクセスする方法が直接渡されるようになります。この問題を解決するために、k8s では Service というリソース概念が導入されました。このリソースを通じて、複数のポッドを統合して、統一されたエントリ アドレスを提供できます。サービスのエントリアドレスにアクセスすることで、後続のポッドサービスにアクセスできます。

サービスはどこからともなく現れるものではありません。 Node ノード上の重要なコンポーネント kube-proxy をまだ覚えていますか?ここが重要なポイントです〜思い出すために古い写真を見てみましょう:

この写真は、以前のブログを読んだ人にはお馴染みのものでしょう。はい！ Kube-proxy はここで重要な役割を果たします。各ノード上で kube-proxy サービス プロセスが実行されます。サービスが作成されると、作成されたサービスの情報が api-server を通じて etc に書き込まれます。 Kube-proxy は監視メカニズムに基づいてこのサービスの変更を検出し、最新のサービス情報を対応するアクセス ルールに変換します。

この時点で、サービスの概要を理解し、少なくともその使用法を知っているはずです。次に、さらに詳しく見てみましょう。

1) 作業モード

kube-proxy は次の 3 つの動作モードをサポートしています。

1. ユーザースペース

このモードはより安定していますが、効率は低くなります。 userSpace モードでは、kube-proxy は各サービスに対してリスニング ポートを作成します。リクエストがクラスター IP に送信されると、Iptables ルールによって kube-proxy がリッスンするポートにリダイレクトされます。 kube-proxy はサービスを提供する Pod を選択し、LB アルゴリズムに基づいて接続を確立します。

このモードでは、kube-proxy はレイヤー 4 バランサーとして機能します。 kube-proxy は userSpace モードで実行されるため、転送時にカーネルとユーザー空間間のデータコピーが増加し、効率が比較的低くなります。

2.iptables の設定

iptables モードでは、kube-proxy はサービス バックエンドの各ポッドに対応する iptable ルールを作成し、クラスター IP に送信されたリクエストをポッド IP に直接リダイレクトします。このモードでは、kube-proxy はレイヤー 4 ロード バランサの役割を担わず、iptables ルールの作成のみを担当します。このモードの利点は、ユーザー空間モードよりも効率的ですが、柔軟な LB ポリシーを提供できないことです。バックエンド Pod が利用できない場合は再試行は行われません。

3. IPvs

このモードは iptables モードに似ています。 Kube-proxy はポッドの変更を監視し、対応する ipvs ルールを作成します。ただし、iptables と比較すると、ipvs ルールは転送効率が高く、より多くの LB アルゴリズムをサポートします。

練習する

上記では 3 つの動作モードについて学習しました。 ipvs の役割を簡単に試してみましょう。まず、リソースのリストを準備します。

このリストの前半は Pod コントローラーを作成するためのもので、後半はサービスを作成するためのものです。

次に、ipvsadm -Ln コマンドを入力して、ipvs ルール ポリシーを確認します。

10.108.230.12 は、サービスによって提供されるアクセス エントリです。このエントリにアクセスすると、呼び出しを待機しているポッド サービスが 3 つあることがわかります。 Kube-proxy は、rr (ラウンドロビン) 戦略に基づいて、リクエストをポッドの 1 つに配布します。このルールはクラスター内のすべてのノードで同時に生成されるため、どのノードからでもアクセスできます。

このモードではipvsカーネルモジュールがインストールされている必要があります。そうでない場合はiptablesに縮小されます。

ipvs を有効にする:

 kubectl edit cm kube-proxy -n kube-system

編集後に保存して終了する（:wq）

 kubectl delete pod -l k8s-app=kube-proxy -n kube-system 
 
 ipvsadm -Ln

2)サービスの利用

上記では、サービスのいくつかの動作モードを紹介しました。次に、サービスの使用フェーズに入ります。上記では、DeployとServiceを作成するという簡単な練習をしました。その後、serviceIp + targetPortまたはnodeIp + nodePortを介してリソースにアクセスできます。

ただし、サービスの使用方法を学ぶには、これだけでは十分ではありません。サービスは5つのタイプに分かれており、以下で一つずつ紹介していきます。

1. クラスターIP

まず、ClusterIP タイプのサービスのリソース リストを見てみましょう。

作成後にテストしてclusterIp + portにアクセスする

ipvs ルールをもう一度確認すると、サービスを対応する 3 つのポッドに転送できることがわかります。

次に、describe コマンドを使用してサービスの情報を表示します。

ざっと調べてみると、エンドポイントとセッションアフィニティは私たちにとって新しいものであることがわかりました。それで、これは何ですか？

終点

エンドポイントは、etcd に保存され、サービスに対応するすべての Pod のアクセス アドレスを記録するために使用される、k8s のリソース オブジェクトです。サービス構成ファイル内のセレクター記述に従って生成されます。サービスは、エンドポイントを通じて公開される一連のポッドで構成されます。エンドポイントは、実際にサービスを実装するポートの集合体であると言えます。簡単に言えば、エンドポイントはサービスとポッドの間の橋渡しです

それは資源なので、

負荷分散

上記のサービスを通じて Pod リソースへのアクセスを正常に実装したので、いくつか変更を加えて 3 つの Pod に入り、usr/share/nginx/index.html ファイルを編集してみましょう。

 #ポッド01
ポッド01: ip - 10.244.1.73
 #ポッド02
ポッド01: ip - 10.244.1.73
 #ポッド03
ポッド03: ip - 10.244.2.63

次に、curl 10.96.10.10:80 コマンドを使用して結果を再度表示してみます。

この負荷分散戦略がポーリングであることに気付きましたか?サービスへのアクセスに関して、k8s は次の 2 つの負荷分散戦略を提供します。

• 分散戦略が定義されていない場合は、ランダムやラウンドロビンなどの kube-proxy のデフォルトの戦略が使用されます。
• セッション永続モードはクライアント アドレスに基づいています。つまり、同じクライアントによって開始されたすべてのリクエストは、固定されたポッドに転送されます。ここでは、上で説明した sessionAffinity を使用する必要があります。

ipvsadm -Ln コマンドを使用して配布ポリシーを確認すると、rr フィールドがありました。気づきましたか？はい、この rr フィールドはラウンドロビンを意味します。

セッション永続性の分散戦略を有効にしたい場合は、仕様にsessionAffinity:ClientIPオプションを追加するだけです。

ipvsadm -Ln コマンドを使用して配布ポリシーを再度確認すると、結果が変更されていることがわかります。

簡単なテストをしてみましょう:

このようにして、セッション永続性の分散戦略が実装されました。

注: ClusterIp サービスは外部アクセスをサポートしていないため、ブラウザ経由でのアクセスは無効であり、クラスター内でのみアクセスできます。

2. 見出し

多くのサービスではカスタマイズをサポートする必要があります。製品がサービスとして位置付けられる場合、その製品が成功することは間違いありません。シナリオによっては、開発者はサービスによって提供される負荷分散機能を使用するのではなく、負荷分散戦略を自分で制御したい場合があります。このような状況に対応して、k8s も優れたサポートを提供し、HeadLines Service を導入しています。このタイプのサービスでは ClusterIp は割り当てられません。サービスにアクセスする場合は、サービス ドメイン名を通じてのみクエリを実行できます。

HeadLines リソース リスト テンプレートを見てみましょう。

ClusterIp との唯一の違いは、clusterIP: None 属性の変更です。

作成後、ClusterIP が割り当てられていないことがわかります。引き続きサービスの詳細を確認してみましょう。

詳細から、エンドポイントが有効になっていることがわかります。次に、任意のポッドに入り、ドメイン名の解決を確認します。

ドメイン名が解決されたことがわかります。デフォルトのドメイン名は、サービス名.namespace.svc.cluster.local です。

3. ノードポート

上記の 2 つのサービス タイプはクラスター内でのみアクセスできますが、サービスをデプロイするときには、ユーザーがクラスター外でもそれらを使用できるようにする必要があります。このとき、最初に作成したサービス タイプ、NodePort サービスを使用する必要があります。

このタイプのサービスの動作原理は難しくありません。実際には、サービスポートをノード上のポートにマッピングし、NodeIp+NodePortを介してアクセスします。

概略図を見ると、すべてが明らかになったように感じますか?それでは、リソース リストを通じてそれがどのように作成されるかを見てみましょう。

上記のリソース リストを使用してサービスを作成し、それにアクセスします。

どちらの方法もアクセス可能であることがわかります。ブラウザで試すこともできます:

この結果こそ私たちが望んでいたものです!

ユーザーのアクセスは成功したものの、ここで満足してはいけません～鉄は熱いうちに打って、残りの2つのタイプを理解し続けましょう～

4. ロードバランサー

名前が示すように、LoadBalancer は負荷分散に関連しています。このタイプは NodePort と非常によく似ており、ポートを外部に公開することを目的としています。主な違いは、LoadBalancer はクラスター外部のロード バランサーとして機能し、このデバイスは外部環境からのサポートを必要とすることです。外部環境からこのデバイスに送信されたリクエストは、デバイスによってロードされた後、クラスターに転送されます。

図にはVipの概念があります。ここでの Vip は Vitual IP、つまり仮想 IP を指します。外部ユーザーは、この仮想 IP にアクセスしてさまざまなサービスにアクセスし、負荷分散と高可用性を実現できます。

5. 外部名

ExternalName サービスは、クラスター外部にサービスを導入するために使用されます。 externalName 属性を通じて外部サービスのアドレスを指定し、クラスター内でこのサービスにアクセスすることで外部サービスにアクセスします。

リソースリスト:

作成後、ドメイン名の解決を確認し、正常に解決されたことを確認できます。

 dig @10.96.0.10 svc-externalname.cbuc-test.svc.cluster。地元 

2. イングレス

1) 作業モード

いくつかの種類のサービスの使用方法についてはすでに説明しました。外部ユーザーがポッド内のサービスにアクセスできるようにする場合、NodePort と LoadBalancer という 2 種類のサービスがサポートされていることはすでにわかっています。しかし、慎重に分析してみると、これら 2 つのサービスの欠点が簡単に見つかります。

NodePort: クラスター マシンの多くのポートを占有します。クラスター サービスの数が増えると、この欠点はより顕著になります。

LoadBalancer: 各サービスにLBが必要で、面倒でリソースを浪費し、k8s以外の負荷分散デバイスのサポートが必要

この欠点は、私たちだけで発見できるものではありません。 k8s の創始者として、私たちは長い間それを認識しており、その後 Ingress の概念を導入しました。 Ingress では、複数のサービスを公開するニーズを満たすために、1 つの NodePort または LB のみが必要です。

実際、Ingress は、K8s によるリバース プロキシの抽象化である 7 層ロード バランサに相当します。その動作原理は Nginx に似ています。これは、Ingress に多くの暗黙のルールを確立し、Ingress Controller がこれらの構成ルールをリッスンして Nginx リバース プロキシ構成に変換し、外部にサービスを提供すると理解できます。ここでは 2 つの重要な概念が関係しています。

• Ingress: リクエストをサービスに転送する方法のルールを定義する K8s のリソース オブジェクト。
• Ingress コントローラー: リバース プロキシと負荷分散を実装するプログラム。 Ingress によって定義されたルールを解析し、構成されたルールに従ってリクエストを転送します。 Nginx、Contor、Haproxy など、実装方法は多数あります。

Ingress コントローラーは、さまざまな方法でリクエスト転送を実装できます。通常は、より使い慣れている Nginx を負荷として選択します。次に、Nginx を例に、その動作原理を理解します。

• ユーザーは、各ドメイン名がK8sクラスタ内のどのサービスに対応するかを示すIngressサービスルールを記述します。
• Ingress コントローラーは、Ingress サービス ルールの変更を動的に検出し、対応する Nginx リバース プロキシ構成を生成します。
• Ingressコントローラは生成されたNginx構成を実行中のNginxサービスに書き込み、動的に更新します。
• 次に、クライアントがドメイン名にアクセスし、Nginx が実際にリクエストを特定の Pod に転送して、リクエスト プロセス全体を完了します。

動作原理を理解したので、それを実装してみましょう。

2) イングレスの使用

1. 環境構築

Ingressを使用する前に、Ingress環境を構築する必要があります。

ステップ1:

 # 必要なリソースのリストを取得します
wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.30.0/deploy/静的/mandatory.yaml 
 
 https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.30.0/deploy/静的/provider/baremetal/service-nodeport.yamlを取得します。

ステップ2:

 # リソースを作成する
kubectl を適用 -f ./

ステップ3:

リソースが正常に作成されたかどうかを確認する

ここまででIngress環境の準備は整いましたので、次はテスト段階に入ります〜

2つのサービスと2つのデプロイメントを準備し、6つのレプリカポッドを作成しました。

これらのリソースをまだ準備していない場合は、戻って宿題をする必要があります〜

一般的な構造図は次のとおりです。

次に、次の結果を達成するためにIngressを準備します。

Ingress のリソース リストを準備します。

 apiバージョン: extensions/v1beta1
種類: イングレス
メタデータ:
名前: ingress-htpp
  名前空間: cbuc-test
仕様:
  ルール:
  - ホスト: dev.cbuc.cn
    http:
      パス:
      - パス：​​ /
        バックエンド:
          サービス名: svc-nodeport-dev
          サービスポート: 80
  - ホスト: pro.cbuc.cn
    http:
      パス:
      - パス：​​ /
        バックエンド:
          サービス名: svc-nodeport-pro
          サービスポート: 80

作成後、コンピュータのローカル ホストにドメイン名のマッピングも追加する必要があります。

その後、ドメイン名+nodePortを介してWebページにアクセスできるようになります。

この時点で、Ingress アクセス メソッドが実装されました。