前書き
サービスメッシュは、アプリケーションのマイクロサービス間の通信を管理できるインフラストラクチャレイヤーです。 より多くの開発者がマイクロサービスを使用するにつれて、サービスメッシュが進化し、分散セットアップで一般的な管理タスクと管理タスクを統合することにより、その作業がより簡単かつ効果的になりました。
Istioのようなサービスメッシュを使用すると、サービスディスカバリ、ルーティングとトラフィックの構成、暗号化と認証/承認、監視とテレメトリなどのタスクを簡素化できます。 特に、Istioは、既存のサービスコードを大幅に変更することなく動作するように設計されています。 たとえば、Kubernetesを使用する場合、既存のアプリケーションリソースと連携するIstio固有のオブジェクトを構築することで、クラスターで実行されているアプリケーションにサービスメッシュ機能を追加できます。
このチュートリアルでは、KubernetesのHelmパッケージマネージャーを使用してIstioをインストールします。 次に、Istioを使用して、GatewayおよびVirtual Serviceリソースを作成することにより、デモNode.jsアプリケーションを外部トラフィックに公開します。 最後に、Grafanaテレメトリアドオンにアクセスして、アプリケーションのトラフィックデータを視覚化します。
前提条件
このチュートリアルを完了するには、次のものが必要です。
-
役割ベースのアクセス制御（RBAC）が有効になっているKubernetes 1.10+クラスター。 このセットアップでは、3つのノードでDigitalOcean Kubernetes clusterを使用しますが、create a cluster using another methodを自由に使用できます。
[.note]＃Note:このセットアップには、少なくとも8GBの使用可能なメモリと4vCPUを備えたクラスターを強くお勧めします。 このチュートリアルでは、DigitalOceanの標準の4GB / 2vCPUドロップレットのうち3つをノードとして使用します。
＃
-
開発サーバーにインストールされ、クラスターに接続するように構成された
kubectlコマンドラインツール。 official documentationにkubectlをインストールする方法の詳細を読むことができます。 -
How To Install Software on Kubernetes Clusters with the Helm Package Managerのステップ1および2で概説されている指示に従って、開発サーバーにHelmをインストールし、クラスターにTillerをインストールします。
-
Dockerが開発サーバーにインストールされています。 Ubuntu 18.04を使用している場合は、How To Install and Use Docker on Ubuntu 18.04の手順1と2に従います。それ以外の場合は、他のオペレーティングシステムへのインストールについて、official documentationに従ってください。 リンクされたチュートリアルのステップ2で説明されているように、root以外のユーザーを必ず
dockerグループに追加してください。 -
Docker Hubアカウント。 これを設定する方法の概要については、Docker Hubへのthis introductionを参照してください。
[[step-1 -—- packaging-the-application]] ==ステップ1—アプリケーションのパッケージ化
Kubernetesでデモアプリケーションを使用するには、コードのクローンを作成してパッケージ化し、kubelet agentがイメージをプルできるようにする必要があります。
最初のステップは、DigitalOcean Community GitHub accountからnodejs-image-demo respositoryを複製することです。 このリポジトリには、How To Build a Node.js Application with Dockerで説明されているセットアップのコードが含まれています。このコードは、Node.jsアプリケーションのイメージを構築する方法と、このイメージを使用してコンテナーを作成する方法を説明しています。 アプリケーション自体の詳細については、シリーズFrom Containers to Kubernetes with Node.jsを参照してください。
開始するには、nodejs-image-demoリポジトリをistio_projectというディレクトリに複製します。
git clone https://github.com/do-community/nodejs-image-demo.git istio_projectistio_projectディレクトリに移動します。
cd istio_projectこのディレクトリには、サメに関する基本情報をユーザーに提供するサメ情報アプリケーション用のファイルとフォルダが含まれています。 ディレクトリには、アプリケーションファイルに加えて、アプリケーションコードを使用してDockerイメージを構築するための手順を含むDockerfileが含まれています。 Dockerfileの命令の詳細については、Step 3 of How To Build a Node.js Application with Dockerを参照してください。
アプリケーションコードとDockerfileが期待どおりに機能することをテストするには、docker buildコマンドを使用してイメージをビルドしてタグ付けし、イメージを使用してデモコンテナを実行します。 -tフラグをdocker buildとともに使用すると、Docker Hubユーザー名でイメージにタグを付けることができるため、テスト後にDockerHubにプッシュできます。
次のコマンドでイメージをビルドします。
docker build -t your_dockerhub_username/node-demo .コマンドの.は、ビルドコンテキストが現在のディレクトリであることを指定します。 画像にnode-demoという名前を付けましたが、別の名前を付けることもできます。
ビルドプロセスが完了すると、docker imagesを使用してイメージを一覧表示できます。
docker imagesイメージのビルドを確認する次の出力が表示されます。
OutputREPOSITORY TAG IMAGE ID CREATED SIZE
your_dockerhub_username/node-demo latest 37f1c2939dbf 5 seconds ago 77.6MB
node 10-alpine 9dfa73010b19 2 days ago 75.3MB次に、docker runを使用して、このイメージに基づいてコンテナを作成します。 このコマンドには3つのフラグが含まれます。
-
-p：これにより、コンテナーのポートが公開され、ホストのポートにマップされます。 ホストではポート80を使用しますが、そのポートで別のプロセスを実行している場合は、必要に応じてこれを自由に変更してください。 これがどのように機能するかについての詳細は、port bindingに関するDockerドキュメントのこの説明を参照してください。 -
-d：これはコンテナをバックグラウンドで実行します。 -
--name：これにより、コンテナにカスタマイズされた名前を付けることができます。
次のコマンドを実行して、コンテナを構築します。
docker run --name node-demo -p 80:8080 -d your_dockerhub_username/node-demo実行中のコンテナをdocker psで検査します。
docker psアプリケーションコンテナが実行されていることを確認する出力が表示されます。
OutputCONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
49a67bafc325 your_dockerhub_username/node-demo "docker-entrypoint.s…" 8 seconds ago Up 6 seconds 0.0.0.0:80->8080/tcp node-demoこれで、サーバーIPにアクセスしてセットアップをテストできます：http://your_server_ip。 アプリケーションには、次のランディングページが表示されます。
アプリケーションをテストしたので、実行中のコンテナを停止できます。 docker psを再度使用して、CONTAINER IDを取得します。
docker psOutputCONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
49a67bafc325 your_dockerhub_username/node-demo "docker-entrypoint.s…" About a minute ago Up About a minute 0.0.0.0:80->8080/tcp node-demodocker stopでコンテナを停止します。 ここにリストされているCONTAINER IDを、必ず独自のアプリケーションCONTAINER IDに置き換えてください。
docker stop 49a67bafc325イメージをテストしたので、Docker Hubにプッシュできます。 まず、前提条件で作成したDocker Hubアカウントにログインします。
docker login -u your_dockerhub_usernameプロンプトが表示されたら、Docker Hubアカウントのパスワードを入力します。 この方法でログインすると、Docker Hubの認証情報を使用してroot以外のユーザーのホームディレクトリに~/.docker/config.jsonファイルが作成されます。
docker push commandを使用してアプリケーションイメージをDockerHubにプッシュします。 your_dockerhub_usernameを独自のDockerHubユーザー名に置き換えることを忘れないでください。
docker push your_dockerhub_username/node-demoこれで、KubernetesとIstioでアプリケーションを実行するためにプルできるアプリケーションイメージができました。 次に、Helmを使用したIstioのインストールに進むことができます。
[[step-2 -—- installing-istio-with-helm]] ==ステップ2—IstioとHelmのインストール
Istioにはさまざまなインストール方法がありますが、ドキュメントでは、構成オプションの管理の柔軟性を最大化するためにHelmの使用を推奨しています。 IstioをHelmと共にインストールし、Grafanaアドオンが有効になっていることを確認して、アプリケーションのトラフィックデータを視覚化できるようにします。
最初に、Istioリリースリポジトリを追加します。
helm repo add istio.io https://storage.googleapis.com/istio-release/releases/1.1.7/charts/これにより、リポジトリ内のHelmチャートを使用してIstioをインストールできるようになります。
リポジトリがあることを確認します。
helm repo lististio.ioリポジトリがリストされているはずです。
OutputNAME URL
stable https://kubernetes-charts.storage.googleapis.com
local http://127.0.0.1:8879/charts
istio.io https://storage.googleapis.com/istio-release/releases/1.1.7/charts/次に、helm install commandを使用してistio-initチャートでIstioのCustom Resource Definitions（CRD）をインストールします。
helm install --name istio-init --namespace istio-system istio.io/istio-initOutputNAME: istio-init
LAST DEPLOYED: Fri Jun 7 17:13:32 2019
NAMESPACE: istio-system
STATUS: DEPLOYED
...このコマンドは、53個のCRDをkube-apiserverにコミットし、Istioメッシュで使用できるようにします。 また、istio-systemと呼ばれるIstioオブジェクトのnamespaceを作成し、--nameオプションを使用してヘルムにreleaseistio-initという名前を付けます。 Helmのリリースは、特定の構成オプションが有効になっているチャートの特定の展開を指します。
必要なすべてのCRDがコミットされたことを確認するには、次のコマンドを実行します。
kubectl get crds | grep 'istio.io\|certmanager.k8s.io' | wc -lこれにより、数値53が出力されます。
これで、istioチャートをインストールできます。 Grafanaテレメトリアドオンがチャートとともにインストールされていることを確認するために、helm installコマンドで--set grafana.enabled=true構成オプションを使用します。 また、目的のconfiguration profileのインストールプロトコル（デフォルトプロファイル）を使用します。 Istioには、Helmを使用してインストールするときに選択できる構成プロファイルがいくつかあり、Istiocontrol plane and data plane sidecarsをカスタマイズできます。 デフォルトのプロファイルは、実稼働環境への展開に推奨されます。これを使用して、実稼働環境に移行するときに使用する構成オプションについて理解します。
次のhelm installコマンドを実行して、チャートをインストールします。
helm install --name istio --namespace istio-system --set grafana.enabled=true istio.io/istioOutputNAME: istio
LAST DEPLOYED: Fri Jun 7 17:18:33 2019
NAMESPACE: istio-system
STATUS: DEPLOYED
...ここでも、Istioオブジェクトをistio-system名前空間にインストールし、リリースに名前を付けています（この場合はistio）。
次のコマンドを使用して、デフォルトプロファイルに期待されるService objectsが作成されていることを確認できます。
kubectl get svc -n istio-systemここで期待されるサービスには、istio-citadel、istio-galley、istio-ingressgateway、istio-pilot、istio-policy、istio-sidecar-injector、istio-telemetryが含まれます。 、およびprometheus。 インストール中にこのアドオンを有効にしたので、grafanaサービスも表示されるはずです。
OutputNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
grafana ClusterIP 10.245.85.162 3000/TCP 3m26s
istio-citadel ClusterIP 10.245.135.45 8060/TCP,15014/TCP 3m25s
istio-galley ClusterIP 10.245.46.245 443/TCP,15014/TCP,9901/TCP 3m26s
istio-ingressgateway LoadBalancer 10.245.171.39 174.138.125.110 15020:30707/TCP,80:31380/TCP,443:31390/TCP,31400:31400/TCP,15029:30285/TCP,15030:31668/TCP,15031:32297/TCP,15032:30853/TCP,15443:30406/TCP 3m26s
istio-pilot ClusterIP 10.245.56.97 15010/TCP,15011/TCP,8080/TCP,15014/TCP 3m26s
istio-policy ClusterIP 10.245.206.189 9091/TCP,15004/TCP,15014/TCP 3m26s
istio-sidecar-injector ClusterIP 10.245.223.99 443/TCP 3m25s
istio-telemetry ClusterIP 10.245.5.215 9091/TCP,15004/TCP,15014/TCP,42422/TCP 3m26s
prometheus ClusterIP 10.245.100.132 9090/TCP 3m26s 次のコマンドを使用して、対応するIstioPodsを確認することもできます。
kubectl get pods -n istio-systemこれらのサービスに対応するポッドには、RunningのSTATUSが必要です。これは、ポッドがノードにバインドされており、ポッドに関連付けられたコンテナーが実行されていることを示します。
OutputNAME READY STATUS RESTARTS AGE
grafana-67c69bb567-t8qrg 1/1 Running 0 4m25s
istio-citadel-fc966574d-v5rg5 1/1 Running 0 4m25s
istio-galley-cf776876f-5wc4x 1/1 Running 0 4m25s
istio-ingressgateway-7f497cc68b-c5w64 1/1 Running 0 4m25s
istio-init-crd-10-bxglc 0/1 Completed 0 9m29s
istio-init-crd-11-dv5lz 0/1 Completed 0 9m29s
istio-pilot-785694f946-m5wp2 2/2 Running 0 4m25s
istio-policy-79cff99c7c-q4z5x 2/2 Running 1 4m25s
istio-sidecar-injector-c8ddbb99c-czvwq 1/1 Running 0 4m24s
istio-telemetry-578b6f967c-zk56d 2/2 Running 1 4m25s
prometheus-d8d46c5b5-k5wmg 1/1 Running 0 4m25sREADYフィールドは、ポッド内で実行されているコンテナーの数を示します。 詳細については、documentation on Pod lifecyclesを参照してください。
[。注意]＃＃
Note:STATUS列に予期しないフェーズが表示された場合は、次のコマンドを使用してポッドのトラブルシューティングを行うことができることに注意してください。
kubectl describe pods your_pod -n pod_namespace
kubectl logs your_pod -n pod_namespaceIstioインストールの最後のステップは、Envoyプロキシの作成を有効にすることです。これは、メッシュで実行されているサービスにsidecarsとしてデプロイされます。
サイドカーは通常、既存のコンテナ環境に機能のレイヤーを追加するために使用されます。 Istioのmesh architectureは、メッシュのデータプレーンを構成するEnvoyサイドカーとコントロールプレーンのコンポーネント間の通信に依存しています。 メッシュが機能するためには、メッシュ内の各PodがEnvoyサイドカーも実行するようにする必要があります。
この目標を達成するには、manual sidecar injectionとautomatic sidecar injectionの2つの方法があります。 istio-injection=enabledというラベルのアプリケーションオブジェクトを作成する名前空間のlabelingによって、サイドカーの自動注入を有効にします。 これにより、MutatingAdmissionWebhookコントローラーがkube-apiserverへの要求をインターセプトし、特定のアクションを実行できるようになります。この場合、すべてのアプリケーションポッドがサイドカーで始まるようになります。
default名前空間を使用してアプリケーションオブジェクトを作成するため、次のコマンドを使用して、istio-injection=enabledラベルをその名前空間に適用します。
kubectl label namespace default istio-injection=enabled以下を実行することで、コマンドが意図したとおりに機能したことを確認できます。
kubectl get namespace -L istio-injection次の出力が表示されます。
OutputAME STATUS AGE ISTIO-INJECTION
default Active 47m enabled
istio-system Active 16m
kube-node-lease Active 47m
kube-public Active 47m
kube-system Active 47mIstioをインストールして構成したら、アプリケーションサービスとDeploymentオブジェクトの作成に進むことができます。
[[step-3 -—- creating-application-objects]] ==ステップ3—アプリケーションオブジェクトの作成
Istioメッシュを配置し、サイドカーポッドを挿入するように構成すると、ServiceオブジェクトとDeploymentオブジェクト用にspecificationsを使用してアプリケーションmanifestを作成できます。 Kubernetesマニフェストの仕様は、各オブジェクトの望ましい状態を記述します。
アプリケーションサービスは、個々のPodが作成および破棄されるときに、コンテナを実行するPodが動的環境でアクセス可能な状態を維持するようにし、DeploymentはPodの望ましい状態を記述します。
nanoまたはお気に入りのエディターでnode-app.yamlというファイルを開きます。
nano node-app.yamlまず、次のコードを追加して、nodejsアプリケーションサービスを定義します。
~/istio_project/node-app.yaml
apiVersion: v1
kind: Service
metadata:
name: nodejs
labels:
app: nodejs
spec:
selector:
app: nodejs
ports:
- name: http
port: 8080このサービス定義には、ポッドを対応するapp: nodejsラベルと一致させるselectorが含まれています。 また、サービスが、一致するラベルを持つ任意のポッドのポート8080をターゲットにするように指定しました。
また、Istioのrequirements for Pods and Servicesに準拠して、サービスポートに名前を付けています。 http値は、Istioがnameフィールドに受け入れる値の1つです。
次に、サービスの下に、アプリケーションの展開に関する次の仕様を追加します。 containers仕様の下にリストされているimageを、作成してStep 1でDockerHubにプッシュしたイメージに必ず置き換えてください。
~/istio_project/node-app.yaml
...
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: nodejs
labels:
version: v1
spec:
replicas: 1
selector:
matchLabels:
app: nodejs
template:
metadata:
labels:
app: nodejs
version: v1
spec:
containers:
- name: nodejs
image: your_dockerhub_username/node-demo
ports:
- containerPort: 8080このデプロイメントの仕様には、replicasの数（この場合は1）と、デプロイメントが管理するポッドを定義するselectorが含まれます。 この場合、app: nodejsラベルでポッドを管理します。
templateフィールドには、次のことを行う値が含まれています。
-
デプロイメントによって管理されるポッドに
app: nodejsラベルを適用します。 Istiorecommendsは、展開仕様にappラベルを追加して、Istioのメトリックとテレメトリのコンテキスト情報を提供します。 -
versionラベルを適用して、このデプロイメントに対応するアプリケーションのバージョンを指定します。appラベルと同様に、Istioは、コンテキスト情報を提供するためにversionラベルを含めることをお勧めします。 -
コンテナ
nameとimageを含め、ポッドが実行されるコンテナの仕様を定義します。 ここでのimageは、Step 1で作成し、DockerHubにプッシュしたイメージです。 コンテナーの仕様には、各コンテナーがリッスンするポートを指すcontainerPort構成も含まれています。 ポートがここにリストされていない場合、Istioプロキシをバイパスします。 このポート8080は、サービス定義で指定されたターゲットポートに対応することに注意してください。
編集が終了したら、ファイルを保存して閉じます。
このファイルを配置したら、GatewayオブジェクトとVirtual Serviceオブジェクトの定義を含むファイルの編集に移ります。これらのオブジェクトは、トラフィックがメッシュに入る方法と、そこで一度ルーティングされる方法を制御します。
[[step-4 -—- creating-istio-objects]] ==ステップ4—Istioオブジェクトの作成
クラスターへのアクセスとサービスへのルーティングを制御するために、Kubernetesは入力ResourcesとControllersを使用します。 イングレスリソースは、クラスターサービスへのHTTPおよびHTTPSルーティングのルールを定義しますが、コントローラーは着信トラフィックの負荷を分散し、正しいサービスにルーティングします。
Ingressリソースとコントローラーの使用の詳細については、How to Set Up an Nginx Ingress with Cert-Manager on DigitalOcean Kubernetesを参照してください。
Istioは、いくつかの重要な違いはありますが、異なるオブジェクトのセットを使用して同様の目的を達成します。 コントローラーを使用してトラフィックの負荷を分散する代わりに、IstioメッシュはGatewayを使用します。これは、着信および発信HTTP / TCP接続を処理するロードバランサーとして機能します。 次に、ゲートウェイは、メッシュに入るトラフィックに監視ルールとルーティングルールを適用できます。 具体的には、トラフィックルーティングを決定する構成は、仮想サービスとして定義されます。 各仮想サービスには、特定のプロトコルと宛先の基準に一致するルーティングルールが含まれます。
Kubernetes Ingressリソース/コントローラーとIstioゲートウェイ/仮想サービスにはいくつかの機能上の類似点がありますが、メッシュの構造には重要な違いがあります。 たとえば、Kubernetes Ingressリソースおよびコントローラーはオペレーターにいくつかのルーティングオプションを提供しますが、ゲートウェイおよび仮想サービスはトラフィックがメッシュに入ることを可能にするため、より堅牢な機能セットを使用可能にします。 つまり、Kubernetes Ingress Controllers and Resourcesがクラスターオペレーターに提供する制限されたapplication layer機能には、Istioサービスメッシュのサイドカーによって提供される高度なルーティング、トレース、テレメトリなどの機能が含まれていません。
メッシュへの外部トラフィックを許可し、Nodeアプリへのルーティングを構成するには、Istio GatewayとVirtual Serviceを作成する必要があります。 マニフェストのnode-istio.yamlというファイルを開きます。
nano node-istio.yamlまず、Gatewayオブジェクトの定義を追加します。
~/istio_project/node-isto.yaml
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: nodejs-gateway
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "*"ゲートウェイのnameをmetadataフィールドに指定することに加えて、次の仕様が含まれています。
-
このリソースを、Istioのインストール時に選択したconfiguration profileで有効にされたデフォルトのIstio IngressGatewayコントローラーと一致する
selector。 -
入力に対して公開する
portと、ゲートウェイによって公開されるhostsを指定するservers仕様。 この場合、特定の保護されたドメインで作業していないため、すべてのhostsにアスタリスク（*）を付けて指定しています。
ゲートウェイ定義の下に、仮想サービスの仕様を追加します。
~/istio_project/node-istio.yaml
...
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: nodejs
spec:
hosts:
- "*"
gateways:
- nodejs-gateway
http:
- route:
- destination:
host: nodejsこの仮想サービスにnameを提供することに加えて、次のようなこのリソースの仕様も含まれています。
-
宛先ホストを指定する
hostsフィールド。 この場合も、ドメインを使用していないため、ワイルドカード値（*）を使用して、ブラウザーでアプリケーションにすばやくアクセスできるようにしています。 -
外部要求が許可されるゲートウェイを指定する
gatewaysフィールド。 この場合、それはnodejs-gatewayゲートウェイです。 -
HTTPトラフィックのルーティング方法を指定する
httpフィールド。 -
リクエストがルーティングされる場所を示す
destinationフィールド。 この場合、nodejsサービスにルーティングされ、Kubernetes環境のサービスの完全修飾ドメイン名（FQDN）に暗黙的に展開されます：nodejs.default.svc.cluster.local。 ただし、FQDNはサービスではなく、ruleが定義されている名前空間に基づいていることに注意してください。したがって、アプリケーションサービスと仮想サービスが異なる場合は、このフィールドでFQDNを使用してください。名前空間。 Kubernetesドメインネームシステム（DNS）についてより一般的に学ぶには、An Introduction to the Kubernetes DNS Serviceを参照してください。
編集が終了したら、ファイルを保存して閉じます。
yamlファイルを配置すると、アプリケーションのサービスとデプロイメント、およびアプリケーションへのアクセスを可能にするゲートウェイオブジェクトと仮想サービスオブジェクトを作成できます。
[[step-5 -—- creating-application-resources-and-enabling-telemetry-access]] ==ステップ5—アプリケーションリソースの作成とテレメトリアクセスの有効化
アプリケーションサービスとデプロイメントオブジェクトをゲートウェイと仮想サービスとともに作成すると、アプリケーションへのリクエストを生成し、Istio Grafanaダッシュボードで関連データを確認できるようになります。 ただし、最初に、ブラウザでダッシュボードにアクセスできるようにGrafanaアドオンを公開するようにIstioを構成する必要があります。
enable Grafana access with HTTPを使用しますが、実稼働環境または機密性の高い環境で作業している場合は、enable access with HTTPSを使用することを強くお勧めします。
IstioをStep 2にインストールするときに--set grafana.enabled=true構成オプションを設定したため、istio-system名前空間にGrafanaサービスとポッドがあります。これはそのステップで確認しました。
これらのリソースが既に配置されているので、次のステップは、Grafanaアドオンを公開できるように、ゲートウェイと仮想サービスのマニフェストを作成することです。
マニフェストのファイルを開きます。
nano node-grafana.yaml次のコードをファイルに追加して、トラフィックを公開してGrafanaサービスにルーティングするゲートウェイと仮想サービスを作成します。
~/istio_project/node-grafana.yaml
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: grafana-gateway
namespace: istio-system
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 15031
name: http-grafana
protocol: HTTP
hosts:
- "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: grafana-vs
namespace: istio-system
spec:
hosts:
- "*"
gateways:
- grafana-gateway
http:
- match:
- port: 15031
route:
- destination:
host: grafana
port:
number: 3000Grafanaゲートウェイと仮想サービスの仕様は、アプリケーションゲートウェイと仮想サービスに対してStep 4で定義したものと同様です。 ただし、いくつかの違いがあります。
-
Grafanaは、ポート（ポート
15031）という名前のhttp-grafanaで公開され、ホストのポート3000で実行されます。 -
ゲートウェイと仮想サービスはどちらも
istio-system名前空間で定義されています。 -
この仮想サービスの
hostは、istio-system名前空間のgrafanaサービスです。 Grafanaサービスが実行されているのと同じネームスペースでこのルールを定義しているため、FQDN拡張は競合することなく再び機能します。
[.note]＃Note:現在のMeshPolicyはpermissive modeでTLSを実行するように構成されているため、マニフェストにDestination Ruleを適用する必要はありません。 Istioインストールで別のプロファイルを選択した場合は、HTTPを使用したGrafanaへのアクセスを有効にするときに、相互TLSを無効にする宛先ルールを追加する必要があります。 これを行う方法の詳細については、HTTPを使用したテレメトリアドオンへのアクセスの有効化に関するofficial Istio documentaionを参照できます。
＃
編集が終了したら、ファイルを保存して閉じます。
次のコマンドを使用してGrafanaリソースを作成します。
kubectl apply -f node-grafana.yamlkubectl applyコマンドを使用すると、オブジェクトを作成または更新する過程で、特定の構成をオブジェクトに適用できます。 この例では、node-grafana.yamlファイルで指定した構成を、ゲートウェイオブジェクトと仮想サービスオブジェクトの作成プロセスで適用しています。
次のコマンドを使用して、istio-system名前空間のゲートウェイを確認できます。
kubectl get gateway -n istio-system次の出力が表示されます。
OutputNAME AGE
grafana-gateway 47s仮想サービスについても同じことができます。
kubectl get virtualservice -n istio-systemOutputNAME GATEWAYS HOSTS AGE
grafana-vs [grafana-gateway] [*] 74sこれらのリソースが作成されると、ブラウザーでGrafanaダッシュボードにアクセスできるはずです。 ただし、その前に、アプリケーションゲートウェイと仮想サービスとともにアプリケーションサービスと展開を作成し、ブラウザでアプリケーションにアクセスできることを確認しましょう。
次のコマンドを使用して、アプリケーションのサービスと展開を作成します。
kubectl apply -f node-app.yaml数秒待ってから、次のコマンドでアプリケーションポッドを確認します。
kubectl get podsOutputNAME READY STATUS RESTARTS AGE
nodejs-7759fb549f-kmb7x 2/2 Running 0 40sSTATUS列に示されているように、アプリケーションコンテナーは実行されていますが、Step 3からのアプリケーションマニフェストが1つのレプリカのみを指定している場合、READY列に2/2が表示されるのはなぜですか？
この2番目のコンテナーはEnvoyサイドカーであり、次のコマンドで検査できます。 ここにリストされているポッドを、必ず独自のnodejsポッドのNAMEに置き換えてください。
kubectl describe pod nodejs-7759fb549f-kmb7xOutputName: nodejs-7759fb549f-kmb7x
Namespace: default
...
Containers:
nodejs:
...
istio-proxy:
Container ID: docker://f840d5a576536164d80911c46f6de41d5bc5af5152890c3aed429a1ee29af10b
Image: docker.io/istio/proxyv2:1.1.7
Image ID: docker-pullable://istio/proxyv2@sha256:e6f039115c7d5ef9c8f6b049866fbf9b6f5e2255d3a733bb8756b36927749822
Port: 15090/TCP
Host Port: 0/TCP
Args:
...次に、アプリケーションゲートウェイと仮想サービスを作成します。
kubectl apply -f node-istio.yaml次のコマンドでゲートウェイを検査できます。
kubectl get gatewayOutputNAME AGE
nodejs-gateway 7sそして、仮想サービス：
kubectl get virtualserviceOutputNAME GATEWAYS HOSTS AGE
nodejs [nodejs-gateway] [*] 28sこれで、アプリケーションへのアクセスをテストする準備ができました。 これを行うには、LoadBalancer Service typeであるistio-ingressgatewayサービスに関連付けられた外部IPが必要になります。
次のコマンドを使用して、istio-ingressgatewayサービスの外部IPを取得します。
kubectl get svc -n istio-system次のような出力が表示されます。
OutputNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
grafana ClusterIP 10.245.85.162 3000/TCP 42m
istio-citadel ClusterIP 10.245.135.45 8060/TCP,15014/TCP 42m
istio-galley ClusterIP 10.245.46.245 443/TCP,15014/TCP,9901/TCP 42m
istio-ingressgateway LoadBalancer 10.245.171.39 ingressgateway_ip 15020:30707/TCP,80:31380/TCP,443:31390/TCP,31400:31400/TCP,15029:30285/TCP,15030:31668/TCP,15031:32297/TCP,15032:30853/TCP,15443:30406/TCP 42m
istio-pilot ClusterIP 10.245.56.97 15010/TCP,15011/TCP,8080/TCP,15014/TCP 42m
istio-policy ClusterIP 10.245.206.189 9091/TCP,15004/TCP,15014/TCP 42m
istio-sidecar-injector ClusterIP 10.245.223.99 443/TCP 42m
istio-telemetry ClusterIP 10.245.5.215 9091/TCP,15004/TCP,15014/TCP,42422/TCP 42m
prometheus ClusterIP 10.245.100.132 9090/TCP 42m istio-ingressgatewayは、TYPELoadBalancerを持つ唯一のサービスであり、外部IPを持つ唯一のサービスである必要があります。
ブラウザで次の外部IPに移動します：http://ingressgateway_ip。
次のランディングページが表示されます。
次に、[更新]を5〜6回クリックして、サイトへの負荷を生成します。
Grafanaダッシュボードで交通量データを確認できるようになりました。
ブラウザで、istio-ingressgateway外部IPとGrafana Gatewayマニフェストで定義したポートを使用して次のアドレスに移動します：http://ingressgateway_ip:15031。
次のランディングページが表示されます。
ページ上部のHomeをクリックすると、istioフォルダーのあるページが表示されます。 ドロップダウンオプションのリストを取得するには、istioフォルダーアイコンをクリックします。
このオプションのリストから、Istio Service Dashboardをクリックします。
これにより、別のドロップダウンメニューのあるランディングページが表示されます。
使用可能なオプションのリストからnodejs.default.svc.cluster.localを選択します。
これで、そのサービスのトラフィックデータを確認できるようになります。
Grafanaが有効化され、外部アクセス用に構成されたIstioサービスメッシュで動作するNode.jsアプリケーションが機能するようになりました。
結論
このチュートリアルでは、Helmパッケージマネージャーを使用してIstioをインストールし、それを使用して、ゲートウェイおよび仮想サービスオブジェクトを使用してNode.jsアプリケーションサービスを公開しました。 また、アプリケーションのトラフィックデータを調べるために、Grafanaテレメトリアドオンを公開するようにGatewayおよびVirtual Serviceオブジェクトを構成しました。
本番環境に移行するときは、securing your application Gateway with HTTPSのような手順を実行し、Grafanaサービスへのアクセスもsecureであることを確認する必要があります。
collecting and processing metrics、logs、trace spansなど、他のtelemetry-related tasksを調べることもできます。