Linkerd と Ingress-Nginx の組み合わせとサービスへのアクセス制限

Linkerd と Ingress-Nginx の組み合わせとサービスへのアクセス制限

簡潔にするために、Linkerd 自体は組み込みの Ingress コントローラーを提供していません。 Linkerd は、既存の Kubernetes Ingress ソリューションと併用できるように設計されています。

Linkerd を Ingress ソリューションに統合するには、次の 2 つが必要です。

  • Linkerd をサポートするように Ingress を構成します。
  • Ingress コントローラーをメッシュ化して、Linkerd プロキシがインストールされるようにします。

Ingress コントローラをメッシュ化することで、トラフィックがクラスターに入るときに、Linkerd は L7 メトリックや mTLS などの機能を提供できるようになります。 Linkerd は、以下を含むほとんどの Ingress コントローラーとの統合をサポートしています。

  • 大使
  • エンギンクス
  • トラエフィク
  • トラエフィック 1.x
  • トラエフィック 2.x
  • グローバルCE
  • グルー
  • 輪郭
  • コング
  • ハプロキシ

イングレス-nginx

ここでは、クラスターで使用される ingress-nginx を例として、これを Linkerd と統合する方法を説明します。 

 $ kubectl get deploy -n イングレス- nginx ​
 名前準備完了最新利用可能年齢​ ​
 イングレス- nginx - コントローラ1 / 1 1 1 57 d
 イングレス- nginx - デフォルトバックエンド1 / 1 1 1 57 日
$ kubectl get pods - n イングレス- nginx
 名前準備完了ステータス再起動年齢
ingress - nginx - controller - 7647 c44fb9 - sss9m 1 / 1 実行中26 ( 59 分前) 57 日
ingress - nginx - defaultbackend - 84854 cd6cb - rvgd2 1 / 1 実行中27 ( 59 分前) 57 日

まず、ingress-nginx-controller コントローラーを更新し、pod に linkerd.io/inject: enabled アノテーションを追加する必要があります。 kubectl でデプロイメントを直接編集できます。クラスター内の ingress-nginx は Helm Chart を使用してインストールされるため、値に次の構成を追加できます。 

 コントローラー:
 ポッド注釈:
 linkerd.io/inject:enabled
 # ......

次に、値を使用して再度更新します。 

 # Helm リポジトリをIngress - nginx リポジトリで更新します
$ helm リポジトリにingress - nginx を追加しますhttps://kubernetes.github.io/ingress-nginx
 $ helm リポジトリの更新
# Ingress - nginx チャートをインストールする
$ helm アップグレード-- ingress - nginx をインストールingress - nginx / ingress - nginx -- namespace = ingress - nginx -- values ​​= values ​​.yaml

更新後、ingress-nginx のコントローラー Pod に linkerd プロキシ サイドカー コンテナーが自動的に挿入されます。 

 $ kubectl get pods - n イングレス- nginx
 名前準備完了ステータス再起動年齢
イングレス- nginx - コントローラー- f56c7f6fd - rxhrs 2/2 実行中0 4 分21 秒
ingress - nginx - defaultbackend - 84854 cd6cb - rvgd2 1 / 1 実行中27 ( 62 分前) 57 日

イングレス コントローラがメッシュに追加されたため、Linkerd メッシュの関連機能も備わっています。

  • Ingress コントローラーのゴールデン メトリック (1 秒あたりのリクエスト数など) を提供します。
  • Ingress コントローラ Pod とメッシュ アプリケーション Pod 間のトラフィックは暗号化され (相互に認証されます)。
  • HTTPトラフィックを確認できます
  • アプリケーションがエラー (5xx HTTP ステータス コードなど) を返すと、クライアントにエラー コードが返されるため、アプリケーションの Linkerd UI だけでなく、nginx イングレス コントローラーの Linkerd UI にも表示されます。

対応するインジケーターデータは、Linkerd ダッシュボードでも確認できます。

イングレス-nginx メトリクス

対応するチャート情報は Grafana でも確認できます。

イングレス-nginx グラファナ

次に、Emojivoto アプリケーションに対応する Ingress リソース オブジェクトを追加して、サービスを外部に公開します。 

 # 絵文字- ingress.yaml
 apiバージョン: ネットワーク。 k8s 。 io / v1
 種類: イングレス
