MEP管理面： 特性简介MEP管理面提供应用的生命周期管理，通过支持管理多个边缘计算平台。支持基于虚拟机的应用部署，同时也支持基于Docker的应用部署。在部署过程中，可以同步MEP应用商店的应用包到平台，然后通过MEP管理面分发到边缘，进行部署。 客户价值● 方便管理应用的增删改查。● 方便查看边缘节点的资源使用情况。● 方便管理边缘节点的MEP平台。特性描述同时支持容器化和基于虚拟机的应用管理MEP管理面基于kubernetes 进行应用管理，可以支持Helm和Kubernetes deployment两种部署方式，同时通过Kubevirt可以支持基于Kubernetes的虚拟机管理。节点管理MEP管理面通过集成Grafna可以支持对每个Edge节点进行监控，同时MEP管理面也可以分节点进行所有资源的查看，包括MEP，APP，以及Kubernetes自身进行监控。CatalogMEP管理面的Catalog管理MECM从MEP应用商店同步过来的APP Package。并且可以通过注册系统，将APP Package提前分发到边缘计算节点，节省了MEP管理面在部署过程中需要提前下载相关镜像的时间。

引子随着云原生技术的普及，越来越多的企业使用Kubernetes来管理应用，并且集群规模也呈爆发式增长，企业也亟需应对随集群规模增长而带来的各种挑战。同时，为了更好地提供高可用、弹性伸缩的应用，企业也对容器混合云解决方案产生了极大的兴趣。纵观容器混合云市场，主要的云服务提供商纷纷推出了自家的解决方案，例如华为云的MCP、Google的Anthos、Vmware的 Tanzu、IBM的 Cloud Pak、Red Hat的ACM for K8s等等。可以说，当前容器混合云市场纷繁嘈杂、百家争鸣，尽管各厂商不遗余力地鼓吹自家解决方案，但有个不争的事实是在容器混合云领域暂未出现领军产品。混合云市场的乱象源于两点，一是各厂商均嗅到了商机，发现了这一广阔的蓝海市场，急于在这场竞争中抢占先机C位出道；二是开源界暂无统一的事实标准。根据历史规律，后者是解决这一乱象的关键所在，正像Kubernetes终结容器编排领域的纷争一模一样。在开源领域，致力于混合云领域的项目数量与广阔的市场相比，显得极不相称。目前只有Rancher的Fleet、SAP公司力推的Gardener、以及Kubernetes社区的Kubefed。Fleet和Gardener要么缺乏创新，要么格局较低，难成大气，最有可能形成标准的便是被寄予厚望的、也是当前Kubernetes社区唯一的官方项目Kubefed。K8s多集群历史Kubernetes社区早在2015年便发布了集群联邦技术白皮书，并成立了“SIG-Federation”（后更名为SIG-Multicluster）特别兴趣小组致力于多集群领域的研究，该兴趣小组由华为领衔，同时也吸引了包括Google、Redhat在内的一线大厂。SIG-Federation于2016年正式推出官方项目Federation，并在此基础上发展出了Kubefed项目，而且技术架构也发生了较大的变化，因此Federation项目常常被称为Federation V1，而Kubefed则被称为Federation V2。Federation V1架构第一代架构中，引入了Federated API Server，用于增加集群相关API，屏蔽集群差异，统一请求入口，同时提供一个Cluster Controller用于管理多个集群状态、集群级别对象创建，并且Service Controller用来实现跨集群服务发现。整体架构如下图所示：V1架构兼容K8S原生API，从单集群到多集群演进可以变得很自然，但它也有几个不得不面对的缺陷。• 集群信息嵌入原生API的Annotation中（如下图所示），会导致原生API体积膨胀而丑陋；• 没有集群生命周期管理特有API，导致其生命周期管理能力无法扩展；• 无法提供API对象版本控制，比如Deployment在K8S为GA，但在Federation中可能仍是Beta；Federation V2架构在第二代架构中，利用CRD来提供独立的API对象，新的API来封装K8S原生对象，同时也可以方便的对新增API提供版本管理。整体架构如下图所示：随架构升级，Federation项目也更名为Kubefed。在新的架构中，Kubefed提供两种配置类型：• Type configuration（类型配置）： 定义Kubefed接管的K8S的资源类型• Cluster configuration（集群配置）： 定义Kubefed接管的K8S集群在类型配置中有三个关键的概念，用于控制资源向拖管集群分发策略：• Templates（模版）：定义一个原生的K8S资源类型；• Placement（安置）：定义资源将分发的集群；• Overrides（修正）：针对集群自由修正资源；一个典型的Secret配置如下图所示：apiVersion: types.kubefed.io/v1beta1 kind: FederatedSecret metadata:   name: test-secret   namespace: test-namespace spec:   template:     data:       A: YWxhIG1hIGtvdGE=     type: Opaque   placement:     clusters:     - name: cluster2     - name: cluster1   overrides:   - clusterName: cluster2     clusterOverrides:     - path: /data       value:         A: null上述配置中，通过template指定原生资源属性，通过placement指定资源将分发到cluster1 和 cluster2集群，最后overrides指示了分发到cluster2集群时，消除Secret的data信息。K8s多集群现状KubeFed的问题Kubernetes社区当前已将Federation (v1)项目关闭，着重发展Kubefed，但该项目尚停留在beta阶段，社区开发几乎停滞，作为社区官方项目在该领域中的领导地位也在逐渐减弱。Kubefed项目最大的问题是使用了非Kubernetes原生API来管理用户应用部署，用户必须先改造既有的工作流程才可迁移到Kubefed提供的API，这不仅抬高了使用门槛，而且Kubefed为每种资源类型均提供了CRD API，种类繁多的API也增加了用户的学习成本。某位社区致力于多集群管理的架构师坦言：“Kubefed项目强制用户使用非原生API，这个错误的决定很大程度上导致了它的发展不如预期。”另外，多集群管理场景中，应用的多集群分发与监控应该是最基本的诉求，而Kubefed只完成了应用分发，对于应用的运行状态缺乏监管。用户使用Kubefed分发应用只能看到应用是否分发成功，对于应用运行状态，用户仍需要遍历集群分别获取。对用户使用造成了极大的不便。K8s多集群管理标准化工作当前Kubernetes社区针对Kubefed相关问题已经进行了多次讨论，目前多集群管理相关标准制定工作主要围绕在跨集群服务发现和工作负载配置管理，这两块也是实现多集群应用管理最基础的功能部分。a.多集群Service API在多集群应用背景下，用户已经习惯于将应用分发到多个集群，但对于Service应用而言，集群是个硬性障碍，运行于集群中的工作负载无法高效地访问其他集群中暴露的服务。多集群Service API旨在提供解决这个问题的标准，它主要包括：1）定义一组API支持跨集群的Service服务发现和消费；2）集群中应用跨集群访问Service行为与本集群一致；该Service API提供ServiceExport对象表示单个集群中需要暴露到多集群的Service：// ServiceExport declares that the associated service should be exported to // other clusters. type ServiceExport struct {         metav1.TypeMeta `json:",inline"`         // +optional         metav1.ObjectMeta `json:"metadata,omitempty"`         // +optional         Status ServiceExportStatus `json:"status,omitempty"` }每个需要暴露给其他集群的Service均对应一个ServiceExport对象。此外，Service API还提供了ServiceImport对象，表示跨集群的Service定义：// ServiceImport describes a service imported from clusters in a supercluster. type ServiceImport struct {   metav1.TypeMeta `json:",inline"`   // +optional   metav1.ObjectMeta `json:"metadata,omitempty"`   // +optional   Spec ServiceImportSpec `json:"spec,omitempty"`   // +optional   Status ServiceImportStatus `json:"status,omitempty"` }该Service API 提案已被社区接纳，该提案只定义了跨集群Service的声明方式，并没有对其实现细节进行约束，可以想见，将来会有多种具体的解决方案被提出。b.多集群工作负载模型关于联邦应用如何在多集群中分发，SIG-Multicluster也在进行尝试一种与现有Kubefed不同的处理思路。Kubefed当前从一系列FederatedXXX配置中剥离出Kubernetes原生应用分发到多集群，而新的尝试是提供一个通用的ManifestWork对象封装所有的应用，如下API设计：// ManifestWork represents a manifests workload that hub wants to deploy on the managed cluster. // A manifest workload is defined as a set of kubernetes resources. // ManifestWork must be created in the cluster namespace on the hub, so that agent on the // corresponding managed cluster can access this resource and deploy on the managed // cluster. type ManifestWork struct {    metav1.TypeMeta   `json:",inline"`    metav1.ObjectMeta `json:"metadata,omitempty"`    // Spec represents a desired configuration of work to be deployed on the managed cluster.    Spec ManifestWorkSpec `json:"spec"`    // Status represents the current status of work    // +optional    Status ManifestWorkStatus `json:"status,omitempty"` }与Kubefed为每种应用类型均提供一个FederatedXXX 类型相比，这种新型的工作负载API则显得更加简单和通用。未来展望K8s多集群技术是容器混合云/多云解决方案的核心技术领域，涉及到资源、应用、数据、流量多个层面，以及统一配置、注册、可视化、自动弹性等多个功能领域。目前开源业界包括K8s社区的KubeFed项目、以及现有市面上的各种产品与解决方案都没有能够覆盖完整的多集群技术领域。华为云MCP容器多云平台在K8s多集群技术领域属于较早也是实现较为全面的产品，而同时华为云作为KubeFed社区项目的发起者与领导者，将在未来致力于完善现有KubeFed的功能集，并且实现K8s多集群技术的标准化。下图描述了K8s多集群技术的全景，目前华为云已经在KubeFed自身以及周边关联的多个技术领域开展了相关工作。转载自：华为云开发者论坛

