著者はhttps://www.brightfunds.org/funds/foss-nonprofits [無料およびオープンソース基金]を選択して、https://do.co/w4do-cta [Donationsのために書く]の一部として寄付を受け取りましたプログラム。

前書き

Ambassadorは、異種サービス間でトラフィックをルーティングし、分散ワークフローを維持するクラウドネイティブアプリケーション用のAPIゲートウェイです。 単一のエントリポイントとして機能し、サービス検出、構成管理、ルーティングルール、レート制限などのタスクをサポートします。 サービスの優れた柔軟性と構成の容易さを提供します。

Envoyは、クラウドネイティブアプリケーション用に設計されたオープンソースサービスプロキシです。 Kubernetesでは、アンバサダーを使用してEnvoy設定をインストールおよび管理できます。 Ambassadorは、ゼロダウンタイムの構成変更と、認証、サービス検出、https://www.digitalocean.com/community/tutorials/an-introduction-to-service-meshes [services meshes]などの他の機能との統合をサポートしています。

このチュートリアルでは、Helmを使用してKubernetesクラスターにAmbassador API Gatewayをセットアップし、ルーティングルールに基づいて着信トラフィックをさまざまなサービスにルーティングするように構成します。 ホスト名または関連するサービスへのパスに基づいてトラフィックをルーティングするようにこれらのルールを構成します。

前提条件

このガイドを始める前に、次のものが必要です。

  • kubectlが設定されたDigitalOcean Kubernetesクラスター。 DigitalOceanでKubernetesクラスターを作成するには、https://www.digitalocean.com/docs/kubernetes/quickstart/ [Kubernetes Quickstart]を参照してください。

  • ローカルマシンにインストールされたHelmパッケージマネージャー、およびクラスターにインストールされたTiller。 Kubernetesにソフトウェアをインストールする方法のステップ1と2を完了します。 Helm Package Managerを使用したクラスター]

  • 少なくとも2つのAレコードが設定された完全に登録されたドメイン名。 このチュートリアルでは、全体で + svc1。++ svc2。+、および `+ svc3。+`を使用します。 DNSクイックスタートに従って、DigitalOceanでレコードを設定できます。

ステップ1-Ambassadorのインストール

このセクションでは、KubernetesクラスターにAmbassadorをインストールします。 Ambassadorは、Helmチャートを使用するか、YAML設定ファイルを `+ kubectl +`コマンドに渡すことでインストールできます。

このチュートリアルでは、https://helm.sh/ [Helm]チャートを使用して、Ambassadorをクラスターにインストールします。 前提条件に従って、クラスターにHelmをインストールします。

開始するには、次のコマンドを実行してHelm経由でAmbassadorをインストールします。

helm upgrade --install --wait ambassador stable/ambassador

次のような出力が表示されます。

OutputRelease "ambassador" does not exist. Installing it now.
NAME:   ambassador
LAST DEPLOYED: Tue Jun 18 02:15:00 2019
NAMESPACE: default
STATUS: DEPLOYED

RESOURCES:
==> v1/Deployment
NAME        READY  UP-TO-DATE  AVAILABLE  AGE
ambassador  3/3    3           3          2m39s

==> v1/Pod(related)
NAME                         READY  STATUS   RESTARTS  AGE
ambassador-7d55c468cb-4gpq9  1/1    Running  0         2m38s
ambassador-7d55c468cb-jr9zr  1/1    Running  0         2m38s
ambassador-7d55c468cb-zhm7l  1/1    Running  0         2m38s

==> v1/Service
NAME               TYPE          CLUSTER-IP      EXTERNAL-IP    PORT(S)                     AGE
ambassador         LoadBalancer  10.245.183.114  139.59.52.164  80:30001/TCP,443:31557/TCP  2m40s
ambassador-admins  ClusterIP     10.245.46.43    <none>         8877/TCP                    2m41s

==> v1/ServiceAccount
NAME        SECRETS  AGE
ambassador  1        2m43s