メタデータ:
 名前: emojivoto - ingress
 ラベル:
 名前: emojivoto - ingress
 名前空間: emojivoto
 注釈:
 # nginx がメッシュ化されている以下の行を追加します
nginx 。 イングレス。 Kubernetes 。 io / サービス- アップストリーム: "true"
 # nginx 。 イングレス。 Kubernetes 。 io / アフィニティ: 「クッキー」
 # nginx 。 イングレス。 Kubernetes 。 io / アフィニティ- モード: "永続的"
 仕様:
 イングレスクラス名: nginx
 ルール:
 # Ingress Controller が使用する独自のIP でIP を更新します
- ホスト: 絵文字.192 .168 .0 .52 . ニップ。 io
 http://www.google.com/dp ...
 パス:
 - パスタイプ: プレフィックス
パス： /
 バックエンド:
 サービス：
 名前: web - svc - 2
 ポート:
 番号： 80

上記のリソース オブジェクトを適用するだけです。 

 $ kubectl apply -f emojivoto - ingress .yaml ​
 $ kubectl get ingress - n 絵文字
名前クラスホストアドレスポート年齢
emojivoto - ingress nginx 絵文字.192 .168 .0 .52 . ニップ。 io 192.168 .0 .52 80 61 秒

nip.io は任意の IP アドレスに対応するシンプルなワイルドカード DNS なので、etc/hosts ファイルを編集してカスタムのホスト名と IP アドレスのマッピングを設定する必要はありません。nip.io では、次の形式を使用して任意の IP アドレスをホスト名にマッピングできます。

名前なし:

  • 10.0.0.1.nip.io は 10.0.0.1 にマップされます
  • 192-168-1-250.nip.io は 192.168.1.250 にマップされます
  • 0a000803.nip.io は 10.0.8.3 にマップされます

名前付き:

  • app.10.8.0.1.nip.io は 10.8.0.1 にマップされます
  • app-116-203-255-68.nip.io は 116.203.255.68 にマッピングされます
  • app-c0a801fc.nip.io は 192.168.1.252 にマッピングされています
  • customer1.app.10.0.0.1.nip.io は 10.0.0.1 にマップされます
  • customer2-app-127-0-0-1.nip.io は 127.0.0.1 にマップされます
  • customer3-app-7f000101.nip.io は 127.0.1.1 にマップされます

nip.io は、<anything>[.-]<IP Address>.nip.io を「ドット」、「ダッシュ」、または「16 進数」表記の対応する <IP Address> にマッピングします。

ここでは、カスタム ドメイン名 emoji.192.168.0.52.nip.io を使用します。これは、ingress-nginx のエントリ アドレスである IP アドレス 192.168.0.52 に直接マッピングすることと同じなので、マッピングなしでサービスにアクセスできます。

絵文字

また、上記の Ingress では、 nginx.ingress.kubernetes.io/service-upstream: true というアノテーションが追加されていることにも注意してください。これは、Nginx Ingress Controller にトラフィックを Pod に直接ルーティングするのではなく、メッシュ アプリケーションのサービスにルーティングするように指示するために使用されます。デフォルトでは、Ingress コントローラーはターゲット サービスのエンドポイントを照会して、そのサービスの背後にある Pod の IP アドレスを取得します。トラフィックをメッシュ サービスに送信することで、負荷分散やトラフィック分割などの Linkerd の関連機能が有効になります。

ingress-nginx メッシュ

サービスへのアクセスを制限する

Linkerd ポリシー リソースを使用して、サービスにアクセスできるクライアントを制限できます。また、Emojivoto アプリを使用して、Voting マイクロサービスへのアクセスを制限し、Web サービスからのみ呼び出せるようにする方法も示します。

まず、投票サービス用のサーバー リソースを作成します。 Server は Linkerd の別の CRD カスタム リソースであり、ワークロードの特定のポートを表すために使用されます。サーバー リソースが作成されると、承認されたクライアントのみがアクセスできるようになります。

次のようなリソース オブジェクトを作成します。 

 # 投票- server.yaml
 apiバージョン: ポリシー。 リンクされました。 io / v1beta1
 種類: サーバー
メタデータ:
 名前: 投票- grpc
 名前空間: emojivoto
 ラベル:
 アプリ: 投票- svc
 仕様:
 ポッドセレクタ:
 マッチラベル:
 アプリ: 投票- svc
 ポート: grpc
 プロキシプロトコル: gRPC