摘要：KubeEdge 是首个基于 Kubernetes 扩展的，提供云边协同能力的开放式智能边缘计算平台，也是 CNCF 在智能边缘领域的首个正式项目。依托 Kubernetes 强大的容器编排和调度能力，实现云边协同、计算下沉、海量设备接入等。边缘计算场景与挑战边缘计算是一种分布式计算概念，拥有去中心化处理能力的分散型开放 IT 架构，数据由设备本身或本地计算机或服务器处理，无需传输到数据中心，也可在更靠近终端的网络边缘上提供服务。但边缘计算无法单独存在，它必定要和远程数据中心 / 云打通，以 IoT（Internet of Things，物联网）场景为例，边缘设备除了拥有传感器收集周边环境的数据外，还会从云端接收控制指令，因此边缘计算与云计算二者是相依而生、协同运作的。据2020边缘计算状态报告显示，到2022年，75%的数据将通过边缘分析和处理。这种数据处理的流动性，将伴随有4大边缘技术演进方向：人工智能的实用性增强，从云端渗透到边缘物联网设备的数量呈指数级增长5G时代的快速到来边缘计算中心逐步克服分布式设施复杂性和单位成本经济性的问题结合边缘计算的场景与技术演进方向，可以总结出当前边缘计算领域面临的几个挑战：云边协同：逐步从云端渗透到边缘的AI/安全等业务，在云和边的智能协同、弹性迁移；网络：边缘网络的可靠性和带宽限制；设备管理：呈指数级增长的物联网设备，边缘节点与边缘设备的管理；扩展：高度分布和大规模的可扩展性；异构：边缘异构硬件和通信协议。Kubernetes构建边缘计算平台的优势与挑战Kubernetes 已经成为云原生的事实标准，并且能够在任何基础设施上提供一致的云上体验。我们经常能够看到“容器 + Kubernetes”的组合在 DevOps 发挥 10X 效率。基于Kubernetes的技术架构与生态优势，近几年也有越来越多的将Kubernetes 运行在数据中心外（边缘）的需求。基于Kubernetes构建的边缘计算平台，将会具备众多天然的优势：（1）容器化应用封装：容器的轻量化和可移植性非常适合边缘计算的场景，边缘容器应用Build一次，可以运行在任何边缘节点上。（2）通用的应用抽象定义：Kubernetes的应用定义已成为云原生业界的事实标准，被广泛接受。通过原生的Kubernetes应用API，用户可以将云上与边缘的应用统一管理。例如用户可以使用熟悉的 kubectl 或者 helm chart管理云上与边缘的应用。（3）平台易扩展性：Kubernetes 已经被证明具备良好的可扩展性，基于CRD可以自定义API，如边缘设备管理；基于CRI、CNI、CSI等插件可以扩展各种边缘自定义插件。（4）强大的技术生态圈：围绕 Kubernetes 已经形成了一个强大的云原生技术生态圈，诸如：监控、日志、CI、存储、网络都能找到现成的工具链。然而 Kubernetes 毕竟原生是为云数据中心设计的，要将Kubernetes 的能力扩展到边缘，必须解决以下问题：（1）边缘设备资源有限：很多设备边缘的资源规格有限，特别是 CPU 处理能力较弱，内存资源较少，因此无法部署完整的 Kubernetes。（2）边缘网络的不稳定性：Kubernetes依赖数据中心稳定的网络，边缘场景下网络通常又是不稳定的。（3）边缘节点离线自治：Kubernetes依赖 list/watch 机制，不支持离线运行，而边缘节点的离线又是常态，例如：设备离线重启。（4）海量边缘设备管理：如何使用Kubernetes管理指数级增长的海量边缘设备以及产生的数据。另外，关于如何在边缘使用 Kubernetes，Kubernetes IoT/Edge WG 组织的一个调查显示，30% 的用户希望在边缘部署完整的 Kubernetes 集群，而 70% 的用户希望在云端部署 Kubernetes 的管理面并且在边缘节点上只部署 Kubernetes 的 agent。边缘容器开源现状Kubernetes社区很早就已经关注到边缘计算场景，早在2018年社区就已经成立专门的Edge工作组来研讨边缘相关场景。而2018年底，华为在业界首次开源Kubernetes边缘项目KubeEdge，将华为云智能边缘平台产品IEF（Intelligent EdgeFabric）核心代码开源，并于19年初捐献给CNCF基金会，成为CNCF迄今为止唯一边缘计算官方项目。随后，Rancher、阿里云也陆续跟进，开源了K3s、OpenYurt等项目，边缘容器这个领域真正进入到快速发展期。下面，我们对这三个代表性的K8s@Edge的项目进行一些简要分析。KubeEdge架构分析KubeEdge 是华为云于2018年11月开源，2019年3月捐献给 CNCF 的开源项目。KubeEdge 是首个基于 Kubernetes 扩展的，提供云边协同能力的开放式智能边缘计算平台，也是 CNCF 在智能边缘领域的首个正式项目。KubeEdge 的名字来源于 Kube + Edge，顾名思义就是依托 Kubernetes 强大的容器编排和调度能力，实现云边协同、计算下沉、海量设备接入等。KubeEdge架构上分为云、边、端三个层次。云端中心管控边缘节点与设备，边缘节点实现边缘自治，云上管控边缘节点的架构也符合Kubernetes IoT/Edge WG 调查结果中大多数用户的诉求。KubeEdge完整的打通了边缘计算中云、边、设备协同的场景，整体架构如下图。针对边缘特定的场景，KubeEdge 重点解决的问题是：云边协同：KubeEdge 通过 Kubernetes 标准 API 在云端管理边缘节点、设备和工作负载的增删改查。边缘节点的系统升级和应用程序更新都可以直接从云端下发，提升边缘的运维效率；在边缘AI场景下，云端训练好的模型可以直接下发到边缘节点，进行推理等，实现边缘AI的云边一体化。边缘自治：KubeEdge 通过消息总线和元数据本地存储实现了节点的离线自治。用户期望的控制面配置和设备实时状态更新都通过消息同步到本地存储，这样节点在离线情况下即使重启也不会丢失管理元数据，并保持对本节点设备和应用的管理能力。极致轻量：KubeEdge 则是保留了 Kubernetes 管理面，对Kubernetes的节点端组件进行重组，达到极致轻量的目的，节点组件可以运行在内存256M的边缘节点上。海量边缘设备管理：KubeEdge了可插拔式的设备统一管理框架，在云端基于Kubernetes的CRD能力，自定义了设备管理的API，完全符合Kubernetes的原生标准，用户可以在云端通过API来管理海量边缘设备；在边缘可根据不同的协议或实际需求开发设备接入驱动，当前已经支持和计划支持的协议有：MQTT，BlueTooth，OPC UA，Modbus 等，随着越来越多社区合作伙伴的加入，KubeEdge 未来会支持更多的设备通信协议。K3s架构分析K3s 是 Rancher于2019年2月开源的一个自己裁剪的 Kubernetes 发行版，K3S 名字来源于 K8s – 5，这里的“5”指的是 K3S 比 Kubernetes 更轻量使得它能更好地适配 CI，ARM，边缘技术，物联网和测试这 5 个场景。K3S 是 CNCF 官方认证的 Kubernetes 发行版，开源时间较 KubeEdge 稍晚。K3S 专为在资源有限的环境中运行 Kubernetes 的研发和运维人员设计，目的是为了在 x86、ARM64 和 ARMv7D 架构的边缘节点上运行小型的 Kubernetes 集群。K3S 的整体架构如下所示：K3S 就是基于一个特定版本 Kubernetes（例如：1.17）直接做了代码修改。K3S 分 Server 和 Agent，Server 就是 Kubernetes 管理面组件 + SQLite 和 Tunnel Proxy，Agent 即 Kubernetes 的数据面 + Tunnel Proxy。为了减少运行 Kubernetes 所需的资源，K3S 对原生 Kubernetes 代码做了以下几个方面的修改：删除旧的、非必须的代码。K3S 不包括任何非默认的、Alpha 或者过时的 Kubernetes 功能。除此之外，K3S 还删除了所有非默认的 Admission Controller，in-tree 的 cloud provider 和存储插件；整合打包进程。为了节省内存，K3S 将原本以多进程方式运行的 Kubernetes 管理面和数据面的多个进程分别合并成一个来运行；使用 Containderd 替换 Docker，显著减少运行时占用空间；引入 SQLite 代替 etcd 作为管理面数据存储，并用 SQLite 实现了 list/watch 接口；将所有Kubernetes原生进程打包在同一个进程中。K3s项目本质上是一个K8s的“轻量化”版本，而不是一个真正意义上的“边缘”版本。从架构上看，K3s 的所有组件（包括 Server 和 Agent）都运行在边缘侧，这意味着 K3S 并不是一个去中心化的部署模型，每个边缘都需要额外部署 Kubernetes 管理面，因此不涉及云边协同。也缺乏针对边缘网络不稳定性的边缘自治能力，也不涉及边缘设备的管理。此外，如果 K3s 要落到生产，在 K3s 之上应该还有一个云上的统一集群管理方案负责跨集群的应用管理、监控、告警、日志、安全和策略等，遗憾的是 Rancher 尚未开源这部分能力。OpenYurt架构分析OpenYurt是阿里云于2020年5月开源的云原生边缘计算项目，跟KubeEdge架构基本相似，OpenYurt也是依托原生Kubernetes的容器编排及调度能力，提供云边协同能力的边缘计算平台。OpenYurt 也是依托 Kubernetes 强大的容器应用编排能力，实现云-边一体化的应用分发、管控的诉求，也是从云端集中管控边缘节点，OpenYurt 的整体架构如下所示：项目目前还未发布0.1版本，从已开源部分可以看出，OpenYurt架构与KubeEdge类似，也是打通了云边协同的场景。提供的能力也与KubeEdge类似，包括边缘自治、云边协同、单元化管理能力（未开源）等。OpenYurt并未对Kubernetes进行改造，而是通过Addon（插件化）的形式提供边缘计算所需要的管控能力，边缘端的YurtHub，作为节点上的临时配置中心，在网络连接中断的情况下，持续为节点上所有设备和客户业务提供数据配置服务。这种简化的架构，重点在于解决“离线自治”问题，且比较有利于保留现有K8s的完整功能，但由于未对Kubelet进行修改，因此OpenYurt无法运行在资源有限的边缘设备中；物联网场景中的对于边缘设备的管理，OpenYurt也不涉及；并且一些边缘场景下涉及到Kubelet原生不支持的高级特性比如离线自愈、自调度等无法实现。边缘容器总结与展望对比三个开源项目， K3s 最让人印象深刻的特点在于其对 Kubernetes 进行了轻量化、部署便捷化做的尝试，通过剪裁了 Kubernetes 一些不常用功能并且合并多个组件到一个进程运行的方式，使得一些资源较充足的边缘节点上能够很方便的获得与Kubernetes一致的体验。但是从测试数据看K3s 的资源消耗还是很高，而且动辄几百 MB 的内存也不是大多数设备边缘节点所能提供的，而且目前只适合运行在边缘，不具备云边协同、边缘自治等边缘计算领域的核心诉求。OpenYurt通过非侵入的插件化形式在原生Kubernetes的基础上提供边缘计算能力，虽然提供了云边协同、边缘自治等能力，但是未做轻量化改造，只能运行在资源充足的边缘节点，无法运行在大量资源有限的边缘节点上，并且也未提供边缘计算中海量边缘设备管理的能力。KubeEdge是一个从云到边缘再到设备的完整边缘云平台，100% 兼容Kubernetes的原生API，基于Kubernetes解决了边缘计算领域的核心诉求，包括云边协同、边缘网络不稳定、边缘自治、边缘轻量化、海量边缘设备管理以及异构扩展等问题。未来边缘容器技术仍将聚焦于解决边缘计算领域所面临的云边协同、网络、设备管理、扩展及异构等挑战，KubeEdge 已经是 CNCF正式项目，未来将持续与社区合作伙伴一起制定云和边缘计算协同的标准，解决边缘计算领域的难题，结束边缘计算没有统一标准和参考架构的混沌状态，共同推动边缘计算的产业发展。转载自：华为云开发者论坛

