跨集群服务实现Kubernetes应用的高可用-低调大师

跨集群服务实现Kubernetes应用的高可用

2018-12-15 469

我们在进行生产环境部署时得到的一个明确的需求，是Kubernetes用户希望服务部署能够zone、跨区域、跨集群甚至跨云边界（译者：如跨云供应商）。相比单集群多zone部署，跨集群服务提供按地域分布，支持混合云、多云场景，提升高可用等级。客户希望服务能够跨一到多个集群（可能是本地或者远程集群），并希望这些集群无论内部或外部都有一致稳定的连接。

在Kubernetes 1.3版本，我们希望降低跨集群跨地区服务部署相关的管理和运营难度。本文介绍如何实现此目标。

注意：虽然本文示例使用谷歌容器引擎（GKE）来提供Kubernetes集群，您可以在任何的其他环境部署Kubernetes。

我们正式开始。第一步是在谷歌的四个云平台地区通过GKE创建Kubernetes集群。

asia-east1-b
europe-west1-b
us-east1-b
us-central1-b

我们通过下面的命令创建集群：

gcloud container clusters create gce-asia-east1 \
--scopes cloud-platform \
--zone asia-east1-b
gcloud container clusters create gce-europe-west1 \
--scopes cloud-platform \
--zone=europe-west1-b
gcloud container clusters create gce-us-east1 \
--scopes cloud-platform \
--zone=us-east1-b
gcloud container clusters create gce-us-central1 \
--scopes cloud-platform \
--zone=us-central1-b

验证创建的集群：

gcloud container clusters list 
NAME ZONE MASTER_VERSION MASTER_IP NUM_NODES STATUS 
gce-asia-east1 asia-east1-b 1.2.4 104.XXX.XXX.XXX 3 RUNNING
gce-europe-west1 europe-west1-b 1.2.4 130.XXX.XX.XX 3 RUNNING
gce-us-central1 us-central1-b 1.2.4 104.XXX.XXX.XX 3 RUNNING 
gce-us-east1 us-east1-b 1.2.4 104.XXX.XX.XXX 3 RUNNING

下一步是起动集群并在创建的其中一个集群中部署联邦控制模块（Control Plane）。您可以参考和依照Kelsey Hightower的示例进行这步配置。

联邦服务

从联邦API获取信息，因此您可以通过联邦API制定服务属性。

当服务创建后，联邦服务自动进行如下操作：

在联邦中注册的所有Kubernetes集群中创建服务；
监控服务碎片（以及它们所在集群）的健康状况；
在公共DNS提供商上面创建 DNS记录（如谷歌Cloud DNS，或者AWS Route 53），以此确定你的服务客户端能够在任何时候无缝的获得相关的健康服务终端，即使当集群，可用区或者地区出现服务中断的情况时。

在注册到联邦的Kubernetes集群中的服务客户端，当联邦服务在本地集群碎片工作正常时，会优先使用本地服务碎片，否则会在最近的其他集群中选取健康的服务碎片。

Kubernetes集群联邦能够联合不同的云供应商（比如GCP、AWS）以及私有云（如OpenStack）。您只需在相应的云供应商和位置创建您的集群，并且将每个集群的API Server地址和证书信息注册到联邦集群中。

在我们的示例中，我们在四个区域创建了集群，并且在其中的一个集群中部署了联邦控制模块，我们会用这个环境来部署我们的服务。具体请参考下图。

创建联邦服务

我们先查看联邦中所有注册好的集群：

kubectl --context=federation-cluster get clusters
NAME STATUS VERSION AGE
gce-asia-east1 Ready 1m
gce-europe-west1 Ready 57s
gce-us-central1 Ready 47s
gce-us-east1 Ready 34s

创建联邦服务：

kubectl --context=federation-cluster create -f services/nginx.yaml

--context=federation-cluster参数通知kubectl把带相关证书信息的请求提交至联邦API服务器。联邦服务会自动在联邦中所有集群创建相应的Kubernetes服务。

你可以通过检查每一个集群中的服务进行验证，比如：

kubectl --context=gce-asia-east1a get svc nginx
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
nginx 10.63.250.98 104.199.136.89 80/TCP 9m

上面的命令假设你有一个名为gce-asia-east1a的kubectl的上下文设置，并且你有集群部署在这个区（zone）。Kubernetes服务的名字和名空间自动与你上面创建的集群服务一致。

联邦服务状态会实时体现Kubernetes对应的服务状态，例如：

kubectl --context=federation-cluster describe services nginx
Name: nginx
Namespace: default Labels: run=nginx
Selector: run=nginx
Type: LoadBalancer
IP: LoadBalancer Ingress: 104.XXX.XX.XXX, 104.XXX.XX.XXX, 104.XXX.XX.XXX, 104.XXX.XXX.XX
Port: http 80/TCP
Endpoints: &lt;none&gt; Session Affinity: None No events.

