如何为 DigitalOcean 静态路由操作员设置故障转移

本文主要是介绍如何为 DigitalOcean 静态路由操作员设置故障转移，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

静态路由操作器的主要目的是提供更大的灵活性，并在 Kubernetes 环境中控制网络流量。它使你能够根据应用程序的需求自定义路由配置，从而优化网络性能。该操作器作为 DaemonSet 部署，因此将在你的 DigitalOcean Managed Kubernetes 集群的每个节点上运行。

在本教程中，你将学习如何根据 CRD 规范管理每个工作节点的路由表，并设置故障转移网关。

本教程的主要目标是演示如何根据 CRD 规范管理每个工作节点的路由表，并配置故障转移网关。

准备工作

• 你可以访问并且正常运行的 DigitalOcean 托管 Kubernetes 集群。
• 在本地计算机上安装了 Kubectl CLI，并已配置为指向你的 DigitalOcean 托管 Kubernetes 集群。
• 已配置并运行的 NAT GW Droplet（版本 2 或更高），详情请参见此处。

你需要创建一个系统来检测网关 Droplet 中的故障，该系统应符合你的需求，确保清晰准确的检测，并将误报率降至最低。可以使用 Prometheus 或 Nagios 等监控服务，在 Droplet 上设置健康检查端点，或使用 Alertmanager 等警报工具进行通知。为此，你可以使用我们市场中的监控堆栈。

注意：确保你的 NAT 网关 Droplet 在与你的 Kubernetes 集群相同的 VPC 中创建。

以下是架构图：

部署 Kubernetes 静态路由操作器

使用 kubectl 将最新版本的静态路由操作器部署到你的 DigitalOcean Managed Kubernetes 集群：

kubectl apply -f https://raw.githubusercontent.com/digitalocean/k8s-staticroute-operator/main/releases/v1/k8s-staticroute-operator-v1.0.0.yaml

注意：你可以从 k8s-staticroute-operator GitHub repo 的发布路径中检查最新版本。

检查 Operator Pod 是否已启动并正在运行：

让我们验证一下 Operator Pod 是否已启动并正在运行。

``bash kubectl get staticroutes -o wide -n staticroutes

The output looks similar to the below:

[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.

为了减轻网关故障的影响，建议在需要时准备一个备用网关 Droplet 以进行故障转移。尽管运营商目前不支持真正的高可用性 (HA)，但执行故障转移有助于最大限度地缩短服务中断的时间。

注意：考虑到故障转移时所有运营商实例都已启动并正常运行。

假设你有一个指定的目标 IP 地址 34.160.111.145，它代表活动或主网关，其 IP 地址为 10.116.0.4，负责传输流量。这存储在 primary.yaml 文件中。

./primary.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 文件中。

./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 的活动网关发生故障。
• 删除当前活动的静态路由。
• 应用备用静态路由。

删除活动静态路由

现在让我们删除当前活动的静态路由。

kubectl delete -f primary.yaml

等待 30 到 60 秒，让每个操作员实例有足够的时间来处理对象删除；也就是说，通过从所有节点删除路由来做出响应。

应用备用静态路由

让我们使辅助静态路由处于活动状态。

 kubectl apply -f secondary.yaml

操作员应选择新的备用 StaticRoute 并输入相应的路由表条目。此后，故障转移完成。

注意：请避免使用 kubectl edit staticroute primary 等命令直接更新网关 IP 地址来修改现有的 StaticRoute，而仅修改 spec.gateway 字段。此操作目前不受支持，可能会导致失败。

测试设置

每个示例 CRD 都会创建一条静态路由，通向两个报告您的公共 IP 的网站 - 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

最后，测试 curl-test pod 是否针对每个路由回复 NAT 网关公共 IP：

kubectl exec -it curl-test -- curl ifconfig.me/ip
kubectl exec -it curl-test -- curl ipinfo.io/ip

你需要在故障转移测试期间使用相同的测试。在主网关 Droplet 出现故障时，测试结果应显示主 Droplet 的 NAT 网关公共 IP，而在辅助网关 Droplet/故障转移期间，测试结果应显示辅助 Droplet 的 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

注意：上述命令还将删除关联的命名空间（静态路由）。请确保先备份你的 CRD，以备日后需要。

输出类似于：

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)，但实施故障转移功能仍然是将网关故障影响降至最低的推荐方法。

通过在需要时准备好备用网关进行故障转移，组织可以显著减少服务中断的持续时间。

准备备用网关 Droplet 并确保在故障转移时实现平稳过渡至关重要。虽然具体实施可能因要求不同而有所变化，但优先考虑故障转移准备有助于保持服务的可靠性和不间断交付。

如果你希望了解更多关于 DigitalOcean Kubernetes 和 Droplet 云主机的相关产品信息，欢迎访问 DigitalOcean 中国区独家战略合作伙伴卓普云官网，与他们交流、咨询。

这篇关于如何为 DigitalOcean 静态路由操作员设置故障转移的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---