上記のリソース オブジェクトを適用するだけです。 

 $ kubectl apply -f 投票- サーバー.yaml ​
 サーバー。 ポリシー。 リンクされました。 io / 投票- grpc 作成
$ kubectl get server - n emojivoto
 名前ポートプロトコル
投票- grpc grpc gRPC

サーバーは podSelector プロパティを使用して、記述する投票サービスの Pod を選択していることがわかります。また、適用する名前付きポート (grpc) も指定し、最後にこのポートで提供されるプロトコルが gRPC であることを指定します。これにより、プロキシがトラフィックを正しく処理し、プロトコル検出をスキップできるようになります。

このサービスにアクセスする権限がクライアントに与えられなくなったため、Web サービスから Voting への要求が拒否され始め、成功率が低下します。 Web サービスの Pod ログを直接表示して確認することもできます。 

 $ kubectl ログ-f web -svc -2 -f9d77474f -vxlrh -n emojivoto -c web -svc -2 ​ ​ ​ ​ ​ ​ ​ ​ ​
 2022/09/06 09:31:27リクエストの処理中にエラーが発生しました[ & { GET / api / vote ? choice = : trophy : HTTP / 1.1 1 1 マップ[ Accept - Encoding : [ gzip ] L5d - Client - Id : [ デフォルト. 絵文字ヴォート。 サービスアカウント。 身元。 リンクされました。 クラスター。 ローカル] L5d - Dst - 正規:[ web - apex . 絵文字ヴォート。 svc 。 クラスター。 local : 80 ] User - Agent :[ Go - http - client / 1.1 ] X - B3 - Sampled :[ 1 ] X - B3 - Spanid :[ f9e1dc6e24803ea8 ] X - B3 - Traceid :[ 5 ae662deee8fdbf2f3b9eaa40eb673d5 ]] {} < nil > 0 [] false web - apex . emojivoto : 80 map [ choice :[: trophy :]] map [ ] < nil > map [] 10.244.1.87 : 51244 / api / vote ? choice = : trophy : < nil > < nil > < nil > 0xc00045e4b0 }]: rpc error : code = PermissionDenied desc = サーバー投票での不正な接続- grpc
 # ......

linkerd viz authz コマンドを使用して、投票サービスに入るリクエストの承認ステータスを表示できます。 

 $ linkerd viz authz - n emojivoto デプロイ/ 投票
サーバー認証成功RPS LATENCY_P50 LATENCY_P95 LATENCY_P99
 投票- grpc [ 未承認] - 0.9 rps

すべての受信リクエストが現在、許可されていない状態にあることがわかります。

次に、クライアントにサーバーへのアクセスを許可する必要があります。ここでは、別の CRD オブジェクト ServerAuthorization を使用する必要があります。このオブジェクトを作成して、上記で作成した投票サーバーへの Web サービス アクセスを許可します。対応するリソース マニフェスト ファイルは次のとおりです。 

 # 投票- サーバー- auth.yaml
 apiバージョン: ポリシー。 リンクされました。 io / v1beta1
 種類: ServerAuthorization
 メタデータ:
 名前: 投票- grpc
 名前空間: emojivoto
 仕様:
 サーバー:
 名前: 投票- grpc #関連サーバーオブジェクト
# 投票サービスでは、 Web サービスからのリクエストのみが許可されます。
 クライアント：
 メッシュTLS :
 サービスアカウント:
 - 名前: ウェブ
- 名前: ウェブ- 2

上記のオブジェクトでは、spec.server.name を使用して上記の Server オブジェクトを関連付けます。 meshTLS は ServiceAccounts を ID ベースとして使用するため、認証も ServiceAccounts に基づいて行われます。したがって、spec.client.meshTLS.serviceAccounts を使用して、どのサービスが投票サービスにアクセスできるかを指定します。

リソース リストを直接適用することもできます。 

 $ kubectl apply -f 投票- サーバー- 認証.yaml ​
 サーバー認証。 ポリシー。 リンクされました。 io / 投票- grpc 作成
$ kubectl get serverauthorization - n 絵文字
ネームサーバー
投票- grpc 投票- grpc

このオブジェクトを使用すると、投票サービスへのすべてのリクエストが ServerAuthorization 投票グループによって承認されていることがわかります。 linkerd viz auth コマンドは時間枠内でクエリを実行するため、短時間に UNAUTHORIZED リクエストが表示される場合があることに注意してください。 

 $ linkerd viz authz - n emojivoto デプロイ/ 投票