【转载华为云社区】当今K8s独霸天下之时，咱们站在更高的角度，好好的看看K8s的网络是以什么理念构筑的。以及一个容器集群的好保姆，是如何分别照顾 南北流量和东西流量的。1      简单介绍下Kubernetes略。。容器集群管理的事实标准了，不知道要打屁股。（ps：本章节可参考唐老师的《K8S前世今生》文章）2      世界上的集群都一个样有点标题党哈，不过我接触过的各种集群也不少，各种各样：Ø  OpenStack：在一大堆物理机上面，管理（启动/停止）VM的。Ø  SGE，Slurm，PBS：在一大堆电脑集群里面，管理（启动/停止）App的。Ø  Yarn：在一大堆电脑集群里面，管理（启动/停止）大数据App的。Ø  CloudFoundry：在一大堆电脑集群里面，管理（启动/停止）容器的Ø  Kubernetes：在一大堆电脑集群里面，管理（启动/停止）容器的。它们都有一些共同特点：2.1      跨节点跑xx程序这个xx程序一定是首先单机可以运行的。比如OpenStack：单机上面可以用qemu启动VM，想跨节点管理VM，就引入了OpenStack。Kubernetes也一样：单机上面可以跑Docker容器；想跨节点管理容器，就得引入集群管理老大的概念。2.2      有一个管事的老大A）集群管理的老大，负责让手下的某个小弟干活。别管是命令式（直接下命令）的，还是申明式（发告示）的，小弟收到命令后，乖乖干活就是了。B）       同时，这个集群管理的老大，需要有脑子，不然小弟数量多了管不好。所以它需要拿笔记一记。比如OpenStack的老大得带个Mysql数据库；Kubernetes把笔记记在了ETCD里面（不过ETCD这个本子太小，记得东西不能太大，这是另话）。C）       不管哪种老大，都得有个军师。一个新活来到老大这里，那么多小弟，指派给谁不是干呀。这活实际分配给哪个小弟，这得军师说了算，所以每中集群软件都自己写了一套 Scheduler 算法，可谓程序员间浪费重复轮子之典型代表。2.3      小弟上面都有一个Agent这个小弟上面的Agent，时刻向老大汇报自己的状态：活不活着，忙还是闲，方便老大派活。同时，Agent也就是那台电脑里面的地头蛇了，帮忙老大负责各种临时事物。只是大家的取名不一样：OpenStack：取名NovaKubernetes：取名KubeletYarn：取名NodeManager2.4      老大怎么给小弟发号施令一般老大都是通过：消息队列来，给小弟发号施令的，而不是亲自上门（直连）下达命令。原因么，当然是小弟可能临时出门（故障）了呗~ 直接上门可能不通，放消息队列里面就可靠多了。等小弟出差回来，还能看到老大下达的任务令。Ø  OpenStack：用 RabbitMQ 发号施令Ø  Kubernetes：用 ETCD 发号施令Ø  CloudFoundry：用 NATS 发号施令上面这些组件都是带消息通知的功能，区别有些有名，有些没那么出名罢了。比如我们的K8s：特别需要提一下：K8s这个老大不简单，找了个ETCD这个好帮手。这小家伙挺神，既能当笔记本记点事情（代替OpenStack中的Mysql），又能当公告牌，通知点消息（代替OpenStack中的Rabbit）。所以K8s这个容器集群管理相对OpenStack这个虚机管理不需要数据库，666~3      K8s怎么设计容器网络的呢3.1      南北流量要看到K8s诞生的时候，那时是有CloudFoundry和Docker的，且都已经比较成熟。那时作为PaaS一哥的CF对容器网络的抽象：主要考虑平台外部，怎么访问容器里面的App。而平台内部的App之间如何互相访问，几乎没有太多的设计。由上图所示，可以看到，平台外部访问，一般都是上下画的，所以也叫做南北流量。我们这么叫，也是便于程序员之间沟通和理解。Ps：PaaS的基本原型大致都这样：3.2      东西流量K8s吸取了前辈们的精华，除了平台外部访问App，还新增考虑了平台内部，App之间如何互相访问。即K8s通过增加一个负载均衡的“LB”设备，来搞定平台内部的App间互相访问。给每个App取个别名，在LB上面登记一下，就可以被内部其他App访问。由上图所示，可以看到，平台内部访问，一般都是水平画的，所以也叫做东西流量。一个完整的PaaS平台，就是需要南北流量+东西流量，全套治理的。3.3      Docker原生访问方式还记得唐老师的《Docker网络实现》章节吧，Docker容器可以通过“节点IP+节点Port”的方式访问到容器。原理的容器所在节点，设置了NAT规则。报文一到达节点，根据目的端口，转发进入容器。3.4      小结：K8s中3种访问容器的通道（1）       通过南北流量（从集群外部访问App）访问App容器（2）       通过东西流量（集群内App之间）访问App容器（3）       通过Docker原生自带的方式，访问App容器下一章节，我们简单介绍下每种方式，K8s分别怎么去实现的。4      K8s怎么实现容器访问虽然K8s上面，有多种访问App容器的方法。但是不管用什么方式访问，一个App想要能被访问，就得得到K8s的同意。K8s把这个许可证叫做“Service”：也就是不管什么南北流量、东西流量，你的App想要能被访问，就得先申请Service许可证。4.1      南北流量要实现一个App的访问通道，一定要2个东西：（1）LB负载均衡器 + （2）注册映射关系。映射关系就是：报文来了，应该转发给哪个App实例？ 即：找到 “哪个App + 哪个实例”。负载均衡器呢，一般大家爱用Nginx，不过也有其他类型的实现。K8s比CF聪明的地方是，没有自己去实现LB。而只定义了App需要怎么样才能登记到LB上面。即只定规范，不限制实现（这种思路，在k8s里面好多，比如存储的CSI，运行时的CRI的，容器网络的CNI 都是这样。）Ø  4层LB最简单的4层LB实现，K8s取了个名字：LoadBalancer（1）。即定义：xx协议+xx端口 =》xx应用，具体规则自己去看资料。Ø  7层LB为了定义7层LB的规则，K8s给规范取了名字：Ingress（2）。即定义：xx网址+xx-URL路径 =》xx应用，具体规则也自己看K8s资料。南北LB都是全局级的，即：全局一个（HA多实例，咱也当一个整体）就行；不需要每个Slaver节点上一个。4.2      东西流量东西流量，也一样，需要LB+规则注入。这里，K8s设计就比较有意思。逻辑上，如上图所示。在LB部分的实现上，K8s很巧妙的要求每个节点上面都一个“小LB”。所以实现上，大致如上图所示。Ø  本地LB本地LB，要求每个节点都有。所以最开始的版本，K8s使用了Linux使用广泛的iptables来实现。后面由于iptables性能不是特别给力，又有了 IPVS 实现。然后其他各式各样的民间实现也有。Ø  本地控制器LB需要一个控制器，每个本地“小LB”带配备一个小控制器，一样的，也是每个节点一个。和小LB一一对应。K8s给它取了个名字：Kube-proxyØ  假IP地址每个K8s上的App，都可以申请“行走江湖的名号”，用来代表自己。K8s就会给你的App分配一个Service许可证，许可证上面带着“影子IP”，任何集群内部只要访问这个IP，就等于访问你的App。实现上：1.     先到K8s那登记，说我想要个“名号”2.     通过后，K8s会告知每个节点上的本地LB3.     从此以后，每个LB都认识这个“影子IP”了，访问它，就代表访问对应App。由于这个“名号”是集群颁布的，所以仅在集群内有效。K8s取名：ClusterIP（3）。关于东西流量的故事，还可以去看看唐老师之前的《网络骗子》篇。4.3      Docker原生访问方式除了上面几种访问方式，K8s也为原生的Docker访问通道留了个名字：NodePort（4）。这种方式，在《Docker网络实现》里面说过，靠主机Host转发实现。既然是主机搞定，所以这条路和本地LB实现，就合并一起搞定了。如上图，K8s下发规则的时候，顺便把这条路的规则也下发下去。ps：由于每个本地LB都收到了K8s的通告小皮鞭，所以每个K8s的节点，都开通了NodePort通道哦。即：无论哪个Slaver节点的Port都可以通往该App。4.4      小结K8s在实现容器网络的时候，造了很多概念：（1）       LoadBalancer（2）       Ingress（3）       ClusterIP（4）       NodePort本质都是一样的，就是LB+登记规范。 如果你看过《DNS篇》+《Docker网络实现》，这些就比较好理解。ps：具体本地LB怎么实现？真有兴趣可以去搜搜Kube-proxy的代码解读。我本身不是很关心，因为其实你给每个节点安装一个 Nginx 也可以做到的。5      总结K8s的网络概念，特别是Service，是K8s里面的精华，务必需要搞明白。（1）       K8s南北流量，用Loadbalancer（4层）和Ingress（7层）搞定。（2）       K8s的东西流量，用Service概念搞定。特别的，还给了个“行走江湖用的名号”，取名ClusterIP（一个不存在的假IP地址）。（3）       容器所在Host组网，存在Docker原生通道，K8s给重新包装了个名字：NodePort。所以只要报文到达Slaver节点，就能通到容器里面。另外，提一下一直没有说的东西（怕概念太多，影响理解）：K8s的整个网络底座，是要求节点IP和容器IP是能互相连通的（即：在节点上面ping容器IP，是可以通的）。具体则是通过容器网络实现的。这个实现很多，Flannel，Calico等，本质要么隧道，要么子网（可以看看物理网络里面的《VLAN和Vxlan》篇，关于如何划分门派的篇章）。

