導入
静的ルートオペレータの主な目的は、Kubernetes環境におけるネットワークトラフィックの柔軟性と制御性を高めることです。これにより、アプリケーション要件に合わせてルーティング設定を微調整し、ネットワークパフォーマンスを最適化できます。このオペレータはDaemonSetとしてデプロイされるため、DigitalOceanが管理するKubernetesクラスターのすべてのノードで実行されます。.
このチュートリアルでは、CRD 仕様に基づいて各ワーカー ノードのルーティング テーブルを管理し、フェイルオーバー ゲートウェイを設定する方法を学習します。.
このチュートリアルの主な目的は、CRD 仕様に基づいて各ワーカーノードのルーティング テーブルを管理し、フェイルオーバー ゲートウェイを設定する方法を示すことです。.
前提条件
- アクセスできる DigitalOcean 管理の Kubernetes クラスター。.
- ローカルマシンにインストールされた Kubectl CLI (DigitalOcean が管理する Kubernetes クラスターを指すように構成)
- NAT GW ドロップレット (2 以上) は、ここで詳述されているとおりに構成および実装されます。.
- ゲートウェイドロップレットの障害検知システムを構築し、ユーザーのニーズに合わせてカスタマイズすることで、誤報を最小限に抑え、明確かつ正確な検知を実現します。PrometheusやNagiosなどの監視サービス、ドロップレットにヘルスチェックエンドポイントの設定、Alertmanagerなどのアラートツールによる通知などを活用しましょう。この目的のために、マーケットプレイスから利用可能な監視スタックをご利用いただけます。.
以下はアーキテクチャ図です。
Kubernetes 静的ルート オペレーターのデプロイ
kubectl を使用して、最新バージョンの静的ルート オペレーターを DigitalOcean が管理する Kubernetes クラスターにデプロイします。
kubectl apply -f https://raw.githubusercontent.com/digitalocean/k8s-staticroute-operator/main/releases/v1/k8s-staticroute-operator-v1.0.0.yaml
Operator Pod が稼働していることを確認します。
オペレーター ポッドが稼働しているかどうかを確認しましょう。.
“「bash kubectl get staticroutes -o wide -n staticroutes」
The output looks similar to the below:
```bash
[secondary_label Output]
NAME AGE DESTINATIONS GATEWAY
static-route-ifconfig.me 119s ["XX.XX.XX.XX"] XX.XX.XX.XX
static-route-ipinfo.io 111s ["XX.XX.XX.XX"] XX.XX.XX.XX次に、オペレータレポートをチェックしてみましょう。例外は報告されないはずです。
kubectl logs -f ds/k8s-staticroute-operator -n static-routes
次の出力が表示されるはずです。
Output
Found 2 pods, using pod/k8s-staticroute-operator-498vv
[2023-05-15 14:12:32,282] kopf._core.reactor.r [DEBUG ] Starting Kopf 1.35.6.
[2023-05-15 14:12:32,282] kopf._core.engines.a [INFO ] Initial authentication has been initiated.
[2023-05-15 14:12:32,283] kopf.activities.auth [DEBUG ] Activity 'login_via_pykube' is invoked.
[2023-05-15 14:12:32,285] kopf.activities.auth [DEBUG ] Pykube is configured in cluster with service account.
[2023-05-15 14:12:32,286] kopf.activities.auth [INFO ] Activity 'login_via_pykube' succeeded.
[2023-05-15 14:12:32,286] kopf.activities.auth [DEBUG ] Activity 'login_via_client' is invoked.
[2023-05-15 14:12:32,287] kopf.activities.auth [DEBUG ] Client is configured in cluster with service account.
[2023-05-15 14:12:32,288] kopf.activities.auth [INFO ] Activity 'login_via_client' succeeded.
[2023-05-15 14:12:32,288] kopf._core.engines.a [INFO ] Initial authentication has finished.
[2023-05-15 14:12:32,328] kopf._cogs.clients.w [DEBUG ] Starting the watch-stream for customresourcedefinitions.v1.apiextensions.k8s.io cluster-wide.
[2023-05-15 14:12:32,330] kopf._cogs.clients.w [DEBUG ] Starting the watch-stream for staticroutes.v1.networking.digitalocean.com cluster-wide.ゲートウェイ障害の影響を軽減するため、必要に応じてフェイルオーバーを実行できるスタンバイゲートウェイを用意しておくことをお勧めします。現在、真の高可用性（HA）は運用者によってサポートされていませんが、フェイルオーバーを実行することで、サービス中断期間を最小限に抑えることができます。.
例えば、トラフィックの転送を担当するアクティブまたはプライマリゲートウェイを表す宛先IPアドレス34.160.111.145（IPアドレス10.116.0.4）があるとします。これはprimar.yamlファイルに保存されています。.
apiVersion: networking.digitalocean.com/v1
kind: StaticRoute
metadata:
name: primary
spec:
destinations:
- "34.160.111.145"
gateway: "10.116.0.4"さらに、IPアドレス10.116.0.12を持つスタンバイまたはセカンダリゲートウェイが、同じ宛先IPアドレスからのトラフィックを処理できるようになります。secondary.yamlのStaticRoute定義は、ゲートウェイIPアドレス（およびオブジェクト名）を除いて、プライマリの定義と同一です。これはsecondary.yamlファイルに保存されます。.
apiVersion: networking.digitalocean.com/v1
kind: StaticRoute
metadata:
name: secondary
spec:
destinations:
- "34.160.111.145"
gateway: "10.116.0.12"実際の障害プロセスには次の手順が含まれます。
- IP アドレス 10.116.0.5 のアクティブ ゲートウェイがダウンしていることを検出します。.
- 現在アクティブな StaticRoute を削除します。.
- 既製の StaticRoute を適用します。.
アクティブなスタティックルートを削除する
ここで、現在アクティブな StaticRoute を削除しましょう。.
kubectl delete -f primary.yaml
各オペレータインスタンスがオブジェクトの削除を処理するのに十分な時間を確保するため、30～60秒待機してください。つまり、すべてのノードからパスを削除することで応答します。.
スタンバイスタティックルートを適用する
セカンダリ StaticRoute を有効にしましょう。.
kubectl apply -f secondary.yaml
オペレータは新しいスタンバイStaticRouteを選択し、対応するルーティングテーブルエントリを挿入する必要があります。これでフェイルオーバーは完了です。.
セットアップテスト
各CRDインスタンスは、パブリックIPアドレスを報告する2つのウェブサイト（ifconfig.me/ipとipinfo.io/ip）への静的ルートを作成します。典型的な静的ルートの定義は次のようになります。
apiVersion: networking.digitalocean.com/v1
kind: StaticRoute
metadata:
name: static-route-ifconfig.me
spec:
destinations:
- "34.160.111.145"
gateway: "10.116.0.5"設定をテストするには、次の例の場所からサンプル マニフェストをダウンロードします。
ifconfig.meとipinfo.ioの例-
curl -O https://raw.githubusercontent.com/digitalocean/k8s-staticroute-operator/main/examples/static-route-ifconfig.me.yaml
curl -O https://raw.githubusercontent.com/digitalocean/k8s-staticroute-operator/main/examples/static-route-ipinfo.io.yaml
マニフェストをダウンロードしたら、各マニフェストファイルを<>で置き換えます。その後、kubectlを使用して各マニフェストを適用します。
kubectl apply -f static-route-ifconfig.me.yaml
kubectl apply -f static-route-ipinfo.io.yaml
最後に、curl-test ポッドが各ルートの NAT ゲートウェイのパブリック IP に応答するかどうかを確認します。
kubectl exec -it curl-test -- curl ifconfig.me/ip
kubectl exec -it curl-test -- curl ipinfo.io/ipフェイルオーバーテストでも同じテストを使用する必要があります。プライマリゲートウェイのドロップレットフェイルオーバー中は、結果からNATゲートウェイにプライマリドロップレットのパブリックIPが与えられ、セカンダリドロップレット/フェイルオーバー中は、結果からセカンダリドロップレットNATゲートウェイのパブリックIPが与えられるはずです。.
トラブルシューティング
StaticRoute オブジェクトを確認する必要があります。エラーが発生した場合は、まず、ルールが適用される各ノードの静的ルート イベントでエラーを探します。.
kubectl get StaticRoute <static-route-name> -o yaml
ログを確認する: さらに詳しく調べるには、静的ルート オペレータのログでエラーを確認します。.
kubectl logs -f ds/k8s-staticroute-operator -n static-routes
消去
オペレーターと関連リソースを削除するには、次の kubectl コマンドを実行してください (インストール時に使用したものと同じリリース バージョンを使用してください)。
kubectl delete -f deploy https://raw.githubusercontent.com/digitalocean/k8s-staticroute-operator/main/releases/v1/k8s-staticroute-operator-v1.0.0.yaml
出力は次のようになります:
customresourcedefinition.apiextensions.k8s.io "staticroutes.networking.digitalocean.com" deleted
serviceaccount "k8s-staticroute-operator" deleted
clusterrole.rbac.authorization.k8s.io "k8s-staticroute-operator" deleted
clusterrolebinding.rbac.authorization.k8s.io "k8s-staticroute-operator" deleted
daemonset.apps "k8s-staticroute-operator" deletedここで、同じ curl コマンドをテストすると、ワーカー ノードの IP が出力として取得されます。
kubectl exec -it curl-test -- curl ifconfig.me/ip
kubectl exec -it curl-test -- curl ipinfo.io/ip
次に、ワーカー ノードのパブリック IP を確認します。
kubectl get nodes -o wide
結果
真の高可用性 (HA) が完全にサポートされていない場合でも、ゲートウェイ障害の影響を最小限に抑えるには、フェイルオーバー機能を実装することをお勧めします。.
組織は、必要に応じてフェイルオーバーできるスタンバイ ゲートウェイを用意することで、サービス中断の期間を大幅に短縮できます。.
バックアップゲートウェイを用意し、障害発生時にスムーズな移行を確保することが重要です。実装方法は具体的なニーズによって異なりますが、障害への対応を優先することで、信頼性の高い中断のないサービス提供を維持できます。.