サーバー認証成功RPS LATENCY_P50 LATENCY_P95 LATENCY_P99
 投票- grpc 投票- grpc 84.48 % 1.0 rps 1 ms 1 ms 1 ms

gRPC クライアント Pod を作成し、そこから投票サービスにアクセスしてみることで、他の Pod からのリクエストが拒否されるかどうかをテストすることもできます。 

 $ kubectl run grpcurl --rm -it --image = networld / grpcurl --restart = Never --command -- ./grpcurl -plaintext vote -svc . ​ ​ ​ ​ ​ ​ 絵文字: 8080 絵文字。 v1 。 投票サービス/ VoteDog
 コマンドプロンプトが表示されない場合は、Enter キーを押してみてください。
 アタッチ中にエラーが発生しました。 ログにフォールバックします: 接続をアップグレードできません: ポッドgrpcurl_default にコンテナgrpcurlが見つかりません
メソッド"emojivoto.v1.VotingService/VoteDog" の呼び出しエラー: サービス記述子"emojivoto.v1.VotingService" のクエリに失敗しました: rpc エラー: コード= PermissionDenied desc =
 ポッド「grpcurl」 が削除されました
pod default / grpcurl が終了しました( エラー)

クライアントは承認されていないため、リクエストは PermissionDenied エラーで拒否されます。

必要な数の ServerAuthorization リソースを作成して、必要な数の異なるクライアントを認証できます。また、認証されていない (つまり、メッシュ化されていない) クライアント、すべての認証済みクライアント、または特定の ID を持つ認証済みクライアントのみを認証するかどうかを指定することもできます。

さらに、クラスター全体のデフォルト ポリシーを設定することもできます。このポリシーは、定義されていないすべてのサーバー リソースに適用されます。 Linkerd は、リクエストを許可するかどうかを決定する際に次のロジックを使用します。

  • サーバー リソースが存在し、クライアントがそれに対応する ServerAuthorization リソースと一致する場合は許可します。
  • サーバー リソースが存在するが、クライアントがその ServerAuthorizations​ のいずれにも一致しない場合は、拒否されます。
  • ポートにサーバー リソースがない場合、デフォルトのポリシーが使用されます。

たとえば、linkerd アップグレード コマンドを使用して、デフォルトのポリシーを拒否に設定できます。 

 $ linkerd アップグレード-- policyController を設定します。 デフォルト許可ポリシー= 拒否| kubectl を適用- f -

あるいは、config.linkerd.io/default-inbound-policy アノテーションを設定することで、単一のワークロードまたは名前空間にデフォルト ポリシーを設定することもできます。

つまり、Server および ServerAuthorization オブジェクトを作成して明示的に承認しない限り、すべてのリクエストは拒否されます。この場合、ライブネス プローブと準備プローブには明示的な承認が必要です。そうしないと、Kubernetes は Pod がライブまたは準備完了であると認識できず、再起動してしまいます。次のようなポリシー オブジェクトを作成して、すべてのクライアントが Linkerd 管理ポートにアクセスできるようにし、Kubernetes が生存性と準備状況のチェックを実行できるようにします。 

 $ 猫<< EOF | kubectl を適用- f -
 ---
 # サーバー"admin" : この名前空間内のすべてのポッドの管理ポートと一致します
apiバージョン: ポリシー。 リンクされました。 io / v1beta1
 種類: サーバー
メタデータ:
 名前空間: emojivoto
 名前: 管理者
仕様:
 ポート: linkerd - admin
 ポッドセレクタ:
 matchLabels : {} # すべてのポッド
プロキシプロトコル: HTTP / 1
 ---
 # ServerAuthorization "admin-everyone" : 認証されていないアクセスを許可します
# 「admin」 サーバー。Kubernetes ヘルスチェックが通過できるようにします。
 apiバージョン: ポリシー。 リンクされました。 io / v1beta1
 種類: ServerAuthorization
 メタデータ:
 名前空間: emojivoto
 名前: 管理者- 全員
仕様:
 サーバー:
 名前: 管理者
クライアント：
 認証されていない: true