问题描述：当前华为云开源镜像站中Kubernetes软件源版本在2019.5.19后就没有刷新了，版本停滞在1.14.2；当前社区版本已更新至1.18.3版本。问题影响：客户想使用高版本K8S还不能配置华为云的源，必须推荐他们配置阿里云的源，产生困扰。需求建议：尽快刷新Kubernetes软件源，填补缺失的43个小版本（1.14.2 - 1.18.3），跟上社区release版本节奏。

nodejs 和 kubernetes 镜像没有最新版，能不能更新一下，谢谢啦

通过对比如其它云等厂商的源，以及发现kubernetes目前同步停留在了5月28号,麻烦帮忙修复下，谢谢https://mirrors.huaweicloud.com/kubernetes/https://mirrors.huaweicloud.com/kubernetes/yum/repos/kubernetes-el7-x86_64/repodata/primary.xml本厂商同步镜像列表截止yum list kubeadm --showduplicates .... kubeadm.x86_64                              1.14.2-0                                kubernetes其它厂商同步镜像列表截止：yum list kubeadm --showduplicates .... kubeadm.x86_64                              1.14.2-0                                kubernetes kubeadm.x86_64                              1.14.3-0                                kubernetes kubeadm.x86_64                              1.14.4-0                                kubernetes kubeadm.x86_64                              1.14.5-0                                kubernetes kubeadm.x86_64                              1.14.6-0                                kubernetes kubeadm.x86_64                              1.14.7-0                                kubernetes kubeadm.x86_64                              1.15.0-0                                kubernetes kubeadm.x86_64                              1.15.1-0                                kubernetes kubeadm.x86_64                              1.15.2-0                                kubernetes kubeadm.x86_64                              1.15.3-0                                kubernetes kubeadm.x86_64                              1.15.4-0                                kubernetes kubeadm.x86_64                              1.16.0-0                                kubernetes kubeadm.x86_64                              1.16.1-0                                kubernetes