==> v1beta1/ClusterRole
NAME        AGE
ambassador  2m41s

==> v1beta1/ClusterRoleBinding
NAME        AGE
ambassador  2m41s

==> v1beta1/CustomResourceDefinition
NAME                                          AGE
authservices.getambassador.io                 2m42s
consulresolvers.getambassador.io              2m41s
kubernetesendpointresolvers.getambassador.io  2m42s
kubernetesserviceresolvers.getambassador.io   2m43s
mappings.getambassador.io                     2m41s
modules.getambassador.io                      2m41s
ratelimitservices.getambassador.io            2m42s
tcpmappings.getambassador.io                  2m41s
tlscontexts.getambassador.io                  2m42s
tracingservices.getambassador.io              2m43s

. . .

これにより、Kubernetesクラスターノードが接続されたAmbassadorデプロイメント、サービス、およびロードバランサーが作成されます。 ドメインのAレコードにマップするには、ロードバランサーのIPが必要です。

Ambassador Load BalancerのIPアドレスを取得するには、次を実行します。

kubectl get svc --namespace default ambassador

次のような出力が表示されます。

OutputNAME         TYPE           CLUSTER-IP       EXTERNAL-IP     PORT(S)                      AGE
ambassador   LoadBalancer         80:30001/TCP,443:31557/TCP   8m4s

この手順で外部IP + your-IP-address +`に注意し、これを指すように(ドメインプロバイダーを介して) `+ svc1。++ svc2。+、および `+ svc3。+`のドメインをマッピングします。 IPアドレス。

SSL終了の設定方法に記載されている手順を使用して、DigitalOceanロードバランサーでHTTPSを有効にできます。 Load Balancerを介してTLS終了を構成することをお勧めします。 TLS終了を設定する別の方法は、https://www.getambassador.io/reference/core/tls/ [AmbassadorのTLSサポート]を使用することです

Helmを使用してKubernetesクラスターにAmbassadorをインストールし、デフォルトのネームスペースに3つのレプリカを持つAmbassadorデプロイメントを作成しました。 これにより、すべてのトラフィックをAPI GatewayにルーティングするパブリックIPを備えたロードバランサーも作成されました。 次に、このAPI Gatewayのテストに使用する3つの異なるサービス用のKubernetesデプロイを作成します。

手順2-Webサーバーの展開の設定

このセクションでは、3つの異なるWebサーバーコンテナを実行する3つの展開を作成します。 3つの異なるWebサーバーコンテナのKubernetesデプロイメントの定義を使用してYAMLファイルを作成し、 `+ kubectl +`を使用してデプロイします。

好みのテキストエディターを開いて、Nginx Webサーバーの最初の展開を作成します。

nano svc1-deploy.yaml

ファイルに次のyaml設定を入力します。

svc1-deploy.yaml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
 name:
spec:
 replicas: 1
 selector:
   matchLabels:
     app: nginx
     name: svc1
 strategy:
   type: RollingUpdate
 template:
   metadata:
     labels:
       app: nginx
       name: svc1
   spec:
     containers:
     - name: nginx
       image:
       ports:
       - name: http
         containerPort: 80

ここでは、https://hub.docker.com/_/nginx [+ nginx:latest +]コンテナイメージでKubernetesの + Deployment +`を定義し、 `+++と呼ばれる + 1 + レプリカでデプロイします。 `+ Deployment `は、ポート ` 80 +`でクラスタ内を公開するように定義されています。

ファイルを保存して閉じます。

次に、次のコマンドを実行してこの構成を適用します。

kubectl apply -f svc1-deploy.yaml

作成を確認する出力が表示されます。

Outputdeployment.extensions/svc1 created

次に、2番目のWebサーバーのデプロイメントを作成します。 次のコマンドで `+ svc2-deploy.yaml +`というファイルを開きます:

nano svc2-deploy.yaml

