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 にアップグレードされました

推薦する

ウェブサイトをダウングレードする際に分析し調整すべき6つの側面

SEO をしばらくやってきた SEO 担当者は、自分の実践を経て、Baidu に不正ポイント システ...

クラウドネイティブコンピューティング財団の第11回インキュベーションプロジェクトが卒業し、中国で誕生

中国で誕生した最初のインキュベーションプロジェクトであるHarborが、Cloud Native C...

[SEO例] 明るい未来を見つけるための新しい方法を見つける

中秋節はもうすぐそこです。あと1か月ちょっとです。そこで、誰もがトラフィックを増やすために中秋節の最...

ただ開くだけじゃない！ OpenStack ベースの IBM Cloud Manager を活用する新しい方法

「IBMはOpenStack組織に加盟して以来、OpenStackエコシステムの構築に積極的に関わり...

Bステーションのユニークな考え方

暗く風の強い夜、武術の達人たちが少林寺や武当山のふもとの荒れ果てた寺院に集まり、焚き火を焚き、古酒を...

IDC：中国のパブリッククラウド市場の成長率は今後30％～40％に回復すると予想

IDCはこのほど、2022年上半期の中国パブリッククラウドサービス市場に関するデータを発表し、市場規...

Alibaba Cloud が中国で Redis の初のグローバル マルチアクティブ バージョンをリリース

データセンター間でのデータ同期は、企業が災害復旧能力を向上させるために不可欠な手段です。ソーシャルネ...

権威の高いウェブサイトのための SEO の方向性 3: 内部リンクのレイアウト

みなさんこんにちは。私はMuzi Chengzhouです。権威の高いウェブサイトには、新しいウェブサ...

SEOガイドラインの5つの要素

検索エンジン最適化のプロセスにおいて、一部の Web サイトは検索エンジンで非常に高いランクを獲得す...

企業にとって新しいウェブサイトの最適化はどれほど重要ですか?

ショートビデオ、セルフメディア、インフルエンサーのためのワンストップサービスインターネット時代の到来...

あまり知られていない VMware の 6 つのトリック

[[242514]] 1. VMware が esxi ネットワーク カード ドライバーをアップグレ...

11月のモバイルアプリTOP1000リスト

この記事では、11 月のモバイル インターネット業界のトップ 1000 ランキングを紹介します。注：...

Sogou の WeChat 検索は単なる花瓶ですか?

WeChat は確かに簡単には手に入りません。6 億人のユーザーと数百万の公開アカウントを持つ We...

SEO デッドリンクに関する関連知識

サイト全体の最適化プロジェクトを運用する場合、デッドリンクツールを使用して、Web サイト上のデッド...

2012 年以降、 SEO の世界でどのような変化が起こりましたか?

百度の年次総会で、ロビン・リー氏は2012年の百度の業績を総括し、2012年は百度にとって最も困難な...