1. 云计算开源框架    全球云计算的龙头亚马逊近日风光无限，成为继苹果公司之后，第二个市值突破万亿美元的公司。但是市盈率却高达400倍，而同期苹果公司却只有20倍。暂且不说亚马逊能否撑起如此之高的市盈率，可见全球市场对云计算持有乐观的发展预期。云计算的概念在2006年由谷歌首次提出，大约经过10年的探索和技术积累，在2015年开始进入应用的繁荣期。    亚马逊占据了市场60%的市场份额，具有绝对领先的地位。亚马逊的CEO贝佐斯要求开发人员按照SOA理念来进行开发，即面向服务的理念，要求所有程序模块必须要用服务接口把数据和功能开放出来，这种设计理念也奠定了现在AWS的基本技术基础。1.1 OpenStack的诞生和繁荣    当然参与云计算的公司一直都很多，在2010年7月，RackSpace和NASA(美国国家航空航天局)，分别捐献出RackSpace云文件平台代码和NASANebula平台代码，OpenStack由此诞生。OpenStack作为AWS的追随者，其设计理念和AWS都非常的相似，核心组件包括计算（Nova）、对象存储（Swift）、认证（Keystone）、用户界面（Dashboard）、块存储（Cinder）、网络（Neutron）和镜像服务（Glance），这些组件协同工作为用户提供计算、网络和存储等硬件资源。    OpenStack这种DIY的设计模式受了极大追捧，而且OpenStack涉及的概念和调用接口也和AWS一致。用户可以把AWS上的应用无缝迁移到基于OpenStack的云平台上，思科、IBM、HP等一些列的IT巨头纷纷基于OpenStack推出了自己的公有云平台。OpenStack不光在公有云上作为AWS的替代者，而且在私有云领域也打破了VMware公司在服务器虚拟机的垄断。全世界的云计算工程师都为之欢呼，因此基于OpenStack的产业链也就诞生了。    国内出现了很多基于OpenStack的创业公司，比如united stack、easystack、awcloud等。拥有最多数据中心的三大运营商，也分别成立云计算分公司并组建OpenStack团队。还有一些金融等传统行业也成立自己的事业部，志在基于OpenStack打造自己的私有云。互联网巨头腾讯和百度，也有自己的OpenStack团队和对应的产品。所以在OpenStack黄金会员里面，我们华人公司占据了一半的席位。    随着OpenStack的蓬勃发展，其笨重、性能等缺陷日益显露。部署起来非常复杂，光部署工具就有很多种；使用起来性能也不是太好，非常多的重复代码。而且社区管理也有问题，功能组件繁多且重复，围绕OpenStack有100多个项目，各个厂商利益角逐。就比如裸机管理项目最开始是ironic，后面华为和intel又搞出来mogon。两个项目只是代码框架不同却是实现相同的功能，这样的情况并不是特例，这无疑分散了OpenStack的研发实力。    有些PTL和TC更是想把自己的项目脱离OpenStack单独部署，无非是想脱离走下坡路的OpenStack社区。目前社区的一些任务目标，PTL响应也不够，完成度更不用说了。因为随着OpenStack的衰落，公司支持力度下降，有些PTL都是兼职自愿奉献社区。就比如Trove项目的前任PTL，因为Tesora被收购一拍屁股走人，我们国人接过来trove的PTL重担，但是2018年温哥华峰会的时候，据说因为其个人原因没有如期参加吧，也饱受批评。    OpenStack经历了短暂的繁荣期，2015年惠普把EG（中国惠普企业集团）51%的股份卖给了紫光股份，并于次年2017年9月彻底解散了国内云计算团队；惠普美国云计算也纷纷有大佬离职，并把OpenStack组件资产卖给了SUSE，表示SUSE将是其OpenStack业务发展的首选合作伙伴。思科也在2017年3月关闭基于OpenStack的Intercloud公有云服务，并宣称将专注于混合云和网络虚拟化服务的提供。IBM也在2018年放弃OpenStack，转向做kubernetes去了。    但是国内在云计算领域公有云份额很少，私有云份额很大占到95%，所以仍然有很多厂商在私有云领域采用OpenStack，至于公有云的话，OpenStack框架确实也不太适合。国内华为、金山等公有云厂商，虽然使用的OpenStack，但是基本上功能已经改了很多了。1.2 Kubernetes的开场    伴随着OpenStack的衰落，Kubernetes已经成为新贵。说到Kubernetes，不得不说一下docker。2013年3月dotcloud公司推出了一项新的容器技术Docker。说到容器技术，也不是什么新技术，只是非常的小众。然而Docker的出现，降低了容器技术使用的门槛，带来了无可比拟的优势，所以迅速在IT行业内普及。不光是IT工程师，还是产品经理等非技术工作人员，人们争相讨论着容器化会带来哪些便利和优势，也像OpenStack一样催化了无数的创业公司。    但是在Docker发布的初期，受到了谷歌、IBM等互联网巨头的挤压，同期也有CoreOS推出的rkt等容器技术作为有力的竞争者。互联网巨头纷纷站队，或者推出自己的容器技术。互联网巨头有着众多的研究人员、雄厚的经济实力和丰富的项目经验，初创公司对此毫无招架之力。    于是Docker的创始人决定把Docker开源，让全世界的感兴趣的容器工作者参与其中，无疑增加了研发实力。然后建立了全世界最丰富的镜像仓库，使用者可以在这里找到自己想要的镜像，间接也增加了docker的用户群。最后就是通过融资，收购了一些容器编排相关的创业公司来提升自己的整体实力。    这样的竞争持续了两年多，最终在DockerCon 2015上，Docker的创始人和CoreOS的创始人最终握手言和，并成立runC项目，和基金会一起维护容器的标准。此时Docker已然给云计算、应用交付等多个领域带来巨大的革新。    随着Docker的普及和使用，其自身的性能无法满足大规模集群的使用，需要一个工具对成千上万个容器进行统一编排。在2015年又开始了容器编排之争，行业内最主要的三个编排框架分别是docker公司的swarm、google的kubernetes以及Apache mesos。Mesos是参考谷歌的borg大规模集群管理系统，并于2009年推出的。swarm和kubernetes是为docker等容器技术，新推出的框架。swarm是docker公司发布的，有近水楼台先得月的优势。kubernetes是参考谷歌的borg系统10几年的容器管理经验，重新推出的一套容器管理框架，可谓含着金钥匙出身，kubernetes迅速得到了微软，红帽等支持。这场战争不用打，或许都已经猜到结局是什么，战争的胜利只是一个时间问题。    Docker公司的用户大部分是IT开发人员，所以靠这些用户带来盈利是非常难的。Docker公司在2017年1月把docker分为社区版docker-ce和商业版docker-ee，一直没有放弃盈利的机会，但是也一直没有找到盈利的方式。终于，2017年10月的dockerCon峰会上，docker公司官方支持Kubernetes，确立了kubernetes成为了容器编排界事实上的标准。    2018年初docker的母公司cloud control还一度传出资不抵债要破产的节奏。有人说docker和kubernetes的出现加速了OpenStack的衰落，确实容器技术会抢占一部分虚拟机的市场。但是OpenStack的衰落自身也有原因，包括OpenStack也有些容器相关的项目，但是在我看来顶多算个自我救赎而已，始终不能摆脱那个复杂的框架。2. IoT下IaaS架构的选择    国内阿里涉足云计算领域比较早，所以阿里云采用的是自身研发的云计算架构，其余公司都或多或少的采用开源的云计算架构。所以在4月26日云栖大会·南京峰会上，阿里云副总裁李津表示：“中国只有两种云，一种是拿来主义的云，一种是自主可控的飞天云”。当然这不完全准确，但也能反映目前国内公有云和私有云市场现状。    日前，美国权威调研机构Gartner发布了全球公共云市场份额报告(2017年)。从报告中可以发现，全球公有云前三市场份额占到66%，且持续扩大。另外Gartner的“2018年全球公共云魔力象限”也有所体现，2017年有14家企业入围魔力象限，而2018年只有6家，这也意味着全球云计算市场头部企业和尾部企业差距逐渐拉大。与国际市场不同的是，我们国内IaaS市场是阿里云一家独大，但是PaaS层和SaaS层才刚刚发展，所以不失为一个突破口。先看一下，谷歌云的IoT的框架图     把物联网设备通过某种协议，接入到IoT云平台。IoT云平台对外提供API接口，我们可以通过接口控制物联网设备。谷歌在物联网和AI这一块做的比较成熟，还开发了对应的物联网芯片cloud edge，可以直接植入到散布在全球各地的物联网设备。在云平台一侧，开发大数据分析的模块big query，更加方便第三方厂商对物联网设备的数据进行分析，打造从芯到云的整个产业链。    我们目前还处于的初级阶段，第一阶段首先实现物联网设备接入到自研IoT云平台，然后APP调用IoT云平台对外的API接口，控制和收集设备的状态。使用户利用从分布在全球的设备获得的数据，实时发掘业务数据洞见。IoT平台收集的设备数据将发布到订阅和发布系统以进行下游分析。目前支持简单的大数据分析，丰富的报表和**以可视化的方式呈现物联网数据结果。    IaaS层要为IoT PaaS平台提供动态可扩展的网络、计算和存储等资源。初期网络的流量主要是设备到IoT后台服务、app和Iot后台服务之间的交互，所以网络模型相对简单。网络的峰值一般会出现在一天中的晚上某个时刻，这个时候后台服务的压力就比较大，相应的要求更多计算资源。对于存储的话，前期阶段主要是物联网设备的数据和用户的数据，存储量比较少。    综合上面的因素，高峰期时对计算的要求比较大，然而网络和存储的要求比较简单。所以选择轻量级的docker+kubernetes能实现高峰期的自动扩容，而且也支持网络自动化和存储持久化。Kubernetes的社区发展情况来看，更加倾向于服务的治理，即PaaS层的编排工具，但是又有非常丰富的插件，可以直接运行在真实的服务器、虚拟机、国内外公有云上。如果公司有丰富的原始技术积累，还是采用定制化自研云平台，平台升级就不会涉及到与社区版本的兼容性。但是国内的大部分公司由于研发实力不够，一般都采用成熟的开源社区项目，随着上线产品的优化，迭代完善使用的开源框架。3. PaaS和IaaS的共同演进    目前谷歌云IoT业务植入大数据和AI的元素，能够根据用户的物联网设备数据分析出每个用户的习惯等，也提供一些AI的方案供用户选择。随着PaaS层陆续增加大数据和AI等功能，对IaaS的要求也就越来越高。Kubernetes在生产环境上的应用主要是容器编排，在8月份刚刚发布Istio(服务治理)项目生产环境的版本，还没有涉及像IoT等如此细分的生产项目。虽然Kubernetes社区也有AI的孵化项目，但是能不能满足我们的需要，还是要通过实践来验证。    Kubernetes提供了非常丰富的网络插件，说到网络一直是云计算领域的痛点和难点。OpenStack也有非常多的网络插件，这些插件也给使用者带来困扰。我到底选择哪个插件，那这个插件在未来会一直持续活跃下去么，还是说在不久的将来会被社区废弃。我们现在服务间的网络模型也非常简单，所以选用的flannel网络插件，所有的容器都在一个大二层里面。流量限速、网络隔离和安全问题等问题社区还在完善，随着我们业务的增长，我们也可以引入SDN等复杂的网络模型。    计算的方面的话，由于一个个容器不像虚拟机做到真正的隔离，目前是限制容器对cpu和内存的使用率来控制。如果是公有云的话，可能这样会带来潜在的风险，因为我们没有办法确定用户的镜像会不会利用系统的漏洞危害其他容器，或者独占宿主机导致超负载以至于其他容器不能获取到资源。但是我们目前是私有云的形式，我们每个服务、每个镜像都是安全可追溯的。如果后面有对虚拟机和裸机的要求，我们也可以自己开发对应的插件，或者采用OpenStack+Kubernetes的形式，来管理更复杂的集群。    我们的PaaS服务用到了MySql、redis、mogonDB等数据库，还有emq消息队列，这些都是需要持久化存储的。如果服务器发生异常关机，那么要确保服务器启动以后，数据是可以恢复的。Kubernetes提供了ceph、公有云存储等大约20个存储后端，也增加了选型上负担。如果采用公有云提供的稳定的方案得话，可能带来安全和稳定性方面的顾虑。如果采用私有自建云的话，可能需要一定的技术积累。总之，根据业务进行迭代开发，要优于一开始就做大而全的私有云方案。

将kubernetes源加到huaweicloud.com开源镜像站，方便使用。

