物理マシンをVMとは異なるレベルで仮想化を可能にするコンテナ仮想化（Container Virtualization）技術が、マイクロサービスの活性化と合わせて運用環境で導入が増え続けています。しかし、コンテナ層はOSから実行環境を隔離した状態で提供されるため、運用面から見ると小規模サービスに導入し易いですが、実際に大規模サービスに導入するには課題が多くあります。例えば、“図1”のように運用担当者がマルチコンテナを運用するときにはヒューマンエラーが発生する可能性があります。

この問題を解決するためにコンテナ化されたワークロードやサービスを管理するためのオーケストレーションツールがあります。システム運用担当者は“図2”のようにオーケストレーションツールを利用すると、マルチコンテナを簡単に管理できるようになります。また、大規模サービスへのコンテナ技術の導入もより活発になりました。

このような運用環境の変更は、クラウドサービスを提供するベンダーはいち早く自社の製品に取り入れています。何故なら、オーケストレーションツールがあっても、コンテナ技術が活性化されるインフラは必須だからです。
クラウドサービスベンダーは既存の仮想インフラ環境の上にk8sサービスだけを乗せることで完璧なコンテナサービスを提供できます。これはクラウドサービスが強調する“インフラ管理費用の節減”になります。現在、この流れを反映した代表的なものでは、AzureのAKS、GCPのGKE、AWSのEKSサービスなどがあります。

JENNIFERエージェントのk8sサポート

参考：
本ドキュメントはAKS環境を例に説明しますが、JENNIFERはk8sをサポートすることで他の環境（GKE、EKSなど）もサポート可能です。また、様々なコンテナ技術がありますが、本ドキュメントではdockerを対象に説明します。

JENNIFERエージェントがk8sをサポートする構造は、基本的にコンテナ環境をサポートすることと異なりません。エージェントの実行ファイルと環境変数の設定をコンテナに伝達する方法が必要ですが、JENNIFERエージェントは次の2つの方法によりdocker環境で活性化されます。

①　実行時にJENNIFERエージェントのバイナリがあるボリュームと環境変数を指定

②　既存のコンテナのDockerfileにJENNIFERエージェントのバイナリと環境変数を含めてビルド

k8sオーケストレーションツールはコンテナを一つの層にラッピングしてPod単位に配布する方法で、JENNIFERエージェントのk8sサポートの方法は上記の2つの方法と同じです。2つ目の方法はk8s環境でもそのまま利用できます。

しかし、ボリューム連携はコンテナに直接に連携する既存の構造とは異なり、コンテナの集合でもあるPodと繋がる特徴から、k8sが定めたPV(Persistent Volume)でJENNIFERエージェントのバイナリとコンテナを繋げます。

JENNIFERエージェントのバイナリが入ったボリュームを準備して、各サービスを配布するためのyamlファイル内にPVと繋がるvolumesとenv設定を追加します。

1.	apiVersion: apps/v1
2.	kind: Deployment
3.	metadata:
4.	　　　　name: net-razor31-sample
5.	...[省略]...
6.	spec:
7.	　　　　...[省略]...
8.	　　　　template:
9.	　　　　　　　　...[省略]...
10.	　　　　　　　　spec:
11.	　　　　　　　　　　　　containers:
12.	　　　　　　　　　　　　　　　　...[省略]...
13.	　　　　　　　　　　　　　　　　env:
14.	　　　　　　　　　　　　　　　　- name: CORECLR_ENABLE_PROFILING
15.	　　　　　　　　　　　　　　　　　　　　value: "1"
16.	　　　　　　　　　　　　　　　　- name: CORECLR_PROFILER
17.	　　　　　　　　　　　　　　　　　　　　value: "{6C7CAF0F-D0E5-4274-A71B-6551761BBDC8}"
18.	　　　　　　　　　　　　　　　　- name: CORECLR_PROFILER_PATH
19.	　　　　　　　　　　　　　　　　　　　　value: "/netagent/bin/libAriesProfiler.so"
20.	　　　　　　　　　　　　　　　　- name: ARIES_SERVER_ADDRESS
21.	　　　　　　　　　　　　　　　　　　　　value: "127.0.0.1"
22.	　　　　　　　　　　　　　　　　- name: ARIES_SERVER_PORT
23.	　　　　　　　　　　　　　　　　　　　　value: "5000"
24.	　　　　　　　　　　　　　　　　- name: ARIES_DOMAIN_ID
25.	　　　　　　　　　　　　　　　　　　　　value: "1000"
26.	　　　　　　　　　　　　　　　　volumeMounts:
27.	　　　　　　　　　　　　　　　　- mountPath: "/netagent"
28.	　　　　　　　　　　　　　　　　　　　　name: volume
29.	　　　　　　　　　　　　volumes:
30.	　　　　　　　　　　　　　　　　- name: volume
31.	　　　　　　　　　　　　　　　　　　　　persistentVolumeClaim:
32.	　　　　　　　　　　　　　　　　　　　　　　　　claimName: my-agent-file

その後、kubectlを利用してyamlを適用すると正常なモニタリングが確認できます。

1.	$ kubectl apply -f demo.yaml

クラウドプラットフォームのメリットは、インフラを基盤にしたワーカーノードをk8sで自由に追加や削除ができることです。また、応用プログラムのPodインスタンス数を手動および自動でスケール（変更）できます。k8sの場合、オートスケールのため、Horizontal Pod Autoscaling（以下、hpa）をサポートしますが、AKSでも同じコマンドを利用できます。上位で配布した“demo.yaml”に対して1つのインスタンスを常に実行して、負荷に応じて最大3つまで実行させる場合は、次のように設定します。

1.	$ kubectl autoscale deployment --max=3 net-razor31-sample --min=1
2.	horizontalpodautoscaler.autoscaling/net-razor31-sample autoscaled
3.	$ kubectl get pod
4.	NAME READY STATUS RESTARTS AGE
5.	net-razor31-sample-6b747bb886-c2kgk 1/1 Running 0 116s

負荷が無くてもpodが1つ運用されますが、JENNIFERコンソールにない場合もあります。何故なら、Podが起動されることと内部の応用プログラムにリクエストがあることとは異なる場合があるからです。

当然、この状況で次のように負荷テストを行うと、

1.	$ docker run --name loadtest --rm -it azch/loadtest http://...[サービスURL]

3つのPodが自動的に起動されて次のJENNIFER画面でその結果を確認できます。