Kubelet (ヘルスチェックを実行する) の IP アドレスまたは範囲がわかっている場合は、ServerAuthorization をそれらの IP アドレスまたは範囲にさらに制限できます。たとえば、Kubelet が 10.244.0.1 で実行されていることがわかっている場合は、ServerAuthorization を次のように変更できます。 

 # ServerAuthorization "admin-kublet" : 認証されていないアクセスを許可します
# Kubernetes ヘルスチェックが通過できるように、 kubelet から"admin" サーバーを削除します。
 apiバージョン: ポリシー。 リンクされました。 io / v1beta1
 種類: ServerAuthorization
 メタデータ:
 名前空間: emojivoto
 名前: admin - kubelet
 仕様:
 サーバー:
 名前: 管理者
クライアント：
 ネットワーク:
 -cidr : 10.244.0.1/32
 認証されていない: true

注目すべきもう 1 つの点は、Server リソースを作成した後、ServerAuthorization を作成するまでの間に、すべてのリクエストが拒否される期間があることです。ライブ システムでこのような状況を回避するには、サービスをデプロイする前にポリシー リソースを作成するか、サーバーを作成する前に ServiceAuthorizations を作成して、クライアントがすぐに承認されるようにすることをお勧めします。

認可ポリシーの詳細については、https://linkerd.io/2.11/reference/authorization-policy/ にある公式ドキュメントを参照してください。

<<:  IoTとエッジコンピューティングの簡単な分析

>>:  Linkerd が新しいバージョン 2.12 にアップグレードされました

推薦する

ウェブサイトの包含率を向上させる方法

Baiduが最近アルゴリズムを更新した後、含まれるウェブサイトの数が急減しました。著者のウェブサイト...

ウェブサイトのページを閲覧する時間の長さは、ウェブサイトに滞在する時間の長さと同じですか? 1つの記事で違いとベストプラクティスを理解する

ページが閲覧される時間の長さは、ユーザーがそのページに滞在する時間の長さと同じではありません。したが...

SEO はサンドイッチですか?

最近、ウェブマスターが中間にいるという声が絶えず聞こえてきており、Sanqin SEO も「SEO ...

Inforは、より細分化された業界ソリューションを作成することでERPをより身近なものにします

[51CTO.com からのオリジナル記事] SAP と Oracle に次ぐ世界第 3 位のエンタ...

クラウドコンピューティングのコンプライアンス問題に関する誤解と現実を合理的に考察

ハッカーが米国の3大信用機関の1つであるEquifaxのシステムを攻撃し、1億4,300万人の個人デ...

サービス メッシュは具体的に何ができるのでしょうか?

​翻訳者 |ブガッティ校正：孫淑娟これら 2 つのマルチクラウド ネットワーク アーキテクチャを見て...

WeChat時代のマーケティングの役割の分析

現在最も人気のアプリケーションはWeChatです。長い間QQの使い方を知らなかった超初心者でも簡単に...

QQとQQグループの簡単なプロモーション方法について簡単に説明します

精度の高い無料プロモーションといえば、QQとQQグループプロモーションが最高です。テンセントQQは登...

holderhost-$7/3Gメモリ/150Gハードディスク/4Tトラフィック/Gポート/フェニックスシティ

holderhost.com の openvz 用大容量メモリ VPS をご紹介します。サーバー構成...

中小企業向けインターネットマーケティングソリューション

電子商取引の発展に伴い、中国のビジネス分野は徐々に「有形」から「無形」へと移行しています。インターネ...

簡単な分析: 企業ウェブサイトに適したキーワードの選び方

私はインターネット業界で4年以上働いています。この過程で、企業から非常に奇妙な要求をいくつか見てきま...

タオバオストアのプロモーションによりトラフィックが飛躍的に増加します

今日は私が以前お店を経営していた時に使っていたこの方法を紹介します。結果は素晴らしく、コンバージョン...

企業視点での検索マーケティング戦略共有

検索マーケティング (SEM) には、SEO と検索入札 PPC が含まれます。これらは、中国企業が...

2018 年 9 月のカンファレンスで発表される Apple のハードウェア製品が明らかに: MacBook と iPad Pro も含まれる!

2018年最もホットなプロジェクト：テレマーケティングロボットがあなたの参加を待っていますA5ベンチ...

3つの可能なマルチクラウド展開戦略

組織内の複数の部門でワークフローやストレージのニーズが異なる場合は、マルチクラウド展開が役立ちます。...