本文不做深入的技术讨论，仅从 Knative 的基本概念及诞生背景入手，让读者对 Knative 的产生初步了解。下一篇开始将对 Knative 的核心组件：Build、Serving、Event 进行深入解读，并结合我们在日常工作中的案例，让大家对 Knative 从技术到应用有一个全方位的了解。Knative 是什么？2018 年 7 月，Google 在 Google Cloud Next 2018 上发布了Knative，将其定位为基于 Kubernetes 的 Serverless 解决方案，旨在标准化 Serverless，简化其学习成本。自开源以来，Knative 项目备受关注，在 github 上已经获得 1000+ 的 start， Pivotal、IBM、Red Hat 等公司也纷纷成为其重要的合作伙伴。传统 Serverless 之殇既然 Knative 的定位是 Serverless 解决方案，那我们不不妨看看 Knative 之前的 Serverless 解决方案是什么样子。提到 Serverless，开发者往往可以想到一张经典的图片，它描述了传统互联应用架构与 Serverless 架构的不同点，Serverless 架构让开发者在构建应用的过程中无需关心计算资源的获取和运维，由服务提供商按需分配计算资源并保证应用执行的 SLA，商业策略上也不同于传统资源的计费模式，按照调用次数进行计费，避免了资源冗余造成的浪费，有效节省应用成本。Serverless 大体上可以分为两种类型：“Backend as a Service” 和 “Functions as a Service”。BaaS(Backend as a Service) 后端即服务，服务商为客户 (开发者) 提供整合云后端的服务，如提供文件存储、数据存储、推送服务、身份验证服务等功能，以帮助开发者快速开发应用。FaaS(Function as a Service) 函数即服务，服务商提供一个平台，允许客户开发、运行和管理应用程序功能，而无需构建和维护基础架构。按照此模型构建应用程序是实现“无服务器”体系结构的一种方式，通常在构建微服务应用程序时使用。传统的互联网 APP 主要采用 B/S 架构，服务器端需长期维持业务进程来处理客户端请求，并调用代码逻辑完成请求响应流程。而在 Serverless 架构中，应用的业务逻辑将基于 FAAS 架构拆分成多个相互独立的功能组件，并以 API 的形式向外提供服务；同时，不同功能组件间的代码将存储在云服务厂商的函数服务（Function Service）上，如：Amazon Lambda，Azure Function，Google Cloud Functions 等，业务代码仅在被调用时运行，在响应结束时释放资源。然而，传统的 Serverless 解决方案却一直叫好不叫座，这与其自身的问题是分不开的：1.厂商绑定Serverless 只提供了应用本身部署和运行的便利性，但应用依赖的其它服务，比如 API 网关、数据库、消息、缓存管理组件等，会因为选用了某个厂商的 Serverless 平台，而必须使用该厂商提供的配套服务，比如使用 AWS Lambda 就必须配套使用 AWS 的 DB, S3 等产品，这样用户就被该厂商绑定，不能进行随意的迁移或者迁移成本非常高。在 Baas 行业内，一个比较典型的事件是：2016 年 1 月 19 日，Facebook 关闭曾经花巨额资金收购的 Parse，造成用户不得不迁移在这个平台中产生一年多的数据，无疑需要花费比较大的人力和时间成本。2.没有行业标准因为对 Serverless 缺乏统一认知以及相应的标准，Serverless 应用无法适应所有的云平台，只适合简单的应用开发，无法推动形成大型成功案例。Knative：Serverless 大规模商业化实施的基石Knative 提供了一组标准中间件，专注于在云原生平台上构建和运行应用的通用任务，比如源码到容器的构建、将服务绑定到事件生态系统（通过事件触发工作负载的执行）、管理部署期间的路由和流量以及工作负载的自动扩展。该框架为用户提供了“部署任何负载都需要的熟悉的、惯用的语言支持以及标准化的模式，这些负载包括传统的应用，也包括函数或容器应用”。相对于传统的 Serverless 解决方案，Knative 的优良性得到开发者和企业认可，这也是其短时间内得到业内各大厂商追捧的主要原因。细数一下 Knative 的优势，包括：便利性：Knative 以 Kubernetes 和 istio 作为其底层框架，因此无论是线上还是线下，任何 Kubernetes 集群，无论是云上 Kubernetes 服务还是自建 Kubernetes 集群，都能通过安装 istio 和 knative 插件快速的搭建 serverless 平台；标准化：Knative 联合 CNCF，把所有事件标准化，统一为 CloudEvent，提供事件的跨平台，同时让函数和具体的调用方能够解耦；服务间解耦：使用 Knative 使得应用不在与底层依赖服务强绑定，可以跨云实现业务互通；成熟的生态：Knative 基于 Kubernetes 体系构建，与 kubernetes 生态结合更紧密；自动伸缩：监控应用的请求，并自动扩缩容, 得益于 Istio 能力加持，天生支持蓝绿发布、回滚功能，方便应用发布流程。应用监控：支持日志的收集、查找和分析，并支持 VAmetrics 数据展示、调用关系 tracing；目前，Knative 已经发布到 0.5 版本，每一次更新都离客户的最终诉求近了一步，加上 Google, IBM ，Pivotal，Redhat 这样的豪华社区阵营支持，Knative 的未来必定是一片坦途，相信在很短的时间内，我们就能看到基于 Knative 的成功商业化案例。

掌握Kubernetes是非常困难的，因为有如此多的信息漂浮在互联网的海洋上，有时很难找到理解Kubernetes的“核心”信息，尤其是当看到Kubernetes.io的概念页和文档上的信息多么密集时。在这个“Kubernetes”博客系列的第一部分中，我们将探索Kubernetes的核心概念，以获得基本的知识，这样我们就可以一起揭开Kubernetes的神秘面纱。Kubernetes是什么？Kubernetes提供了基本基础和构建块，为你的团队构建一个可用于开发和发布的可用平台。用户可以通过图形用户界面，以及命令式和声明式命令行界面管理Kubernetes集群，旨在管理你的容器化应用程序和服务的整个生命周期。可以上下伸缩应用程序、执行滚动部署并管理哪些服务应该响应某些请求。它还提供了一个可扩展的开发框架，允许你的团队扩展核心kubernetes基本功能，直到他们高兴为止！以及创建自己概念的选项。但是，与大多数框架一样，它的缺点之一是缺少了许多现成的功能，无法分类作为一站式解决方案。在标准发行版中，它不包含关于服务如何相互通信的方法（甚至不包含网络组件！），但有其他发行版存在，你也可以构建自己的发行版。容器（Container）容器是一个独立的、可执行的软件，它包含运行容器所需的所有内容。例如代码、库和任何外部依赖项。它确保运行的内容是相同的，即使运行在不同的环境中也是如此。这是通过将运行代码与其执行环境隔离来实现的。这在Linux中是通过使用称为cgroup的API来分割Linux内核的子集来实现的。这提供了与操作系统的高度隔离，但没有虚拟化环境运行时性能的影响，如VMWare、KVM等。PodPod是Kubernetes中最基本的物件。Pod是容器的集合，共享存储和网络，有关于如何运行它们的规范。每个Pod获分配自己的IP地址。Pod中的容器共享这个IP地址、端口空间，并且可以通过localhost彼此查找。Pod应该被看作是短暂的基本功能。Replicaset一个replicaset根据提供的模板运行n个Pod。Replicaset不被直接使用，但是需要理解该资源，因为它是用于在Kubernetes上构建应用程序的基本构建。Replicaset可以（在指示下）按比例增加或减少所需的Pod数量。服务（Service）由于Pod是短暂的（Replicaset通过上下伸Pod的数量来实现这一点），就出现了一个问题；现在，如果没有跟踪拓扑变化的复杂逻辑，几乎不可能引用单个pod。服务通过提供对Pod的抽象和提供与Pod通信的可寻址方法来解决这个问题。服务在OSI模型中“第4层”（IP上的TCP/UDP）操作。部署（Deployment）部署管理Replicaset，并可用于在应用程序的不同版本之间运行滚动升级。这是最常用的资源类型，它通过一个接口提供了对Replicaset和Pod的抽象。在更新此部署的情况下，也就是说，部署应用程序的新版本，部署控制器将创建一个新的Replicaset，并管理从旧版本到新版本的滚动升级。ConfigMap设计良好的应用程序应该遵循12因素的应用程序声明，对于应用程序的配置，应该将配置存储在“环境”中。尽管现在常见的安全实践指出，在环境中存储配置可能会导致机密的意外泄漏，因为一些应用程序在失败时抛出了它们的环境，但是配置应该与构建的应用程序分开存储，因为每个环境都有配置更改。(开发、临时、生产)。ConfigMap允许将配置文件作为环境变量或文件系统挂载到Pod中，从而解决了这个问题。秘密（Secret）Secret非常类似于ConfigMap，它们跟名称一样，是“秘密”[1][2][3][4]。DaemonsetDaemonset确保所有节点运行特定的Pod。这对于在所有节点上运行诸如fluentd之类的日志代理非常有用。也可以通过使用污点（Taint）略过某些节点。入口（Ingress）在大多数情况下，服务和Pod的IP地址只能从Kubernetes集群中访问。服务与互联网流量隔离。“入口是允许入站连接到达集群服务的规则集合。”它可以用于负载平衡、终止TLS、提供外部可路由URL等等。一个入口只是另一个Kubernetes资源，然而，在大多数情况下，它需要有一个入口控制器（Ingress Controller）像Nginx或Træfik等。Kubernetes是一个用于自动化容器编排的平台，使应用程序能够在大量平台上大规模运行，这些平台可以包含处理器体系结构和操作系统的组合，由实现者决定。使用这些核心概念，Kubernetes可以将Pod编排到适当的节点上，由Kubernetes实现多种算法（如Bin Packing）来控制，以确保Pod的最大密度，从而实现更高的硬件容量利用率。

 kubernetes管理员实训培训介绍本系列课程参考CKA (Certificted Kubernetes Administrator)* 知识体系进行课程设计，并结合华为在kubernetes项目推广过程中的实践经验，理论+实践让用户快速掌握kubernetes的使用和维护技能。课程主题直播介绍观看回放材料下载CKA考纲与K8S基础概念解读点此了解点击观看点此下载K8S调度管理实训点此了解点击观看点此下载K8S日志、监控与应用管理实训点此了解点击观看点此下载K8S网络管理实训点此了解点击观看点此下载K8S存储管理实训点此了解点此观看点此下载K8S安全管理实训点此了解点此观看点此下载K8S集群运维与安装配置实训点此了解点此观看点此下载K8S问题排查实训点此了解点此观看点此下载注：CKA (Certificted Kubernetes Administrator) 由 Linux 基金会和 CNCF 联合推出的一项认证计划。详见官网： https://www.cncf.io/certification/cka。主讲大咖介绍王泽锋华为云 Kubernetes 开源负责人，Kubernetes Maintainer华为云PaaS 服务团队核心成员，专注于PaaS产品和容器开源社区。曾主导社区NodeAffinity，PodAffinity，Taints-Tolerations，Forgiveness等多个关键特性的设计开发，对K8S有深入的见解。目前负责华为云K8S开源团队在社区贡献的整体工作。杜军华为云高级工程师，Kubernetes MaintainerKubernetes核心维护者，主导了Network SIG多个核心特性设计、开发，同时是Scheduling, Cluster-lifecycle SIG的子项目owner王波华为云容器服务高级工程师华为云容器服务核心开发者，K8S社区贡献者，负责华为云容器服务多个核心组件设计与开发，对Kubernetes有深入理解。Gloria.Zhao华为云高级工程师华为云容器核心开发者，负责华为云容器服务的设计与核心组件开发，对kubernetes有深入理解。

