A 华为云王泽锋 Kubernetes在容器混合云领域的实践与发展

2020-02-27 235浏览

  • 1.Kubernetes在容器混合云领域的实践与发展 王泽锋 Kubernetes项目Maintainer @kevin-wangzefeng 华为云Kubernetes开源负责人
  • 2.目录 CONTENTS 1. 典型场景 2. 发展历程 3. 关键项目 4. 未来展望
  • 3.容器混合云的典型场景
  • 4.多云、混合云的主要需求 高可用 • • 业务从集群故障中快速恢复 容量溢出 (Cloud Bursting) • • 集群、机房扩容速度跟不上应用扩容 资源池划分 • • 为特定的业务类型预留专用资源池 避免厂商绑定 • • 在多个云环境中部署集群和负载 ?
  • 5.典型阶段1：多云多地部署，统一管理运维，减少重复劳动 End user • 不同云上托管业务相同，无需跨云访问 • 每朵云独立对外提供业务 • 通过统一入口部署运维，减少重复劳动 • K8S版本、部署形态允许有一定差异 统一应用交付（部署、运维） Admin
  • 6.典型阶段2：多云统一资源池，应对业务压力波动 • • • • 不同云上的托管业务可能不同 • 公有云为业务子集，或无状态应用 • 私有云保留核心业务 End user 统一应用访问控制（流量分发） 基于业务特点设计流量分发策略 • 感知地域、云平台差异 • 基于业务、作业类型 存在少量跨云访问，单向为主 • 多数情况下是公有云访问私有云 • 需专线打通 统一应用交付（部署、运维） 通过统一平台控制业务跨云伸缩 • 业务忙时扩容到公有云，闲时收缩回私有云 Admin
  • 7.典型阶段3：多云协同，统一PaaS层，业务跨云部署 • • 托管业务跨云部署，配置策略进行跨云调度 • 如配置实例数配比、跨云弹性伸缩 • 私有云依然保留核心业务 PaaS层统一管理应用访问、运维等 • Admin 应用访问 应用运维 PaaS层提供统一的应用访问控制（路由、负载均衡 、灰度等）、应用运维（部署、监控、弹性等）， 无需定制 • End user 重度的跨云业务访问，需要云网络专线打通 App 专线打通
  • 8.Federation及Multicluster SIG发展历程
  • 9.Kubernetes Federation 发展历程 • 2015年H1 – 概念孵化 – 发布白皮书 • 2015年H2 – 开展工作 • 2016年初 –“Ubernetes Lite”单集群多AZ方案完成实现 • 2016年中 –“Ubernetes” – 多集群联邦完成功能最小集 • 2016年末 – 更名为 Kubernetes Cluster Federation • • 更多的玩家正式投入 2017年中 – 成为独立子项目 • github.com/kubernetes/federation
  • 10.Kubernetes Federation 发展历程 2017年末，Federation F2F 会议讨论，将SIG更名为Multicluster • Turnkey Solution => Building Blocks • 更明确的划分，各组件职责明确 • 简化方案，不同场景根据需求自由组合、替换 • 对混合云所需的能力支持划分几个大块 • Application Management • Cluster Discovery • Cluster Automation（实际上属于cluster-lifecycle）
  • 11.跨集群的应用管理：Federation 项目
  • 12.Federation 整体架构 管理控制请求 kubectl / KubeUI / Rest API 业务流量 ETCD Federated API Server 增加集群相关API，屏蔽集群差异，统 一请求入口 3rd Auth 全球分布式路由 Federated Controllers Cluster Controller Federated API Server Cluster Controller 管理个集群状态，集群级别对象创建 Kubernetes Master 负载均衡 Kubernetes Master 负载均衡 Service Controller 跨集群服务发现 Node Node Node Node Node Node Node Node Node Node Node Node Flannel/OVS（叠加网络） Flannel/OVS 关键设计原则 • 基于底层容器网络无法打通的前提 • 跨集群通信时延无法保证
  • 13.Federation API 的美中不足 • 直接映射 K8S API • 从单集群到多集群，client无修改 • Federation信息嵌入Annotation — Ugly • 不提供Federation特有API • 联邦层在调度、生命周期管理等方面的增强空 间有限 • 缺少独立的API对象版本控制 • Deployment 在K8S 中GA，但在Federation 中是仍是 beta
  • 14.Federation V2 架构 V2版本的重点改进 • 剥离annotation为独立API对象 • FederatedTypePlacement • FederatedTypeOverride Metrics based Scheduling Replica Scheduling FederatedType Placement Batch jobs FederatedType Override Propagation Config + Push Reconciler FederatedTemplate • 用Federated API 对象 封装 K8S 对象 User Defined • FederatedSecret has k8s v1/secret • 模块化，可裁剪、自由组合的能力 Cluster Pull • 通过拆分 API 来加强 Push • 独立管理API版本 Registry cluster cluster cluster
  • 15.集群发现与Endpoint维护：Cluster Registry 项目
  • 16.Cluster Registry ● “Cluster” API对象标准化和增强 ‐ 后续多集群发展的building block ● 管理member集群的API endpoint等信息 ‐ kubeconfig as a service ‐ 基于label的集群查询（如：查询所有staging集群） ● 独立代码仓库开发“kubernetes/cluster-registry” ‐ 提供“crinit”进行部署和初始化 ‐ 支持Stand alone，或者as CRD ‐ 为周边组件提供集群信息：Auth，UI/UX平台，Cluster API，Federation ● Istio主流的多集群方案已适配cluster registrykind:ClusterapiVersion:clusterregistry.k8s.io/v1alpha1metadata:namespace:defaultname:my-clusterlabels:foo:barspec:kubernetesApiEndpoints:serverEndpoints:-clientCIDR:"0.0.0.0"serverAddress:"https://us-west1a.demo.io"status:{}https://kubernetes.github.io/cluster-registry/
  • 17.统一集群管理架构：Cluster API 项目 （集群生命周期SIG子项目）
  • 18.Cluster API • Declarative API 管理集群生命周期 ‐apiVersion:"cluster-api.k8s.io/v1alpha1" ‐kind:Cluster ClusterAPI Cluster API Spec Cluster API Implementation Layer 3 Addons API* Cloud Provider Load Balancers Monitoring Logging • controller监视并调整“期望”、 “当前”状态 ‐ 可以运行在被管理集群内，或外置独立运行 • 各云厂商针对自家平台适配实现 Kubernetes API Layer 2 Bootstrapping kubeadm kubeadm kubeadm kubeadm Machines Master A Master N* Node 1 Node N ‐ GCE, AWS, Azure, 华为云, Terraform 等等 Layer 1 • 统一现有各集群管理工具架构 Infrastructure ‐ 集群升级，自动恢复，集群自动伸缩 *：规划能力 / WIP
  • 19.展望：完整形态的混合云方案还有多远？
  • 20.Federation 中的服务发现 1 创建服务 kubectl Federated API Server 2 保存对象 ETCD 3 Watch 服务创建 4 创建外部服务 并设置Endpoint Node 全球分布式路由 Federated Service Controller 负载均衡 Kubernetes Cluster A 5 管理控制请求 负载均衡 Kubernetes Cluster B Watch Service Endpoints 刷新iptables Node Node Node Node Node Node Node Node KubeKube-proxy proxy Node Node Node 业务流量
  • 21.Istio 接管 K8S 多云多集群流量治理 Istio多集群当前方案限制 —— 与K8S Federation设计原则不对等 • 各集群的 Pod CIDR 范围和 Service CIDR 范围必须唯一，不能相互重叠。 • 每个集群中的所有的 Pod CIDR 需要能够互相路由。 • 所有的 Kubernetes 控制平面 API Server 互相可路由。
  • 22.Istio 接管 K8S 多云多集群流量治理 Istio多集群未来将不约束容器网络打通
  • 23.SIG Multicluster • • •https://github.com/kubernetes/community/tree/master/sigmulticluster华为云容器团队公众号