ファイルに次のYAML設定を入力します。

svc2-deploy.yaml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
 name:
spec:
 replicas: 1
 selector:
   matchLabels:
     app: httpd
     name: svc2
 strategy:
   type: RollingUpdate
 template:
   metadata:
     labels:
       app: httpd
       name: svc2
   spec:
     containers:
     - name: httpd
       image:
       ports:
       - name: http
         containerPort: 80

ここでは、Kubernetesの + Deployment +`をhttps://hub.docker.com/_/httpd [+ httpd `]コンテナイメージで定義し、 `++と呼ばれる` + 1 + `レプリカでデプロイします。

ファイルを保存して閉じます。

次のコマンドを実行して、この構成を適用します。

kubectl apply -f svc2-deploy.yaml

次の出力が表示されます。

Outputdeployment.extensions/svc2 created

最後に、3番目のデプロイメントのために、 `+ svc3-deploy.yaml +`ファイルを開いて作成します:

nano svc3-deploy.yaml

ファイルに次の行を追加します。

svc3-deploy.yaml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
 name:
spec:
 replicas: 1
 selector:
   matchLabels:
     app: httpbin
     name: svc3
 strategy:
   type: RollingUpdate
 template:
   metadata:
     labels:
       app: httpbin
       name: svc3
   spec:
     containers:
     - name: httpbin
       image:
       ports:
       - name: http
         containerPort: 80

ここで、「+」と呼ばれる「+1」レプリカでデプロイされるhttp://httpbin.org/ [+ httpbin +]コンテナイメージでKubernetesの `+ Deployment +`を定義しました。

ファイルを保存して閉じます。

最後に、次のコマンドを実行して適用します。

kubectl apply -f svc3-deploy.yaml

次の出力が表示されます。

Outputdeployment.extensions/svc3 created

Kubernetes展開を使用して3つのWebサーバーコンテナを展開しました。 次の手順では、これらの展開をインターネットトラフィックに公開します。

ステップ3-アンバサダーアノテーションでサービスを使用してアプリを公開する

このセクションでは、Webアプリをインターネットに公開し、https://www.getambassador.io/reference/configuration/ [Ambassadorアノテーション]を使用してKubernetesサービスを作成し、トラフィックをルーティングするルールを構成します。 Kubernetesの注釈は、オブジェクトにメタデータを追加する方法です。 Ambassadorは、サービスからのこれらの注釈値を使用して、ルーティングルールを構成します。

念のため、ドメイン(たとえば、「。your-domain」、「。your-domain」、「+。your-domain」)をDNSレコードのロードバランサーのパブリックIPにマッピングする必要があります。

このファイルを作成して開くことにより、Ambassadorアノテーションを使用して `+ svc1 +`デプロイメントのKubernetesサービスを定義します。

nano svc1-service.yaml

svc1-service.yaml

apiVersion: v1
kind: Service
metadata:
 name: svc1
 annotations:
   getambassador.io/config: |
     ---
     apiVersion: ambassador/v1
     kind: Mapping
     name: svc1-service_mapping
     host:
     prefix: /
     service: svc1:80
spec:
 selector:
   app: nginx
   name: svc1
 ports:
 - name: http
   protocol: TCP
   port: 80

このYAMLコードでは、ホスト名 “をこのサービスにマッピングするために、AmbassadorアノテーションでKubernetesサービス “を定義しています。

`+ svc1-service.yaml +`を保存して終了し、次を実行してこの設定を適用します。

kubectl apply -f svc1-service.yaml

次の出力が表示されます。

Outputservice/svc1 created

Ambassadorアノテーションを使用して、 `+ svc2 +`デプロイメント用の2つ目のKubernetesサービスを作成します。 これは、Ambassadorを使用したホストベースのルーティングの別の例です。

svc2-service.yaml

次の構成をファイルに追加します。

svc2-service.yaml

apiVersion: v1
kind: Service
metadata:
 name: svc2
 annotations:
   getambassador.io/config: |
     ---
     apiVersion: ambassador/v1
     kind: Mapping
     name: svc2-service_mapping
     host:
     prefix: /
     service: svc2:80
spec:
 selector:
   app: httpd
   name: svc2
 ports:
 - name: http
   protocol: TCP
   port: 80

これを「+ svc2-service.yaml 」として保存します。 ここで、Ambassadorアノテーションを使用して別のKubernetesサービスを定義し、「 host 」ヘッダー値が「 svc2.your-domain 」のリクエストをAmbassadorが受信したときに、トラフィックを「 svc2 」にルーティングします。 したがって、このホストベースのルーティングにより、サブドメイン「 svc2.your-domain 」にリクエストを送信し、トラフィックをサービス「 svc2 」にルーティングして、「 httpd +」ウェブサーバーからリクエストを処理できます。

このサービスを作成するには、次を実行します。

kubectl apply -f svc2-service.yaml

次の出力が表示されます。

Outputservice/svc2 created

`+ svc3 `デプロイメント用の3番目のKubernetesサービスを作成し、パス ` svc2.your-domain / bin +`経由で提供します。 これにより、Ambassadorのパスベースのルーティングが構成されます。

svc3-service.yaml

apiVersion: v1
kind: Service
metadata:
 name: svc3
spec:
 selector:
   app: httpbin
   name: svc3
 ports:
 - name: http
   protocol: TCP
   port: 80

これを「+ svc3-service.yaml +」として保存し、次を実行して構成を適用します。

kubectl apply -f svc3-service.yaml

あなたの出力は次のようになります。

Outputservice/svc3 created

`+ svc2-service.yaml `を編集して2番目のAmbassadorアノテーションブロックを追加し、 ` / bin `を ` svc3 +`サービスにルーティングします。

nano svc2-service.yaml

svc2-service.yaml

apiVersion: v1
kind: Service
metadata:
 name: svc2
 annotations:
   getambassador.io/config: |
     ---
     apiVersion: ambassador/v1
     kind: Mapping
     name: svc2-service_mapping
     host: svc2.your-domain
     prefix: /
     service: svc2:80







spec:
 selector:
   app: httpd
   name: svc2
 ports:
 - name: http
   protocol: TCP
   port: 80

2つ目のAmbassadorアノテーションブロックを追加して、「+ / bin 」で始まるパスを設定して、「 svc3 」Kubernetesサービスにマッピングします。 ` svc2.your-domain / bin `のリクエストを ` svc3 `にルーティングするために、2番目の注釈ブロックをホスト値 ` svc2.your-domain `として追加しました。ブロック。 したがって、パスベースのルーティングを使用すると、リクエストを「 svc2.your-domain / bin 」に送信できます。リクエストはサービス「 svc3 」で受信され、このチュートリアルの「 httpbin +」アプリケーションで処理されます

次に、以下を実行して変更を適用します。

kubectl apply -f svc2-service.yaml

次の出力が表示されます。

Outputservice/svc2 configured

3つの展開用にKubernetesサービスを作成し、Ambassadorアノテーションを使用してホストベースおよびパスベースのルーティングルールを追加しました。 次に、これらのサービスに高度な構成を追加して、ルーティング、リダイレクト、カスタムヘッダーを構成します。

ステップ4-ルーティングのための高度なAmbassador構成

このセクションでは、Ambassadorアノテーションをhttps://www.getambassador.io/reference/headers/ [ヘッダーの変更]およびhttps://www.getambassador.io/reference/redirects [リダイレクトの構成]に追加してサービスを構成します。 。

ドメイン「+ svc1。」を「 curl +」し、応答ヘッダーを確認します。

curl -I svc1.

出力は次のようになります。

OutputHTTP/1.1 200 OK
server: envoy
date: Mon, 17 Jun 2019 21:41:00 GMT
content-type: text/html
content-length: 612
last-modified: Tue, 21 May 2019 14:23:57 GMT
etag: "5ce409fd-264"
accept-ranges: bytes
x-envoy-upstream-service-time: 0

この出力は、Ambassadorを使用してルーティングされたサービスから受信したヘッダーを示しています。 Ambassadorアノテーションを使用してカスタムヘッダーをサービスレスポンスに追加し、新しく追加されたヘッダーの出力を検証します。

サービスレスポンスにカスタムヘッダーを追加するには、ヘッダー `+ x-envoy-upstream-service-time `をレスポンスから削除し、新しいレスポンスヘッダー ` x-geo-location:India `を ` svc1 +`に追加します。 (要件に応じてこのヘッダーを変更できます。)

ファイル `+ svc1-service.yaml +`を編集します。

nano svc1-service.yaml

次の強調表示された行で注釈を更新します。

svc1-service.yaml

apiVersion: v1
kind: Service
metadata:
 name: svc1
 annotations:
   getambassador.io/config: |
     ---
     apiVersion: ambassador/v1
     kind: Mapping
     name: svc1-service_mapping
     host: svc1.example.com
     prefix: /




     service: svc1:80
spec:
 selector:
   app: nginx
   name: svc1
 ports:
 - name: http
   protocol: TCP
   port: 80

ここでは、 + svc1 +`サービスを変更して `+ x-envoy-upstream-service-time`を削除し、HTTP応答に ++ `ヘッダーを追加しました。

行った変更を適用します。

kubectl apply -f svc1-service.yaml

次の出力が表示されます。

Outputservice/svc1 configured

ここで、 `+ curl +`を実行して、サービスレスポンスの更新されたヘッダーを検証します。

curl -I svc1.

出力は次のようになります。

OutputHTTP/1.1 200 OK
server: envoy
date: Mon, 17 Jun 2019 21:45:26 GMT
content-type: text/html
content-length: 612
last-modified: Tue, 21 May 2019 14:23:57 GMT
etag: "5ce409fd-264"
accept-ranges: bytes
x-geo-location: India

ホスト名 `+ svc3。`のリクエストをパス ` svc2。`にリダイレクトするために、 ` svc3-service.yaml +`を編集します:

nano svc3-service.yaml

次のYAMLに示すようにAmbassador注釈ブロックを追加して保存します。

svc3-service.yaml

apiVersion: v1
kind: Service
metadata:
 name: svc3











spec:
 selector:
   app: httpbin
   name: svc3
 ports:
 - name: http
   protocol: TCP
   port: 80

ホスト名「+ svc3。」の「 svc2。」から「 svc3 」の301リダイレクト応答を設定する「 host_redirect:true 」を追加しました。 ` host_redirect +`パラメーターは、301リダイレクト応答をクライアントに送信します。 設定しない場合、要求は301 HTTP応答ではなく200 HTTP応答を受け取ります。

次のコマンドを実行して、これらの変更を適用します。

kubectl apply -f svc3-service.yaml

次のような出力が表示されます。

Outputservice/svc3 configured

これで、 + curl`を使用して + svc3.your-domain`の応答を確認できます。

curl -I svc3.

出力は次のようになります。

OutputHTTP/1.1 301 Moved Permanently
location: http://svc2.your-domain/bin
date: Mon, 17 Jun 2019 21:52:05 GMT
server: envoy
transfer-encoding: chunked

出力はサービス + svc3。+`に対するリクエストの応答のHTTPヘッダーであり、サービスアノテーションの `+ host_redirect:true +`の設定がHTTPステータスコードを正しく提供していることを示します: `+301 Moved Permanently +

HTTPヘッダーを変更し、リダイレクトを構成するために、Ambassadorアノテーションを使用してサービスを構成しました。 次に、Ambassador API Gatewayサービスにグローバル構成を追加します。

ステップ5-Ambassadorグローバル構成のセットアップ

このセクションでは、Ambassadorサービスを編集して、グローバルGZIP圧縮構成を追加します。 GZIP圧縮により、HTTPアセットのサイズが圧縮され、ネットワーク帯域幅の要件が軽減され、Webクライアントの応答時間が短縮されます。 この構成は、Ambassador API Gatewayを介してルーティングされるすべてのトラフィックに影響します。 同様に、Ambassadorを使用して他のグローバルモジュールを構成できます。これにより、グローバルレベルでAmbassadorの特別な動作を有効にできます。 これらのグローバル構成は、注釈を使用してAmbassadorサービスに適用できます。 詳細については、https://www.getambassador.io/reference/modules [Ambassadorのグローバル構成]ドキュメントを参照してください。

次の `+ kubectl edit `コマンドは、vimであるデフォルトのエディターを開きます。 たとえば、nanoを使用するには、環境変数 ` KUBE_EDITOR +`をnanoに設定できます。

export KUBE_EDITOR="nano"

アンバサダーサービスを編集します。

kubectl edit service ambassador

GZIP圧縮のために、強調表示された行を新しい注釈ブロックに追加します。

アンバサダーサービスの編集

apiVersion: v1
kind: Service
metadata:

























 creationTimestamp: "2019-06-17T20:45:04Z"
 labels:
   app.kubernetes.io/instance: ambassador
   app.kubernetes.io/managed-by: Tiller
   app.kubernetes.io/name: ambassador
   helm.sh/chart: ambassador-2.8.2
 name: ambassador
 namespace: default
 resourceVersion: "2153"
 . . .

AmbassadorアノテーションブロックをAmbassadorサービスに追加し、GZIPをAPI Gateway用にグローバルに設定しました。 ここには、 `+ memory_level `で使用される内部メモリの量を制御する設定が含まれています。これは1から9の値になります。 ` BEST `に設定された ` compression_level `は、より高いレイテンシを犠牲にしてより高い圧縮率を保証します。 「 min_content_length 」を使用して、最小応答長を「+256」バイトに設定しました。 `+ content_type `には、圧縮をもたらすhttps://en.wikipedia.org/wiki/Media_type[media types](以前のMIME-types)のセットを具体的に含めました。 最後に、圧縮を可能にするために、最後の2つの構成を「 false +」として追加しました。

GZIP圧縮の詳細については、https://www.envoyproxy.io/docs/envoy/v1.11.2/configuration/http_filters/gzip_filter#how-it-works [EnvoyのGZIPページ]をご覧ください。

このサービスの変更は、API Gatewayのグローバル構成として適用されます。

エディターを終了すると、次のような出力が表示されます。

Outputservice/ambassador edited

値が「+ gzip 」の「 content-encoding 」ヘッダーに対して「 curl 」を使用して「 svc1。+」を確認します。

curl --compressed -i http://svc1.example.com

出力は次のようになります。

OutputHTTP/1.1 200 OK
server: envoy
date: Mon, 17 Jun 2019 22:25:35 GMT
content-type: text/html
last-modified: Tue, 21 May 2019 14:23:57 GMT
accept-ranges: bytes
x-geo-location: India
vary: Accept-Encoding

transfer-encoding: chunked

<!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>

ここで、受信した応答の `+ content-encoding `が ` gzip +`圧縮されていることを示す応答ヘッダーを持つNginxのデフォルトのHTMLページを見ることができます。

APIゲートウェイ全体の選択されたコンテンツタイプレスポンスのGZIP構成を有効にするために、グローバル構成をAmbassadorに追加しました。

結論

Ambassadorを使用してKubernetesクラスターのAPI Gatewayを正常にセットアップしました。 ホストおよびパスベースのルーティング、カスタムヘッダー、グローバルGZIP圧縮を使用して、アプリを公開できるようになりました。

Ambassadorのアノテーションと設定パラメータの詳細については、https://www.getambassador.io/reference/configuration [Ambassadorの公式ドキュメント]をご覧ください。