Cloud Native Lives之深入剖析Kubernetes系列课：课程主题直播介绍观看回放资料下载云原生技术的前世今生点此了解观看回放下载K8s初体验-快速部署第一个容器应用 点此了解观看回放下载K8s工作负载原理剖析和体验 点此了解观看回放下载K8s调度器原理剖析和实践点此了解观看回放下载K8S网络原理剖析和实践 点此了解观看回放下载K8S服务发现与负载均衡原理剖析与实践点此了解观看回放下载K8S存储原理剖析与实践     点此了解观看回放下载K8S安全原理剖析和实践点此了解观看回放下载优质品牌课程介绍：Cloud Native，云原生是云计算必然的发展方向。自从Cloud2.0时代来临，许多公司都希望完成传统应用到云端的迁移，但是这个过程中会遇到一些技术难题。云原生包含了一组应用的模式，用于帮助企业快速，持续，可靠，规模化地交付业务软件。云原生的出现，可以改进应用开发的效率，改变企业的组织结构，甚至会在文化层面上直接影响一个公司的决策。Cloud Native Lives，系列直播将带你走进云原生技术的核心，深入浅出的为您讲解云原生技术的方方面面：容器化、微服务、动态管理。结合CNCF（Cloud Native Computing Foundation）社区的成功项目，为您剖析它们的原理及核心技术架构，并在课程中进行实践操作，帮助您快速理解掌握云原生的内涵。讲师团队主要由华为云容器服务团队的核心架构师组成，包括多名CNCF社区的maintainer、committer，负责、参与了多个CNCF社区项目的设计和开发，将带给您最原汁原味云原生讲解。

1性能增强虽然Istio1.0的目标是生产可用，但从去年7月份发布以来，在性能和稳定性上并不能让用户满意。社区的Performance and Scalability工作组在Istio v1.1中做了大量的努力以提高控制面和数据面的性能，其中最明显的性能增强包括：Sidecar API，减少发给proxy的配置数量以及pilot负载。网络配置规则（Destinationrule,Virtualservie, ServiceEntry）中增加的 exportTo字段限制配置的可见范围。Envoy默认收集的统计数据大量减少。给mixer增加load-shedding功能，防止overload。提升envoy和mixer之间的交互协议。可配置并发线程数，提高吞吐量。可配置filter来约束mixer遥测数据。从对Istio 1.1的测试数据来看，这部分工作取得了显著的效果。1.1控制面性能表现Pilot的CPU和内存使用受网格内的配置和系统状态的影响，例如负载变化速率，配置变化速率，连接到Pilot的proxy的数量等。可以通过增加Pilot的实例数来减少配置分发处理的时间，提高性能。在网格内有1000个服务，2000 个sidecars，每秒1000请求下的表现：单Pilot 实例使用 1 vCPU 和1.5 GB 的内存。istio-telemetry服务使用0.6 vCPU。1.2数据面性能表现CPU：proxy在每秒1000个请求下大约消耗0.6 vCPU 。内存：proxy的内存消耗主要取决于它需要处理的配置数量，大量的listeners, clusters, and routes配置会增加内存使用。proxy每秒1000个请求下大约消耗50MB的内存。时延：数据在传输时会通过客户端和服务端的sidecar，传输路径上的这两个proxy在1000 rps情况下，99%的请求时延是10 ms（TP99），单独server端的proxy增加6ms的时延。如果启用策略会进一步增加时延。2多集群方案在1.0中只提供了一种基于扁平网络的多集群方案：Istio控制面部署在一个Kubernetes集群中。这种方案要求各集群的 Pod 地址不能重叠，且所有的 Kubernetes 控制平面API Server 互通。看上去就是物理上把多个Kubernetes并到一个Istio控制面下，在Istio看来是同一个网格。这种方案的网络要求苛刻，实际应用并不多。在新发布的1.1版本上，多集群上做了非常多的增强，除了保留1.0扁平网络作为一种单控制面的方案外，还提出了另外两种方案供用户根据实际环境和需求灵活选择，这两种方案都不要求是扁平网络：多控制面方案：在每个集群中安装完整的Istio控制面，可以看成是一种松散的联邦，集群间服务在Gateway处联通即可。通过一个全局的DNS将跨集群的请求路由到另外一个集群里去。这种集群的访问是基于Istio的ServiceEntry和Gateway来实现的，配置较多且复杂，需用户自己维护。一种集群感知（Split Horizon EDS）的单控制面方案：Istio控制面板只在一个Kubernetes集群中安装，Istio控制面仍然需要连接所有Kubernetes集群的Kube API Server。每个集群都有集群标识和网络标识。在服务间访问时，如果目标是本集群的负载，则类似单集群的方式直接转发；如果是其他集群的实例，则将流量转发到集群的入口网关上，再经过网关转发给实际对端。3安全3.1HTTP Readiness Liveness Probe自动重写mTLS模式下，进入Envoy的HTTP请求会在TLS握手阶段被拒绝。1.1新增加了HTTP Probe的自动重写，通过将HTTP Probe请求发送到pilot-agent由其转发HTTP探测到应用，进而绕开Envoy的TLS认证。默认自动重写是关闭状态，用户需要根据实际需要打开。3.2集群级别的RBAC设置ClusterRbacConfigRbacConfig被标记为废弃，用户升级1.1后，必须迁移到使用ClusterRbacConfig。因为RbacConfig有bug，在一些情况下，其作用范围会被缩小到命名空间。3.3SDSSDS（SecretDiscovery Service）通过节点密钥生成提供更强的安全性以及动态的证书回滚。可以取代目前使用secret卷挂载的方式提供证书。1.1中目前为alpha，不建议生产环境使用，但是随着Istio发展值得期待。3.4授权新增对TCP类型服务的RBAC授权以及基于用户组的授权。3.5Vault集成允许用户集成开源Vault，使用Vault CA签发证书。4网络4.1新的sidecar API资源在1.1中引入Sidecar这资源对象可以更精细的控制Envoy转发和接收的端口、协议。在指定命名空间中使用sidecar资源时，支持定义可访问的服务范围。这样可以降低发给proxy的配置的数量。在大规模的集群中，我们推荐给每个namespace增加sidecar的对象。 这个功能主要是为了提升性能，减轻pilot计算的负担。对proxy的影响是：1. 内存占用少，2. 降低网络带宽占用。  4.2exportTo在Istio1.1版本中添加了一个重要字段exportTo。用于控制VirtualService、DestinationRule和 ServiceEntry 跨Namespace的可见性。这样就可以控制一个Namespace下定义的资源对象是否可以被其他Namespace下的Envoy执行了。如果未赋值，则默认全局可见。当前版本中只支持“.”和“*”两种配置。 “.”表示仅应用到当前Namespace。“*”表示应用到所有Namespace。4.3Locality based loadbalancerIstio 1.1 引入了负载均衡新特性：基于位置的负载均衡。这也是华为主导的新特性。目前是alpha特性，只支持服务网格全局的位置感知的负载均衡设置：基于位置权重的负载均衡设置（Locality-weighted load balancing）：Locality-weighted load balancing允许管理员基于流量来源及终止的位置信息控制流量的分发。例如可以设置从源位置{region}/{zone}/{sub-zone}的工作负载发出的流量转发到目的位置的endpoints负载均衡权重：用户可以为相同区域的工作负载访问设置较高的权重，为不同区域的工作负载设置较小的权重，减少网络延迟。基于位置的故障转移设置：类似于Envoy的“Zone aware routing”负载均衡策略，基于位置的故障转移特性，通过为不同的位置的endpoints设置不同的优先级，控制流量的转发策略。默认设置如下，同一位置{region}/{zone}/{sub-zone}的endpoints优先级最高，同一{region}/{zone}的endpoints优先级次之，同一region的endpoints第三，最后故障转移设置区域以及其他区域的endpoints依次。endpoints全部健康的情况下，流量只会在同一{region}/{zone}/{sub-zone}转发。当endpoint变得不健康时，会进行相应的降级处理，选择低优先级的endpoints转发。4.4pilot配置资源发现Istio1.1将galley作为默认的 配置规则发现中心，pilot通过MCP协议与galley进行配置订阅，取代1.0以前直接从Kubernetes以CR的方式watch配置资源。5策略和遥测默认关闭策略检查功能 为了提高多数客户场景下的性能，安装时默认关闭策略检查， 后期可按需开启此功能。弃用ServiceGraph，推荐使用 Kiali：提供了更丰富的可视化体验。多方面降低开销 ，提升性能和可扩展性：o 减少Envoy生成的统计数据的默认收集o Mixer的工作负载增加load-shedding功能o 改进Envoy和Mixer的通信协议控制请求头和路由 增加选项使适配器可以修改请求头和路由进程外适配器 进程外适配器功能生产可用，下个release弃用进程内适配器。多方面增强Tracing的能力： o Trace id支持128bit的范围o 支持向LightStep发送追踪数据o 增加选项完全禁用Mixer支持的服务的追踪功能o 增加策略的decision-aware 追踪默认的TCP指标 为追踪TCP连接增加默认指标降低Addon对Load Balancer的依赖 不再通过独立的load balancers对外暴露addons，而是通过Istio gateway来暴露插件服务。安全的Addon证书 改变插件的证书存储方式。Grafana, Kiali, and Jaeger的用户名和密码存放在kubernetes的secrets中以提高安全性和合规性。去除内置的statsd collector。Istio目前支持用户自己的statsd，以提高现有Kubernetes部署的灵活性。另外，Istio运维管理的复杂度也不能被部分用户接受（比如：众多的crd资源），因此社区专门成立了User Experience工作组致力于提高Istio的易用性，进一步降低其使用门槛。经过大家的共同努力，Istio1.1版本几经推迟终于发布了！我们有理由对其充满期待和信心，共同催熟以Istio为代表的云原生服务网格技术，为我们的用户提供高品质的云服务体验。欢迎试用华为云应用服务网格Istio。相关服务请访问： https://support.huaweicloud.com/cce/index.html?utm_content=cce_helpcenter_2019

