引子随着云原生技术的普及，越来越多的企业使用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自身以及周边关联的多个技术领域开展了相关工作。转载自：华为云开发者论坛

一、几个概念：kubernetes/pod/docker/container1.K8S，就是基于容器的集群管理平台，它的全称，是kubernetes2.Docker本身并不是容器，它是创建容器的工具，是应用容器引擎。3.pod是k8s中的最小部署单元，不是一个程序/进程，而是一个环境4.一个pod可以运行1个或多个container详情请点击博文链接：https://bbs.huaweicloud.com/blogs/163511

摘要：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

云早报，(北京时间)8月22日，星期四【云头条】百度云支持Rancher Kubernetes平台8月21日消息，百度智能云与容器管理软件提供商Rancher Labs宣布达成战略合作，在Rancher开源版（v2.2.5及以上版本）和企业版中正式集成百度智能云集群驱动。用户可以在Rancher平台上调用百度智能云API直接创建和管理基于百度智能云CCE服务上托管的Kubernetes集群。【华为云】 一图读懂基于鲲鹏处理器的全栈混合云华为云Stack6.5 （查看原文）【互联网新闻】1.为减少对三星依赖，苹果委托京东方测试最新尖端iPhone屏幕据外媒报道，为了削减成本开支，并减少对韩国三星电子公司的依赖，苹果正委托中国顶级显示器制造商京东方测试最新尖端iPhone屏幕。目前，京东方对新款iPhone屏幕的认证测试已进入最后阶段。据消息人士透露，苹果正在“积极测试”京东方的柔性OLED屏幕，这增加了苹果首次从中国采购这种先进显示技术的可能性。他们表示，苹果将在今年年底前决定是否将京东方作为其最昂贵组件的供应商。2.达摩院发布新一代自研语音AI芯片技术8月21日消息，在美国旧金山举行的芯片行业顶级学术会议HOTCHIPS上，阿里巴巴达摩院发布新一代AI语音FPGA芯片技术——Ouroboros。据阿里达摩院介绍，该技术能将语音生成算法的计算效率提高百倍以上。Ouroboros芯片技术除了语音合成之外，还将支持AI语音识别。基于Ouroboros研发完整的语音AI芯片，有望率先在天猫精灵上落地。3.IC Insights发布Top15半导体公司名单8月20日消息，近日，IC Insights发布最新全球半导体研究报告，报告显示，全球Top15半导体供应商的销售额在2019年上半年下降了18%，其中，索尼成为唯一一家销售额实现同比增长的半导体供应商；三星、SK海力士和美光科技（Micron）2019年上半年营收下降至33%。Top15公司中，英特尔三星台积电前三，有9家在2019年上半年的销售额至少为50亿美元，但与2018年上半年相比少了一家。而进入2019年上半年全球Top15的半导体供应商，它们的销售额均不低于37亿美元。与此同时，与2018年上半年相比，2019年上半年有两位新加入全球Top15阵营的半导体厂商，分别为联发科和IDM索尼。4.数据分析服务Splunk超10亿美元收购SignalFx据外媒报道，数据分析软件公司Splunk周三表示，将以约10.5亿美元现金加股票的价格收购私人持股的云计算软件公司SignalFx。Splunk股价在美国股市的盘后交易中上涨7.4%，至137.99美元。5.英特尔推出首款AI处理器Springhill8月21日消息，英特尔周二发布了为大型计算中心设计的新款处理器Springhill，这是该公司首次使用人工智能技术开发的芯片。英特尔表示，Springhill芯片是在该公司旗下位于以色列海法的研发设施开发的，以10纳米Ice Lake处理器为基础，能用最小的耗电量处理高工作负荷。该公司称，Facebook已经开始使用这款产品。6.百度飞桨推端侧推理引擎Paddle Lite8月21日消息，百度深度学习平台飞桨（PaddlePaddle）发布端侧推理引擎Paddle Lite。该推理引擎在多硬件、多平台以及硬件混合调度的支持上更加完备，是飞桨在Paddle Mobile的基础上进行的一次大规模升级迭代。目前，Paddle Lite已经支持了ARM CPU，Mali GPU，Adreno GPU，华为NPU以及FPGA等诸多硬件平台，是目前首个支持华为NPU在线编译的深度学习推理框架。此外，Paddle Lite还进一步完善提供了Web前端开发接口，支持javascript调用 GPU，可在网页端快捷运行深度学习模型。7.OpenAI公布7.74亿个参数的GPT-2模型8月21日消息，据外媒报道，OpenAI今天公布了包含7.74亿个参数的GPT-2模型，同时还分享了一项开源法律协议，以帮助创建大型AI模型的公司建立自己的模型共享协议。GPT-2是OpenAI于今年2月份发布的一款先进的会话式AI模型，也是当时规模最大的会话式AI模型，总计包含约15亿个参数，当时发布了包含1.17亿参数的GPT-2模型缩减版本。8.高通LG和解 签署新5年期专利授权协议8月21日消息，据路透社报道，高通公司今日宣布，已与LG电子签署一项新的5年期专利授权协议，以开发、制造和销售3G、4G和5G智能手机。该协议的条款与高通既定的全球专利许可条款一致。LG电子今年6月曾表示，该公司与高通在续签芯片授权协议方面仍存在分歧。LG电子还向美国法院提出诉讼，称高通想通过其专利收取高昂授权费的做法触犯了反垄断法。随后，法院作出判决，要求高通向LG电子提供一份不违反相关规定的专利许可协议。高通与LG电子的授权协议已于6月底到期。9.Facebook将推新闻服务 放弃算法用人工8月21日消息，据外媒报道，Facebook一直依赖“算法”来为用户选择新闻；但如今，Facebook要用人工编辑为用户提供更高质量的新闻内容。Facebook本月早些时候曾证实，正在开发一项新闻服务News Tab（新闻标签）。该产品将于今年秋季推出，旨在向Facebook用户提供“值得信赖的新闻”。今日，Facebook表示，该公司计划聘请一支编辑和记者团队，为即将推出的News Tab服务保驾护航。10.AI创企H20.ai获得7250万美元D轮融资8月21日消息，据路透社报道，人工智能创企“H20.ai”周二宣布，公司已获得7250万美元的D轮融资，由高盛集团的主要战略投资部门和中国平安全球领航基金领投，富国银行、英伟达以及Nexus Venture Partners等参投。据悉，本轮融资将用于扩展其全球销售和营销团队，并进一步扩大产品组件。此轮融资之后，H20的总融资金额达到1.47亿美元。【更多内容，欢迎访问】http://forum.huaweicloud.com/forum.php?mod=forumdisplay&fid=569&filter=typeid&typeid=266（内容来源于互联网，如侵犯您的合法权益或有其他任何疑问，请联系：huaweicloud.bbs@huawei.com沟通处理。谢谢！）

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的最大密度，从而实现更高的硬件容量利用率。

