Kubernetesクラスターでmabl Linkを実行する場合は、Link Agentに必要なものがすべて含まれたmabl Link Dockerイメージを使用します。この記事では、Link AgentをKubernetesのデプロイメントとして実行する方法、割り当てるリソースの量、テストを中断せずに停止する方法について説明します。
開始する前に
次のものを用意してください。
- "Link Agent" のAPIキー。APIキーにアクセスできるのはワークスペースの所有者だけです。会社内のすべてのワークスペースで共有するトンネルには、会社キーを使用してください。会社スコープのLinkトンネルを参照してください。
- 英小文字、数字、ダッシュから成る1~24文字のトンネル名。
- Kubernetesのネームスペースの名前。
AWS Gravitonなどのarm64ノードでは、mablhq/link-agent:latest-ubuntuイメージを使用してください。デフォルトのmablhq/link-agent:latestイメージはAlpineバリアントで、x86-64向けにのみ公開されているため、arm64ノードでは実行できません。各バリアントについては、Dockerを用いたLinkの使用方法を参照してください。
APIキーをシークレットに保存する
APIキーはPodのspecではなく、Kubernetesのシークレットに保存してください。Podのspecに含めると、デプロイメントを読み取れるすべてのユーザーにキーが見えてしまいます。
kubectl create secret generic mabl-link-agent \
--namespace={your-namespace} \
--from-literal=api-key={your-api-key}
Link Agentをデプロイメントとして実行する
デプロイメントは、指定した数のLink Agentを実行し続け、停止したものを置き換えます。高可用性のために、replicasを2以上に設定してください。すべてのレプリカが同じトンネルを提供し、mablはそれらに接続を分散します。
次の例では、トンネルqa-env-01で2つのLink Agentを実行します。{your-namespace}はご自身のネームスペースに置き換えてください。
apiVersion: apps/v1
kind: Deployment
metadata:
name: mabl-link-agent
namespace: {your-namespace}
labels:
app: mabl-link-agent
spec:
replicas: 2
selector:
matchLabels:
app: mabl-link-agent
template:
metadata:
labels:
app: mabl-link-agent
spec:
# Longer than the Link Agent's own drain, so that running tests can finish
terminationGracePeriodSeconds: 90
containers:
- name: mabl-link-agent
image: mablhq/link-agent:latest
args:
- "--api-key"
- "$(MABL_LINK_API_KEY)"
- "--name"
- "qa-env-01"
env:
- name: MABL_LINK_API_KEY
valueFrom:
secretKeyRef:
name: mabl-link-agent
key: api-key
resources:
requests:
cpu: "2"
memory: "4Gi"
limits:
memory: "4Gi"
# No CPU limit: throttling the agent adds latency to every connection through it.
readinessProbe:
exec:
command:
- grep
- "^ready$"
- /opt/mabl/link-agent/run/status
initialDelaySeconds: 10
periodSeconds: 10
volumeMounts:
# The Link Agent's working files, which must stay writable on a read-only root filesystem
- name: link-agent-run
mountPath: /opt/mabl/link-agent/run
volumes:
- name: link-agent-run
emptyDir: {}
デプロイメントを作成するには、specをファイルに保存して適用します。
kubectl apply -f mabl-link-agent-deployment.yaml
# Optionally follow the logs of one of the agents
kubectl logs -f deployment/mabl-link-agent -n {your-namespace}
デプロイメントが起動しない場合は、kubectl describe podでPodのイベントを確認し、シークレットとネームスペースの名前が一致していることを確認してください。
リソースの選択
この例のリクエスト値は最小のホスト構成に相当し、同時利用の少ないトンネル1つに対応します。Podのサイズは、VMと同じ考え方で決めてください。
- メモリ: Podが提供するトンネルをまかなえるようにメモリ制限を設定します。Link Agentには約400 MBに加えて、トンネルごとに約500 MBが必要で、アップデートのインストール中はさらにトンネル1つ分が必要です。レガシーLinkからの移行中は、最大2 GBを追加で見込んでください。
- CPU: Podを通過するトラフィック150~200 Mb/sごとに約1コアを計画し、2コア未満のCPU制限は避けてください。CPUを制限されたトンネルでは、そのトンネルを通るすべての接続にレイテンシーが加わります。
- スケーリング: より多くのトラフィックを処理するには、1つのPodを大きくするのではなくレプリカを追加してください。そうすることで、1つのPodが置き換えられてもトンネルは動作し続けます。
詳しいガイダンスについては、Link Agentのサイジングとスケーリングを参照してください。
ネットワーク要件
Podには、api.mabl.comと、Linkトンネルエンドポイントのいずれか1つへの送信アクセスが必要です。クラスターの送信トラフィックでポート443の送信UDPが許可されている場合、Link Agentはより高速なQUICを使用します。許可されていない場合は、TCPポート443上のセキュアWebSocketを使用します。Link Agentの要件を参照してください。
mablは、Link Agent Podを実行する各ノードでソケットバッファー上限を引き上げることを推奨しています。上限を引き上げると、長いネットワーク経路でのトンネルのスループットが向上します。この上限はノードのカーネル設定であるため、Podではなく各ノードで適用してください。ホストのソケットバッファー上限を引き上げるを参照してください。
ルートファイルシステムが読み取り専用のクラスター
多くのクラスターでは、PodにreadOnlyRootFilesystem: trueの設定が求められます。多くの場合、これはすべてのワークロードに適用されるアドミッションポリシーによって強制されます。このようなクラスターでは、例にあるemptyDirボリュームを/opt/mabl/link-agent/runにマウントしたままにしてください。各Link 3.0トンネルは、トンネルプロセスと呼ばれる個別のプログラムとして実行されます。Link Agentはこのプログラムをそのディレクトリにダウンロードし、そこから実行します。そのため、このディレクトリは書き込み可能で、プログラムの実行も許可されている必要があります。デフォルトのemptyDirは、その両方を満たします。
Link AgentがレガシーLink経由では接続するもののLink 3.0経由では接続せず、ログにno writable, executable directory for the Link 3.0 workerと表示される場合は、ボリュームがないか、ボリュームでプログラムの実行が許可されていません。ボリュームが/opt/mabl/link-agent/runにマウントされていることを確認してください。
デフォルトのemptyDirはノードからマウントオプションを引き継ぐため、noexecでマウントするノードでは、Link Agentはそこからトンネルプロセスを実行できません。Link 3.0にはプログラムを実行できるディレクトリが必要なため、次のいずれかを選択してください。
-
クラスター管理者に例外を依頼する。 Link AgentのボリュームまたはPodを
noexecルールの対象外にしてもらいます。 -
メモリバックのボリュームを使用する。 Kubernetesは、
medium: Memoryを指定したemptyDirを、プログラムの実行を許可する形でマウントします。ボリュームの内容はPodのメモリ制限に含まれます。また、ボリュームにはトンネルごとに最大3つのバージョンのトンネルプロセス (それぞれ約175 MB) が保持されます。メモリ制限をトンネルごとに約600 MB引き上げ、同じ量をボリュームのsizeLimitに設定してください。 - クラスターの外部でLink Agentを実行する。 書き込み可能なディレクトリからのプログラムの実行を許可するVMまたはDockerホストで実行します。
たとえば、1つのトンネルを提供するPod用のメモリバックのボリュームは次のとおりです。
volumes:
- name: link-agent-run
emptyDir:
medium: Memory
sizeLimit: 600Mi
ルートファイルシステムが読み取り専用の場合、Link Agentはコンテナー内で自身をアップデートしたり、ログファイルを書き込んだりすることもできません。
-
アップデート: 新しいバージョンのLink Agentに移行するには、最新のイメージをプルし、
kubectl rollout restart deployment/mabl-link-agent -n {your-namespace}でデプロイメントを再起動します。イメージタグを固定している場合は、代わりにタグを変更してください。 -
ログ: Link Agentの出力は、引き続き
kubectl logsで確認できます。
その他のインストール方法でLink Agentが書き込むディレクトリについては、書き込み可能なディレクトリを参照してください。
Link接続の有効性の検証
Link Agent Podは、トンネルのセットアップが完了するとReadyを報告します。この例のレディネスプローブは、Link Agentのステータスファイル/opt/mabl/link-agent/run/statusを読み取ります。このファイルにはエージェントの現在のステータスが記録され、エージェントがmablに登録されてトンネルをセットアップするとreadyが含まれます。
エージェントがメンテナンスモードの間は、ステータスファイルに完了処理中であることが示されるため、メンテナンスを終了するまでPodは準備未完了を報告します。
トンネルがアクティブになると、mablアプリのネットワークページ (ワークスペース > ネットワーク) にも、Link Agentが接続済みのステータスで表示されます。
テストを中断せずにLink Agentを停止する
KubernetesがLink Agent Podを停止すると、エージェントは処理中の接続を完了させてから終了します。エージェントの処理が完了する前にKubernetesがPodを停止しないよう、terminationGracePeriodSecondsは90秒以上にしてください。デフォルトの30秒では、トンネル経由で実行中のテストが中断される可能性があります。
ノードのドレインなどの計画的な作業では、先に各Link Agentをメンテナンスモードにすることもできます。そうすると、エージェントの処理が完了するまでの間、新しいテストは他のレプリカに送られます。
mablアプリからKubernetesベースのLink Agentをシャットダウンすると、デプロイメントは指定されたレプリカ数を維持するため、数秒以内に代わりのエージェントを起動します。Link Agentを完全に停止するには、デプロイメントを削除してください。
kubectl delete deployment mabl-link-agent -n {your-namespace}
トンネルへのテストのルーティングを停止するには、mabl Linkトンネルの削除を参照してください。
次のステップ
Link Agentをインストールして実行したら、mabl Link経由で実行するようにテストを設定します。