之前给大家讲了构建镜像的原理，那么有了镜像之后，我们怎么样能将它快速的部署到kuberentes集群上呢？ 早期，大家都习惯于使用kubernetes接口，或者cli命令行来完成这些操作，但是yaml文件语法的复杂性、大量容器和kuernetes的概念，让人难以理解，无疑成为容器化交付路上的又不障碍。为了解决这些问题，华为云容器服务推出了向导式镜像部署，通过一步步引导、对复杂概念的屏蔽或抽象，在一定程度上降低了用户首次部署镜像的难度，但是灵活度相对较差，对于经常变更版本的场景，还是需要使用原生接口进行操作，使得整体研发交付流程的复杂度并未降低太多。鉴于此现状华为云容器团队又推出了一款易用性更好、自动化程度更高的服务产品——容器交付流水线，它以容器技术为基础，践行DevOps的理念，围绕容器业务端到端场景提供持续集成和持续交付能力，包括代码编译、镜像构建与交付、自动化部署、升级回滚等能力，并提供全量能力接口，便于与企业已有流程相结合，同时接口屏蔽底层容器概念，对接口进行了二次封装，接口定义更贴近于CI/CD业务概念，使得熟悉CI/CD流程的用户能快速切换。发布组件作为该产品的一个重要组成部分，其直接影响了整个发布周期，我们今天就跟大家一起聊聊该部件的一些实现原理。01Kubernetes DeploymentKubernetes Deployment提供了官方的用于更新Pod和ReplicaSet（下一代的Replication Controller）的方法，我们可以在Deployment对象中填写我们需要用到的配置和版本信息，Deployment控制器将现在的实际状态转换成我们所期望的状态，例如，将nginx:v1.0升级成nginx:v2.0，我们只需创建一个Deployment，Kubernetes会按照Deployment自动进行升级。而随着Kubernetes的迭代更新，目前云容器引擎服务提供了几个版本的集群，那么如何使得部署组件支持不同的集群版本呢？由于我们的CI/CD的工具提供了deployment的yaml页面编辑，部署组件会根据deployment中apiversion即：apps/v1, apps/v1beta1, extensions/v1beta1。提供不同版本的API接口。自行封装接口使得发布组件自主能动性强，免于受制于第三方库。02如何判断发布成功？解决了版本问题，还有一个最重要的问题，是如何判断组件发布结果呢？对于一个CI/CD工具，我们判断工作负载运行成功的标准并不仅仅是Pod处于running状态又或者工作负载处于可用状态。我们需要保证的是工作负载运行的镜像或者配置是新版本的。因此我们判断成功的标志应该是新起的pod处于running状态，那如何找到这些新起的pod呢？下图展示了Deployment，ReplicaSet和Pod之间的关系，以无状态工作负载为例，我们通过查询deployment中Annotations的"deployment.kubernetes.io/revision"，根据这个revision寻找Deployment控制的ReplicaSet。最后根据ReplicaSet的label去寻找这些新起的pod。我们已经找到这些新起的Pod了，那么现在就需要对pod的状态进行分析了。在K8s源码中PodPhase字段表示了pod的不同阶段：Pending: k8s已经接受创建pod的请求，但是容器并没有启动成功，这个阶段包括调度之前的，下载镜像等。 Running: pod已经绑定到node节点，并且所有的容器已经启动成功，或者至少有一个容器在运行，或者在重启中。 Succeeded: pod中的所有的容器已经正常的自行退出，并且k8s永远不会自动重启这些容器。 Failed: pod中的所有容器已经终止，并且至少有一个容器已经终止于失败（退出非零退出代码或被系统停止）。 Unknown: 由于一些未知的原因，无法获得pod的状态，通常是因为pod的主机通信错误。而以上四个阶段只是一个粗略状态阶段。而对于每一个阶段都有更详细的pod conditions信息，podcondition数组的元素都包含了类型和状态字段，这个类型分为以下四种:"Ready"：Pod能够提供服务"PodScheduled"：pod正处于调度中"Unschedulable"：调度程序现在无法调度Pod，例如由于缺乏资源或其他限制;"Initialized"：所有pod的容器初始化已经完成。"ContainersReady"：pod中的容器都已准备好。其中状态字段用"true" 表示处于,"false"表示不处于，我们发现当阶段为Running, condition中Ready状态为True时， 即表示pod中的容器可以提供服务了。因此，我们现在就可以依次判断新起的pod是否升级成功了。03如何判断发布失败？现在我们能够判断成功了，下一步就需要对失败的状态进行一个判断，其实理论上负载的成功或者失败不是一个确定性的东西，k8s本身具有重试机制，也存在概率性调度失败的情况。所以一开始我们考虑的是通过一个超时机制来判断发布失败的情况。但后面分析考虑到，发布作为一个重要的组件，需要第一时间知道问题所在，以致可以快速进行版本回退等操作。对于容器的状态，pod中的containerstatus包含了更详细的当前容器的状态。其state字段表示容器当前的状态，state分为三种状态：等待中，运行中和已终止，对应三种不同类型的结构体。等待中的结构体包含了处于非运行状态的原因和信息。其他结构体就不在此一一赘述。结合podphase、podcondition、以及containerstatus，我们总结了如下几个升级异常状态（如有不全，欢迎补充）：PodPhase == FailedPodPhase == SucceededContainerStatuses 中有一项为state.waiting 并且 waiting 的原因不是ContainerCreating 或者 PodInitializing(ContainerCreating表示容器创建中，PodInitializing表示pod初始化中)ContainerStatuses 中有一项为state.running 并且 containerStatuses.ready == falseConditions中存在一项的type为Ready且status为False且Containerstatues存在Conditions中存在一项的type为PodScheduled且status为False：调度失败由于pod的状态是动态变化的，为了保证发布结果的准确性，我们选择pod超过3次时置为失败状态，即发布失败。看完上面这些原理解析，您是不是有什么收获，或者有什么想法与我们交流呢？请在下方留下您宝贵意见和建议吧？说不定下个版本，您的创意就会出现在我们的产品里。相关服务请访问https://www.huaweicloud.com/product/swr.html?cce_helpcenter_2019