联邦服务的LoadBalancer Ingress地址会汇总所有注册的Kubernetes集群服务的LoadBalancer Ingress地址。为了让同一联邦服务在不通集群之间以及不同云供应商之间的网络正确工作，你的服务需要有外部可见的IP地址，比如Loadbalancer是常见的服务类型。

请注意我们还没有部署任何后台Pod来接收指向这些地址的网络流量（比如服务终端），所以此时联邦服务还不会认为这些服务碎片是健康的，所以联邦服务对应的DNS记录也尚未创建。

增加后台Pod

为了渲染底层服务碎片的健康状况，我们需要为服务增加后台Pod。目前需要通过直接操作底层集群的API Server来完成（为节省您的时间，未来我们可以通过一条命令在联邦服务器中创建）。例如我们在底层集群中创建后台Pod：

for CLUSTER in asia-east1-a europe-west1-a us-east1-a us-central1-a
do
kubectl --context=$CLUSTER run nginx --image=nginx:1.11.1-alpine --port=80 done

验证公共DNS记录

一旦Pod开始成功启动并开始监听连接，每个集群（通过健康检查）会汇报服务的健康终端至集群联邦。集群联邦会依次认为这些服务碎片是健康的，并且创建相应的公共DNS记录。你可以使用你喜欢的DNS供应商的接口来验证。比如，如果你使用谷歌Cloud DNS配置联邦，你的DNS域为 ‘example.com’：

$ gcloud dns managed-zones describe example-dot-com 
creationTime: '2016-06-26T18:18:39.229Z'
description: Example domain for Kubernetes Cluster Federation
dnsName: example.com.
id: '3229332181334243121'
kind: dns#managedZone
name: example-dot-com
nameServers: - ns-cloud-a1.googledomains.com. - ns-cloud-a2.googledomains.com. - ns-cloud-a3.googledomains.com. - ns-cloud-a4.googledomains.com.
$ gcloud dns record-sets list --zone example-dot-com
NAME TYPE TTL DATA
example.com. NS 21600 ns-cloud-e1.googledomains.com., ns-cloud-e2.googledomains.com.
example.com. SOA 21600 ns-cloud-e1.googledomains.com. cloud-dns-hostmaster.google.com. 1 <a dir="ltr" href="tel:21600%203600" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="17">21600 3600</a> 1209600 300
nginx.mynamespace.myfederation.svc.example.com. A 180 104.XXX.XXX.XXX, 130.XXX.XX.XXX, 104.XXX.XX.XXX, 104.XXX.XXX.XX
nginx.mynamespace.myfederation.svc.us-central1-a.example.com. A 180 104.XXX.XXX.XXX
nginx.mynamespace.myfederation.svc.us-central1.example.com.
nginx.mynamespace.myfederation.svc.us-central1.example.com. A 180 104.XXX.XXX.XXX, 104.XXX.XXX.XXX, 104.XXX.XXX.XXX
nginx.mynamespace.myfederation.svc.asia-east1-a.example.com. A 180 130.XXX.XX.XXX
nginx.mynamespace.myfederation.svc.asia-east1.example.com.
nginx.mynamespace.myfederation.svc.asia-east1.example.com. A 180 130.XXX.XX.XXX, 130.XXX.XX.XXX
nginx.mynamespace.myfederation.svc.europe-west1.example.com. CNAME 180 nginx.mynamespace.myfederation.svc.example.com. ... etc.

注意：如果您使用AWS Route53来配置联邦，你可以使用相应的AWS工具，例如：

$aws route53 list-hosted-zones

$aws route53 list-resource-record-sets --hosted-zone-id Z3ECL0L9QLOVBX

不管您使用什么DNS供应商, 您可以使用DNS查询工具（例如 ‘dig’ 或者 ‘nslookup’）来查看联邦为您创建的DNS记录。

从联邦集群内部的pod发现联邦服务

默认情况下，Kubernetes集群有内置的本地域名服务器（KubeDNS），并且有智能的DNS搜索路径确保针对“myservice”、“myservice.mynamespace”、”bobsservice.othernamespace”等等被您运行在Pod中的的应用软件自动扩展和解析至相应的本地集群中的服务IP。

通过引入联邦服务以及跨集群服务发现，这个概念被扩展至全局，覆盖您联邦中所有的集群。为了利用这个扩展带来的便利性，您只需使用稍微不同的服务名（比如，myservice.mynamespace.myfederation）进行解析。

使用不同的DNS名同时避免了您现有的服务在您没有做明确的配置和选择情况下，意外的被解析到不同区（zone）或地域（region）网络，导致额外的网络费用或延迟。