云早报，(北京时间)5月17日，星期五【云头条】VMware收购另一家面向Kubernetes的初创公司：BitnamiVMware首席执行官Pat Gelsinger在履行承诺：将容器技术进一步整合到其公司，宣布计划收购Bitnami，收购金额不详。Bitnami专门提供面向容器和Kubernetes环境的应用程序打包技术。VMware战略和企业发展执行副总裁兼Telco NFV集团总经理Shekar Ayyar表示：Bitnami的应用程序打包产品使开发人员能够快速、轻松地将开源和闭源软件部署到世界领先的云提供商以及他们自己的服务器上。一旦交易达成，Bitnami的应用程序打包功能将帮助我们的客户简化在混合云环境中使用应用程序，混合云环境涵盖本地环境、VMware Cloud on AWS以及VMware云提供商计划的合作伙伴云。此前，VMware斥资5.5亿美元收购Heptio，去年8月还收购了多云管理初创公司CloudHealth Technologies。【华为云】 离子钙，吸收快! 哈药&华为云给这支“小蓝瓶”加足了科技味儿! （查看原文）【互联网新闻】1.华为回应：限制华为只能让美国5G落后据**网报道，美国当地时间15日，特朗普签署行政命令，要求美国进入紧急状态，在此紧急状态下，美国企业不得使用对国家安全构成风险的企业所生产的电信设备。另据外媒预测，这是在为禁止美企与华为的业务往来铺平道路。刚刚，华为对此事件作出了回应，全文如下：华为是5G电信设备领域无可比拟的领导者，我们也愿意和美国政府沟通保障产品安全的措施。如果美国限制华为，不会让美国更安全，也不会使美国更强大，只会迫使美国使用劣质而昂贵的替代设备，在5G网络建设中落后于其他国家，最终伤害美国企业和消费者的利益。不合理的限制也会侵犯华为的权利，引发其他严重的法律问题。2.青桔单车才上线就被约谈？北京交通部门责令回收违规投放单车36氪讯，北京市交通部门今日对滴滴进行约谈，指出其在未按照要求报备的情况下强行投放车辆，违反了《北京市非机动车管理条例》相关规定，严重扰乱了北京市互联网租赁自行车运营秩序。责令滴滴出行于5月16日下午进行车辆回收，5月17日12时前完成全部违规投放车辆的回收工作。同时，依法开展执法调查，并按程序对滴滴出行违规投放青桔单车一事实施处罚。网友评论：：青桔：我在北京的最后24小时。3.海马汽车亏16亿卖400套房 5月15日晚间，*ST海马公告称，为优化和盘活存量资产，公司拟通过招标和/或委托中介机构按照市场价格在二手房交易市场挂出等方式公开出售位于海口市金盘工业开发区创业新村一区、二区及金盘工业区金盘大道旁的部分闲置房产。其中，住宅269套（总面积14,685.04平方米），商铺15套(总面积2,729.12平方米)。账面价值原值为30,899,943元，最终处置价格以成交价为准。网友评论：企业只有炒房才是主业吧。4.百度第一季度净亏损4900万美元，同比转亏百度周四发布了该公司截至2019年3月31日的第一季度财报。财报显示，百度第一季度总营收为人民币241.23亿元（约合35.94亿美元），同比增长15%，市场预期242.7亿元；剔除分拆业务对收入的影响，同比增长21%。归属百度的净亏损为人民币3.27亿元（约合4900万美元），较去年同期的净利润人民币66.94亿元转亏。百度公司同时宣布，董事会已经批准推出新的股票回购计划，公司将在2020年7月1日之前回购不超过10亿美元的百度股票。网友评论：BAT里的B变了...5.向海龙回应离开百度：系正常离职，未来将要创业与投资百度公司董事长兼CEO李彦宏在内部财报信中宣布，搜索公司战略转型为移动生态事业群组，沈抖晋升为高级副总裁，全面负责移动生态事业群组。向海龙即日起辞去百度高级副总裁、搜索公司总裁职务。向海龙向21世纪经济报道记者独家透露，自己离开百度“就是正常离职”。至于为何之前毫无迹象、还在联盟峰会上公开演讲，向海龙表示“怎么也要开好大会后再离开，否则多不好”。同时他表示，接下来自己可能会开始创业，以及开始涉足投资。网友评论:没有一点点防备。6.天猫：投入千亿购物补贴，连续18天制造“千万爆款团”36氪讯，天猫宣布将投入千亿购物补贴连续18天制造“千万爆款团”；聚划算为品牌增加3亿新客；淘宝直播引导成交130亿；天天特卖为产业带增加3亿订单。阿里巴巴营销平台事业部总经理家洛表示，为了打造品牌商家最大增长机会，今年天猫618的投入规模向双11看齐。网友评论：赚钱这么不容易，为什么别人赚我的钱这么容易！7.摩拜创始人胡玮炜、CEO刘禹成立上海考瑞科技发展有限公司36氪讯，天眼查数据显示，上海考瑞科技发展有限公司于2019年5月9日成立，法定代表人为原摩拜CEO刘禹，摩拜创始人胡玮炜任监事。这是刘禹、胡玮炜离开摩拜之后，首次出现在同一家公司。该公司注册资本为1000万美元，经营范围包括：计算机软件科技领域内的技术开发、技术咨询、技术服务、自有技术转让，计算机软件开发，工业产品设计，计算机系统集成等。网友评论：又要搞大事情？8.腾讯优图发布“优图AI手语翻译机”36氪讯，腾讯优图实验室今日宣布攻克AI手语识别技术，并联合深圳市信息无障碍研究会，正式发布“优图AI手语翻译机”。据介绍，使用优图AI手语翻译机，听障人士只要面对摄像头做手语，经过后台计算机高速运算，翻译机屏幕就能快速把手语转换成文字。未来，优图AI手语翻译机有望在机场、高铁、民政窗口等公共场所部署应用，助力信息无障碍城市建设网友评论：技术的进步就是要让所有人都受惠。9.微软开源其Bing搜索服务背后关键算法5月16日消息，微软宣布开源Bing搜索服务背后关键算法。通过开源这项技术，该公司希望开发人员能够为其他搜索大量数据库（包括零售业）的用户构建类似的体验，能够快速将搜索结果返回给用户。 微软今日开源的软件是微软开发的一个库，其能更好地利用它收集的数据和为Bing构建AI模型。网友评论：好久没有用过Bing了10.我国学者研发出可数秒止血的神奇胶水 浙江大学和华东理工大学的联合团队研发出一种新型生物胶水材料，可在数秒内完全止住大动脉损伤和心脏穿透伤的大出血。相关成果于北京时间15日发表于《自然·通讯》杂志。研究团队提供的一段视频中显示，一只小猪的心脏受到了6毫米直径铁管穿透创口损伤，研究人员在猪心脏创口上挤上生物胶水，再用一束紫外光进行照射，短短几秒钟之内，喷涌的鲜血就被止住。网友评论：希望刺激战场可以引进。【更多内容，欢迎访问】http://forum.huaweicloud.com/forum.php?mod=forumdisplay&fid=569&filter=typeid&typeid=266（内容来源于互联网，如侵犯您的合法权益或有其他任何疑问，请联系：huaweicloud.bbs@huawei.com沟通处理。谢谢！）

 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社区项目的设计和开发，将带给您最原汁原味云原生讲解。