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

关注

原创 2024-09-06 14:37:04 1.1k 阅读 AI 写同款· GEO 优化 ›

静态路由操作器的主要目的是提供更大的灵活性，并在 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