因此，使用我们上面的NGINX 服务，以及刚刚介绍的联邦服务DNS名，我们构想一个示例：在可用性区域us-central1-a的集群中的pod需要访问我们的NGINX服务。与其使用传统的本地集群DNS名（“nginx.mynamespace”，自动扩展为“nginx.mynamespace.svc.cluster.local”），现在可以使用联邦服务名“nginx.mynamespace.myfederation”。此名称会被自动扩展和解析至我的Nginx服务最近的健康节点，无论它在世界的哪里。如果本地集群存在健康服务碎片，那么本地集群IP地址（通常是10.x.y.z）会被返回（被集群本地KubeDNS）。这与非联邦服务解析完全一致。

如果服务在本地集群不存在（或者服务存在但本地没有健康的后台pod），DNS查询会自动扩充至`”nginx.mynamespace.myfederation.svc.us-central1-a.example.com”。实际的行为是查找离当前可用性区域最近的服务碎片的外部IP。该扩展被KubeDNS自动触发执行，返回相关的CNAME记录。这会遍历上面示例中的DNS记录，直到找到本地us-central1 区域联邦服务的外部IP。

通过明确指定DNS名，直接指向非本地可用区域（AZ）和地域（region）的服务碎片，而不依赖于自动DNS扩展，是可行的。例如，
“nginx.mynamespace.myfederation.svc.europe-west1.example.com” 会被解析至位于欧洲的所有健康服务碎片，即使通过nslookup解析出的服务位于美国，并无论在美国是否有该服务的健康碎片。这对远程监控和其它类似应用很有用。

从联邦集群外部发现联邦服务

对于外部客户端，前文描述的DNS自动扩展已不适用。外部客户端需要指定联邦服务的全名（FQDN），可以是区域，地域或全局名。为方便起见，最好为您的服务手工创建CNAME记录，比如：

eu.nginx.acme.com CNAME nginx.mynamespace.myfederation.svc.europe-west1.example.com.
us.nginx.acme.com CNAME nginx.mynamespace.myfederation.svc.us-central1.example.com.
nginx.acme.com CNAME nginx.mynamespace.myfederation.svc.example.com.

这样您的客户端可以一直使用左侧的短名形式，并且会被自动解析到它所在大陆的最近的健康节点上。集群联邦会帮您处理服务的failover。

处理后台Pod和整个集群的失败情况

标准Kubernetes服务集群IP已经确保无响应的Pod会被及时从服务中移除。Kubernetes联邦集群系统自动监控集群以及联邦服务所有碎片对应的终端的健康状况，并按需增加和删除服务碎片。

因为DNS缓存造成的延迟（缓存超时，或者联邦服务DNS记录TTL默认设置为三分钟，但可以调节）可能需要这么长时间才能在某集群或服务碎片出现问题时，正确将客户端，请求failover到可用集群上。然而，因为每个服务终端可以返回多个ip地址，（如上面的us-central1，有三个选择）很多客户端会返回其中一个可选地址。

本文转自中文社区-跨集群服务实现Kubernetes应用的高可用

微信关注我们

原文链接：https://yq.aliyun.com/articles/679796

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

Kubernetes在企业级架构中的实践分享

以下为主要内容：演讲提纲 1、Docker与容器技术 Docker跟VM的区别：VM每次起一个实例，实际上包括三层，整个操作系统、中间层内部以及其他应用，全部都包括从OS kernel到应用态的全部，容器技术把kernel层共享给所有的实例。容器实例仅仅是应用态各不相同，而底层的操作系统内核是共享的，这样就带来一个好处：所有运行的应用，都是进程粒度，轻量级，采用Namespace、Cgroup等隔离技术，同时 Docker所定义的标准镜像模式，让我们可以对容器和镜像进行非常快速的迁移。 Docker容器可以 build once、run anywhere，一次构建，可以随意运行。 2、Kubernetes架构及特性 Kubernetes是容器集群编排系统。例如10台机器都装了Docker，我们可以用Kubernetes把这些机器都编排起来，统一成一个集群来处理。这种生产系统已经是生产级别的了，kubernetes最早的技术理念是源于谷歌的borg系统，而这种borg系统已经在谷歌内部稳定运行很多年了。 Kubernetes是2014年6月开源的，采用Golang的语言开发，每...

2018-12-16

691

apiserver的list-watch代码解读 list-watch，作为k8s系统中统一的异步消息传递方式，对系统的性能、数据一致性起到关键性的作用。今天我想从代码这边探究一下list-watch的实现方式。并看是否能在后面的工作中优化这个过程。 0. list-watch的需求上图是一个典型的Pod创建过程，在这个过程中，每次当kubectl创建了ReplicaSet对象后，controller-manager都是通过list-watch这种方式得到了最新的ReplicaSet对象，并执行自己的逻辑来创建Pod对象。其他的几个组件，Scheduler/Kubelet也是一样，通过list-watch得知变化并进行处理。这是组件的处理端代码： go c.NodeLister.Store, c.nodePopulator = framework.NewInformer( c.createNodeLW(), ...(1) &api.Node{}, ...(2) 0, ...(3) framework.ResourceEventHandlerFuncs{ ...(4) AddF...

2018-12-16

535

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。