2021年3月22日，业界应用最为广泛的企业级Kubernetes管理平台Rancher发布了2020年Kubernetes行业调研报告，研究结果表明，2020年，更多的受访者在混合云环境中使用Kubernetes 运行容器，与此同时，更多的企业将功能和服务部署至边缘，最终进一步推动企业IT现代化的进程。2019年和2020年，Rancher分别对近1,000名专业人员展开了调查。调查结果表明，Kubernetes在不同行业连续两年保持了90%以上的采用率，而生产环境中的容器采用率从2019年的85%增长至2020年的87%。“从调研结果可以清晰地看到，用户持续推动容器在混合云和多云环境落地，92%的受访者将容器作为DevOps、IT运维、IT架构、应用程序开发和基础架构转型的关键部分。”Kubernetes和云：真实环境下的真实工具近1,000名在技术、工程、电信、银行、网络安全和咨询等行业工作的专业人员的反馈，他们主要专注于实现DevOps、IT运维、IT架构、应用程序开发和基础架构转型，92%的受访者选择使用容器来实现这些目标。另一方面，这些受访者均更倾向于采用Rancher所推出的Kubernetes发行版。36%的受访者将RKE作为其Kubernetes发行版，而32%的受访者使用K3s。受访者指出，在容器快速发展的大前提下，多层级控制和功能是RKE被广泛采用的关键原因。推动传统IT架构现代化受访者表示，容器化是推动传统IT现代化的关键路径。49%的受访者通过容器实现传统IT应用程序的现代化，而67%的受访者利用容器设计基于微服务的应用程序。通过使用Kubernetes，企业可以将使用了数十年的传统IT系统转化为基于微服务的容器应用程序，并通过Kubernetes进行编排。迁移到Kubernetes还可以使开发团队并行工作，从而减少了重复的可能性，简化开发并加速部署。在混合云环境中，开发团队还可以通过云托管集群完全替代某些本地工作负载，这些集群可以在像Rancher一样的Kubernetes管理平台上运行和管理，进一步实现IT架构现代化的战略。推动边缘环境生产落地容器在生产环境中的采用率逐步增长，也覆盖到了应用端。基于此，许多受访者使用容器来为客户提供各种服务，包括应用程序、边缘计算、混合/多云应用程序、内部应用程序、传统应用程序现代化和将传统应用程序迁移上云等。K3s等体积较小的Kubernetes已经使企业可以更容易地将功能和服务部署至边缘，它赋予了组织从试点项目转向生产环境的能力，并使其能够根据需要进行扩展。2020年，62％的受访者在边缘使用K3s，去年这一比例仅为50%。随着混合云网络的成熟，客户可以部署面向客户的云原生微服务应用程序，所需的维护量更少，迭代次数更多，并且可以随时间轻松添加新功能。我们完全有理由相信，在面向客户的环境中几乎完全采用由Kubernetes管理的容器的这一趋势将持续发展。结论随着公司将他们的网络、应用程序和流程发展成为一个更现代的框架，他们发现无论环境如何，Kubernetes 都可以随之改变。世界各地的组织正在利用 Kubernetes 解决方案来创建一个云原生微服务集群。他们还对单体系统进行现代化，建立强大的云架构，同时无缝管理现有集群。这是向加速和保护应用程序的时代迈进的一步，同时赋予了DevOps和工程团队利用未来“更聪明地工作”而不是“更努力地工作”的能力。“容器及Kubernetes是混合云时代软件定义基础架构的最佳选择，它们不仅能帮助企业实现传统IT基础架构的容器化改造，还能帮助企业释放混合云的全部价值。”通过结合容器及Kubernetes的可靠性和灵活性推动企业在任意场景进行无限创新，从而推动创新无处不在。”文章转载自：https://tech.china.com/article/20210325/032021_738288.html

kubelet 是 Kubernetes 中主要节点组件，执行许多关键任务，特别是：用 kube-apiserver 注册节点。监视 kube-apiserver 中已经调度的 Pod，通知容器运行时在调度新 Pod 之后重新启动容器。监视运行中的容器并将其状态报告给 kube-apiserver。执行 liveness 探针并在容器运行失败后重新启动容器。运行由 kubelet 直接管理的静态 Pod。与 Core Metrics Pipeline 和容器运行时进行交互以收集容器和节点度量。本文中要讨论的是 kubelet 另一个重要功能：当节点资源耗尽时，“主节点代理”驱逐 Pod 的能力。当磁盘、RAM 或 CPU 等计算资源不足时，kubelet 可以极大维护节点稳定性。对于 Kubernetes 管理员而言，了解配置资源外的处理很必要，可以保持节点资源灵活性以及系统的整体容错性和关键系统进程的稳定性。kubelet 如何确定资源不足？kubelet 可以从节点上驱逐工作负载，以释放资源来处理其他 Pod 或系统任务，例如容器运行时或 kubelet 本身，但 kubelet 是如何确定资源不足的？其实 kubelet 是通过 eviction signal（驱逐信号）和 eviction threshold（驱逐阈值）确定何时回收资源。驱逐信号是系统资源（如内存或存储）的当前容量。驱逐阈值则是 kubelet 维护的资源最小值。换句话说，每个驱逐信号都与某个驱逐阈值相关联，该驱逐阈值会告诉 kubelet 何时开始回收资源。目前，kubelet 支持以下驱逐信号：memory.available：描述集群内存状态的信号。内存的默认驱逐阈值为 100Mi。换句话说，当内存下降到 100Mi 时，kubelet 就会开始驱逐 Pod。nodefs.available：nodefs 是 kubelet 用于卷、守护进程日志等的文件系统。默认情况下，如果 nodefs.available<10％，kubelet 将开始回收节点资源。nodefs.inodesFree：描述 nodefs 索引节点内存状态的信号。默认情况下，如果 nodefs.inodesFree<5％，kubelet 将开始驱逐工作负载。imagefs.available—imagefs：文件系统是容器运行时使用的可选文件系统，用于存储容器镜像和容器可写层。默认情况下，如果 imagefs.available<15％，kubelet 将开始逐出工作负载。imagefs.inodesFree：索引 imagefs 节点内存的状态。它没有默认驱逐阈值。上述驱逐阈值都是合理的默认值。用户可以通过在 kubelet binary 上设置适当的 flag 来配置其自定义驱逐阈值。这些用户定义的阈值可以更改默认的 kubelet 驱逐行为。目前，Kubernetes 支持硬驱和软驱逐阈值。如果达到硬驱逐阈值，kubelet 将立即开始回收资源，而没有任何宽限期。软驱逐阈值则会包含用户定义的宽限期。在超过宽限期前，kubelet 不会回收与驱逐信号关联的资源。我们可以使用 kubelet binary 上的 --eviction-hardkubelet flag 定义硬驱逐阈值。例如，kubelet —-eviction-hard=memory.available<1Gi 当节点的 memory.available 大小低于 1Gi 时，kubelet 将开始回收资源。如果要在驱逐之前允许宽限期，可以将 —-eviction-soft 与 —-eviction-soft-grace-period 结合使用。例如，kubelet —-eviction-soft=memory.available<2Gi 以及 kubelet —-eviction-soft-grace-period=1m30s 能将 90 秒的驱逐阈值保持在触发驱逐前。用户还可以通过设置 —-eviction-max-pod-grace-period 秒数来指定允许的最大宽限期。kubelet 如何回收资源？kubelet 会通过终端用户的 Pod 来回收资源，但它首先会尝试回收未使用的容器镜像或已经终止的 Pod 这类资源。如果节点具有特定 imagefs 文件系统和 nodefs 文件系统，kubelet 会以不同的方式回收节点资源。当 nodefs 达到驱逐阈值时，kubelet 会删除所有已经终止的 Pod 及其容器。相应地，如果 imagefs 达到驱逐阈值，kubelet 会删除所有未使用的容器镜像。如果没使用 imagefs，kubelet 将首先删除所有已经终止的 Pod 及其容器，然后删除所有未使用的镜像。有关这一过程的详细信息，请参阅 Kubernetes 文档。文档信息：https://kubernetes.io/docs/tasks/administer-cluster/out-of-resource/如果回收容器镜像、已经终止的 Pod 和其他资源没有解决资源匮乏问题，kubelet 最后会开始删除终端用户的 Pod。kubelet 根据 Pod 的 QoS 类、Pod 优先级和许多其他参数来决定回收哪个终端用户的 Pod。这里先介绍一下 Kubernetes 中的基本 QoS 类。Guaranteed pod 是在所有容器中为 CPU 和 RAM 设置资源限制（limit）和请求（request）的 Pod，限制和请求必须一致。Burstable Pod 是为一个或多个容器中为资源（例如CPU、RAM）设置请求和限制的容器，限制和请求不用明确指定。Best-Effort Pod 是未设置资源请求和限制的 Pod。该 QoS 由 kubelet 在其 Pod 排序方案中隐式使用。通常，kubelet 使用以下规则对驱逐进行排序：Pod 是否已超出其资源请求。在 Kubernetes 中，Pod 是根据其请求（request）而不是限制（limit）进行调度的。因此，要保证所有容器和 Pod 都具有它们所请求的 RAM、CPU 数量。但是，如果未设置限制，并且 Pod 超出了其资源请求，那么在保证 Pod 或某些系统任务需要受限资源的情况下，可以终止或限制该 Pod。在某些情况下，某些消耗少于要求量的 Pod 也会被杀死。例如，当系统任务内存严重不足并且没有较低优先级的 Pod 被回收时。按 Pod 优先级。如果没有 Pod 超出其请求，kubelet 会检查 Pod Priority。它将尝试先驱逐优先级较低的 Pod。相对于 Pod 的资源请求消耗量计算资源（例如 RAM）。根据这些规则，kubelet 会按以下顺序逐出终端用户的 Pod：首先驱逐是受限资源的使用超出了请求的 Best-Effort 和 Burstable Pod。如果有多个这样的 Pod，kubelet 会按优先级对它们进行排序。最后是资源低于请求的 Guaranteed 和 Burstable Pod。如果某些系统任务（如 kubelet 或 Docker）需要资源，并且节点上 Best-Effort Pod，kubelet 可以驱逐消耗量低于请求的 Guaranteed Pod。在这种情况下，它会以最低优先级驱逐 Guaranteed 和 Burstable Pod。最低驱逐回收如果 kubelet 回收的资源量很小，系统可能反复达到驱逐阈值，这可能导致会不良的调度决策和 Pod 频繁驱逐。为了避免这种情况，用户可以使用 kubelet binary —-eviction-minimum-reclaimkubelet 的 flag 来设置每个资源的最小回收级别。例如:—-eviction-minimum-reclaim 设置确保 nodefs 回收后的最小可用存储量为 3Gi，imagefs 最小可用存储量为 202 Gi。因此，以上配置可确保系统具有足够的可用资源，以避免频繁达到驱逐阈值。资源不足以处理配置还会遇到另一个问题：节点状态（condition）的波动。当 kubelet 收到驱逐信号后，后者会映射到相应的节点状态。例如，memory.available 达到驱逐阈值时，kubelet 会将 MemoryPressure 节点状态分配给该节点。此状态与相应的污点（taint） 关联，该污点可防止在具有 MemoryPressure 节点状态的节点上调度新 Pod。但如果使用了具有较长宽限期的软驱逐阈值，节点条件会在宽限期 true 和 false 之间振荡。这可能导致调度计划的不确定性。为了避免这种情况，我们可以在 kubelet 上使用 —-eviction-pressure-transition-period，以定义 kubelet 在满足驱逐条件之前必须等待多长时间。简单 Out-of-Resource 处理方案以下将说明如何处理 K8s 集群配置资源不足。想象一个简单的场景，仅考虑节点 RAM。假设节点的内存容量为 10Gi RAM。我们希望为系统守护进程（例如内核、kubelet、Docker 等）保留 10% 的总内存并以 95％ 的内存利用率驱逐 Pod。使用默认驱逐阈值启动 kubelet，并且没有 system-reserved 设置。我们需要在 kubelet 上显式设置几个 flag：虽然直观上应该将 system-reserved 设置为 1.5Gi，但实际将其设置为 10％=1Gi。System reserved 应包括驱逐阈值（1Gi+0.5Gi）覆盖的内存量。根据配置 K8s 集群的方式，可以不同地设置 kubelet flag。例如，如果计划使用 Kops 设置 K8s 集群，请运行 kops edit cluster $NAME 以使用集群配置打开编辑器。如果是 VI 辑器，则按 “I” 进入插入模式以编辑文件。上述资源不足处理策略的 kubelet flag 应如下所示：结论本文我们讨论了一些有用的 Kubernetes 管理实践，用于 Kubernetes 中自定义 kubelet 资源不足管理。该平台允许管理员设置自定义驱逐阈值和驱逐宽限期，能决定哪些条件对节点稳定性有用。Kubernetes 附带了资源不足管理默认设置，在将驱逐阈值设置得太高或将驱逐宽限期设置得太长时，要保持谨慎。文章来源：K8sMeetup社区译者：Bach

跟大家分享下loki跟fluentd结合的一些实践。为什么是FluentdFluentd是一个由云原生基金会(CNCF)管理的统一日志层数据收集器。它可以从多种数据源里采集、处理日志，并集中将它们存储到文件或者数据库当中。其主要的目的也是让你的基础设施能够实现统一的数据收集和分发，以便业务可以更好的使用和理解数据。作为第六个从CNCF里面毕业的项目，fluentd拥有大量的数据处理插件和生产环境的实践指导，同时还有GKE和AWS这样公有云大厂应用为其背书，小白毅然的选择了fluentd作为我们kubernetes上唯一日志采集器。Loki插件Loki为fluetnd提供了一个输出插件fluent-plugin-grafana-loki，它可以将采集到的日志传送到Loki实例当中。当然，在实际的应用当中，还需需要我们自己去构建fluentd的docker镜像， 那么我们需要将下面几行加入到自己的dockerfile里面# 必要的loki输出插件和kubernetes元数据插件gem install fluent-plugin-grafana-lokigem install fluent-plugin-kubernetes_metadata_filter# 小白建议安装的prometheus，字段修改和tag修改插件gem install fluent-plugin-prometheusgem install fluent-plugin-record-modifiergem install fluent-plugin-rewrite-tag-filter采集流程按照Kubernetes上运行应用的日志一般建议Kubernetes 无状态应用的一般特征应用不应继续把日志输出到本地文件，而应该输出到 stdout 和 stderr；集群应该针对容器的 stdout、stderr 提供统一的日志采集，建议使用 Daemonset 而非 Sidecar；进行日志采集的同时，集群应提供 ES、Loki 或其它类似机制来对日志进行处理，并且其处理和存储能力应该有初步预案；应用日志应提供分级开关，保证同一镜像在不同环境中可以输出不同数量和级别的日志信息。小白将fluentd在k8s上的采集流程设计如下：Pre Input阶段默认情况下docker会将容器的stdout/stderr日志重定向到/var/lib/docker/containers，其日志也为json格式如下{    "log":"xxxxxxxxxxx",    "stream":"stdout",    "time":"2020-09-15T23:09:04.902156725Z"}对于将fluentd部署在node上的同学则需要将node的这个目录映射到容器内。# fluentd的workerload中关于映射容器标准输入的volume...volumeMounts:- mountPath: /var/lib/docker/containers  name: varlibdockercontainersvolumes:- hostPath:    path: /var/lib/docker/containers    name: varlibdockercontainers...Input阶段在采集阶段， 利用fluentd的in_tail插件对docker标准输出采集即可，参照如下：<worker 0>  <source>    @type tail    @id input.containers.out    path /var/log/containers/*.log    exclude_path ["/var/log/containers/*fluentd*.log"]    pos_file /var/log/fluentd/container.out.pos    limit_recently_modified 86400    read_from_head true    tag kubernetes.*    <parse>      @type json      time_key time      time_format %Y-%m-%dT%H:%M:%S.%NZ      utc true    </parse>  </source></worker>Fluentd可以通过定义<worker>标签来支持多进程并发采集，如果你的node上是容器密度和小白一样大，我们就创建两个worker来同时采集docker日志，参照如下：<worker 0>  <source>    @type tail    @id input.containers.out.0    path /var/log/containers/*[0-7].log    exclude_path ["/var/log/containers/*fluentd*.log"]    pos_file /var/log/fluentd/container.out.pos.0    limit_recently_modified 86400    read_from_head true    tag kubernetes.*    <parse>      @type json      time_key time      time_format %Y-%m-%dT%H:%M:%S.%NZ      utc true    </parse>  </source></worker><worker 1>  <source>    @type tail    @id input.containers.out.1    path /var/log/containers/*[8-f].log    exclude_path ["/var/log/containers/*fluentd*.log"]    pos_file /var/log/fluentd/container.out.pos.1    limit_recently_modified 86400    read_from_head true    tag kubernetes.*    <parse>      @type json      time_key time      time_format %Y-%m-%dT%H:%M:%S.%NZ      utc true    </parse>  </source></worker>提醒，默认情况下docker没有对容器标准输出的日志存储空间做限制。但实际情况下，我们为了避免生产环境容器日志占满服务器磁盘，会通过修改docker daemon的启动参数--log-opt=10G来限制容器的最大输出日志空间。这里对于fluentd来说，如果在采集停滞时间内容器的日志桶被完全轮转，那么就会出现日志丢失的风险。对于该如何调整参数，小白建议按照大家自己公司情况合理规划即可。Filter阶段Filter阶段主要用来处理日志采集之后的kubernetes元数据标注以及修改、提取自定义字段,这里面主要用了两个插件fluent-plugin-kubernetes_metadata_filter和fluent-plugin-record-modifier来处理以上逻辑。kubernetes_metadata主要作用为提取tag中的关键信息来向kubernetes查询Pod和Namespace上的Label，并将其添加到日志的json结构体内，它的配置可参照如下：<filter kubernetes.var.log.containers.**>  @type kubernetes_metadata  @id kubernetes_metadata_container_out  skip_container_metadata true  skip_master_url true  cache_size 3000  cache_ttl 1800</filter>metadata插件有Cache的机制，大家根据自己集群的规模合理调整cache的容量和cache的过期时间。正常情况下，metadata插件会watch k8s api来更新cache，如果出现新部署的容器日志没有相关标签，那么你可能需要再等一会或者重启fluentd客户端可以解决record_modifier主要用于提取和修改kubernetes元数据标签，修改成我们自定义的字段，这些字段可以为后面存储在Loki的里面的Label提前建立好索引规则。这部分可参考小白下面的配置：<match kubernetes.var.log.containers.**>  @type record_modifier  @id label.container.out  tag ${record.dig('k8s_std_collect') ? 'loki.kubernetes.var.log.containers' : 'dropped.var.log.containers'}  <record>    k8s_container_id ${record.dig("docker", "container_id")}    k8s_cloud_cluster "#{ENV['CLOUD_CLUSTER'] || 'default'}"    k8s_node ${record.dig('kubernetes', 'host')}    k8s_container_name ${record.dig('kubernetes', 'container_name')}    k8s_app_name ${record.dig('kubernetes', 'labels', 'app_kubernetes_io/name')}    k8s_svc_name ${record.dig('kubernetes', 'labels', 'app')}    k8s_pod_name ${record.dig('kubernetes', 'pod_name')}    k8s_namespace_name ${record.dig('kubernetes', 'namespace_name')}    k8s_image_version ${record.dig('kubernetes', 'labels', 'app_image_version')}    k8s_std_collect ${record.dig("kubernetes", "labels", "log-collect") or false}    formated_time "${Time.at(time).to_datetime.iso8601(9)}"    fluentd_worker "#{worker_id}"  </record>  remove_keys docker,kubernetes   //删除原生metadata字段</match>大部分情况下，我们对运行在kubernetes里面的workerload都有自己特定的labels规范，并且这部分内容通常被CD系统集成在发布模板当中。这里大家可以按照自己公司情况构建日志索引结构，当然你可以参考小白定的label规范:...metadata:   labels:    app: <componet_name>   //组件名    app.kubernetes.io/name: <app_name>   //应用名    app.kubernetes.io/version: <app_release>  //应用版本spec:  template:    metadata:      labels:        app: <componet_name>        app.image.version: <componet_image_tag>        app.kubernetes.io/name: <app_name>        log-collect: "true"   //日志采集开关...注意：log-collect可以灵活控制容器是否需要做日志采集，如果不需要控制，可以忽略此标签，同时还需修改record_modifier中的tag处理逻辑如下tag loki.kubernetes.var.log.containersOutput阶段在此阶段，基本上由fluentd采集的日志已经完成了索引构建，我们只需匹配相关的tag将其转发指定的上游数据服务即可，这里我们当然用fluent-plugin-grafana-loki插件将日志抓发给Loki存储。loki插件提供了比较丰富label和buffer参数调试，这里关于Loki的label小白可以直接采用按照前面自定义规则里面的标签即可，参照如下：<match loki.**>  @type loki  @id loki.output  url "http://loki:3100"  remove_keys topic,k8s_std_collect,formated_time,k8s_container_id  drop_single_key true  <label>    stream    k8s_cloud_cluster    k8s_container_name    k8s_node    k8s_app_name    k8s_svc_name    k8s_pod_name    k8s_image_version    k8s_namespace_name </label>  <buffer label>    @type file    path /var/log/fluentd-buffers/loki.buffer    flush_mode interval    flush_thread_count 4    flush_interval 3s    retry_type exponential_backoff    retry_wait 2s    retry_max_interval 60s    retry_timeout 12h    chunk_limit_size 8M    total_limit_size 5G    queued_chunks_limit_size 64    overflow_action drop_oldest_chunk  </buffer></match>关于Buffer的配置，大部分情况下我们可以不用关心，不过你还记得前面小白说的关于docker日志桶的参数配置不当引起丢失日志的风险吗？这里的buffer配置可以根据情况缓解这类问题走到这里我们基本完成了在k8s上较为云原生方式的日志采集架构。另外值得一提的是，Loki本身支持对多租户日志分级存储，如若你的kubernetes平台是基于多租户管理的，那么你可以将租户信息提取出来引入到loki当中。

作为一个功能丰富、组件众多的“云原生操作系统”，安装和配置Kubernetes 的复杂性的确容易让人望而却步。不过，Kubernetes 社区经过几年的快速发展，已经出现了不少颇为易用的安装、部署工具，能够帮助初学者和新用户用最简单的步骤上手 K8s。接下来跟我一起尝试用下面几个非常易用的工具，开始自己的 Kubernetes 学习之旅吧~01MicroK8sMicroK8s 是由Ubuntu推出的基于snap的包。在最新的 Ubuntu 系统下（20.04以上），可以直接使用 snap 命令快速安装一个本地 Kubernetes 集群。在 shell 中执行如下命令：$ sudo snap install --classic microk8s（如果系统没有 snap 命令，可以通过 apt-get install snap 来安装）MicroK8s安装完成以后，通过 sudo microk8s kubectl 命令来访问集群：$ sudo microk8s kubectl get node  NAME               STATUS     ROLES    AGE   VERSIONip-172-44-255-31   NotReady   <none>   65s   v1.20.2-34+350770ed07a558MicroK8s 还集成了很多插件，比如 storage插件也可以通过 microk8s 命令来管理。例如：$ sudo microk8s enable storage ingress如果想把多个节点加入同一个 Kubernetes 集群，可以使用sudo microk8s add-node 命令，然后根据提示进行操作。                                                  02K3SK3S 是 Rancher 推出的一个高集成度的 Kubernetes 发行版，所有的组件都被打包在一个可执行文件中，并且进行了轻量化。K3S程序可以在这里下载：https://github.com/rancher/k3s/releases/latest把 K3S 文件下载到 /usr/local/bin 并且设为可执行以后，就可以用一个命令启动集群服务：$ sudo k3s server访问集群同样是通过 K3S 命令：$ sudo k3s kubectl get node如果要把多个主机加入一个集群，可以在另外的节点上执行：$ sudo k3s agent –server https://$SERVER:6443 –token $TOKEN其中$SERVER和$TOKEN要匹配第一台主机的地址和 /var/lib/rancher/k3s/server/node-token 文件内的令牌。                                                  03RKERKE的全称是 Rancher Kubernetes Engine，也是由 Rancher开发和维护的Kubernetes发行版。跟偏重边缘计算场景的 K3S 相比，RKE 更多面向传统的数据中心生产环境，偏重集群化部署，且可定制性更强。要安装一个 RKE 的集群，可以从这里下载 RKE 程序：https://github.com/rancher/rke/releases然后使用 rke config --name cluster.yml 创建一个新的集群部署配置。编辑 cluster.yml 文件，填充集群的主机列表和访问方式等，同时还可以定制集群的初始化配置。配置文件的一个片段如下：12345678910111213nodes:- address: 11.37.129.93  port: "22"  internal_address: 10.1.4.245  role:  - controlplane  - worker  - etcd- address: 4.103.57.64  port: "22"  internal_address: 10.1.1.101  role:  - worker然后执行 rke up 命令，就会开始安装。注意部署 RKE 的节点需要预先安装Docker。完成以后，当前目录下出现 kube_config_cluster.yml 文件，即可通过 kubectl命令来访问集群：$ kubectl –kubeconfig kube_config_cluster.yml get node                                                  04KINDKind 是 Kubernetes-in-Docker 的缩写。在安装有 Docker 的主机上创建一个测试用的多节点Kubernetes集群非常容易，而且由于整个集群都在 Docker 的容器环境中运行，不会对主机环境和其它配置造成过多干扰。kind 命令可以从这里下载：https://kind.sigs.k8s.io/保存到 /usr/local/bin 以后，直接执行 kind create cluster 就可以创建一个集群：如果你想尝试多节点的集群，也可以：$ cat > kind.config <<EOF kind: Cluster apiVersion: kind.x-k8s.io/v1alpha4 # One control plane node and three "workers". nodes:   - role: control   -plane- role: worker   - role: worker   - role: worker  EOF  $ kind create cluster --config kind.config命令完成后，系统中会出现几个新的 Docker 容器。并且 $HOME/.kube/config 文件会自动更新，因而直接运行 kubectl get node 就可以访问 kind 集群了。

背景虽然云原生时代有了 JenkinsX、Drone、Tekton 这样的后起之秀，但 Jenkins 这样一个老牌的 CI/CD 工具仍是各大公司主流的使用方案。比如我司的私有云产品打包发布就是用这老家伙完成的。然而传统的 Jenkins Slave 一主多从方式会存在一些痛点，比如：每个 Slave 的配置环境不一样，来完成不同语言的编译打包等操作，但是这些差异化的配置导致管理起来非常不方便，维护起来也是比较费劲资源分配不均衡，有的 Slave 要运行的 job 出现排队等待，而有的 Slave 处于空闲状态资源有浪费，每台 Slave 可能是物理机或者虚拟机，当 Slave 处于空闲状态时，也不会完全释放掉资源。正因为上面的 Jenkins slave 存在这些种种痛点，我们渴望一种更高效更可靠的方式来完成这个 CI/CD 流程，而 Docker 虚拟化容器技术能很好的解决这个痛点，又特别是在 Kubernetes 集群环境下面能够更好来解决上面的问题：Jenkins Master 时以 docker-compose 的方式运行在一个节点上。Jenkins Slave 以 Pod 形式运行在 Kubernetes 集群的 Node 上，并且它不是一直处于运行状态，它会按照需求动态的创建并自动删除。这种方式的工作流程大致为：当 Jenkins Master 接受到 Build 请求时，会根据配置的 Label 动态创建一个运行在 Pod 中的 Jenkins Slave 并注册到 Master 上，当运行完 Job 后，这个 Slave 会被注销并且这个 Pod 也会自动删除，恢复到最初状态。那么我们使用这种方式带来了以下好处：动态伸缩，合理使用资源，每次运行 Job 时，会自动创建一个 Jenkins Slave，Job 完成后，Slave 自动注销并删除容器，资源自动释放，而且 Kubernetes 会根据每个资源的使用情况，动态分配 Slave 到空闲的节点上创建，降低出现因某节点资源利用率高，还排队等待在该节点的情况。扩展性好，当 Kubernetes 集群的资源严重不足而导致 Job 排队等待时，可以很容易的添加一个 Kubernetes Node 到集群中，从而实现扩展。上面的大半段复制粘贴自 基于 Jenkins 的 CI/CD (一)kubernetes 集群关于 kubernetes 集群部署，使用 kubeadm 部署是最为方便的了，可参考我很早之前写过的文章《使用 kubeadm 快速部署体验 K8s》，在这里只是简单介绍一下：使用 kubeadm 来创建一个单 master 节点的 kubernets 集群root@jenkins:~ # kubeadm init --pod-network-cidr=10.244.0.0/16 --apiserver-advertise-address=192.168.20.11集群成功部署完成之后会有如下提示：Your Kubernetes control-plane has initialized successfully!To start using your cluster, you need to run the following as a regular user:  mkdir -p $HOME/.kube  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config  sudo chown $(id -u):$(id -g) $HOME/.kube/config查看节点状态和 pod 都已经正常root@jenkins:~ # kubectl get pod -ANAMESPACE     NAME                              READY   STATUS    RESTARTS   AGEkube-system   coredns-f9fd979d6-9t6qp           1/1     Running   0          89skube-system   coredns-f9fd979d6-hntm8           1/1     Running   0          89skube-system   etcd-jenkins                      1/1     Running   0          106skube-system   kube-apiserver-jenkins            1/1     Running   0          106skube-system   kube-controller-manager-jenkins   1/1     Running   0          106skube-system   kube-proxy-8pzkz                  1/1     Running   0          89skube-system   kube-scheduler-jenkins            1/1     Running   0          106sroot@jenkins:~ # kubectl get nodeNAME      STATUS   ROLES    AGE    VERSIONjenkins   Ready    master   119s   v1.19.8去除 master 节点上的污点，允许其他的 pod 调度在 master 节点上，不然后面 Jenkins 所创建的 pod 将无法调度在该节点上。kubectl taint nodes $(hostname) node-role.kubernetes.io/master:NoSchedule-Jenkins master至于 Jenkins master 的部署方式，个人建议使用 docker-compose 来部署。运行在 kubernetes 集群集群中也没什么毛病。但从个人运维踩的坑来讲，还是将 Jenkins master 独立于 kubernetes 集群部署比较方便 。docker-compose.yamlversion: '3.6'services:  jenkins:    image: jenkins/jenkins:2.263.4-lts-slim    container_name: jenkins    restart: always    volumes:      - ./jenkins_home:/var/jenkins_home    network_mode: host    user: root    environment:      - JAVA_OPTS=-Duser.timezone=Asia/Shanghai使用 docker-compose up 来启动，成功启动后会有如下提示，日志输出的密钥就是 admin 用户的默认密码，使用它来第一次登录 Jenkins。jenkins    | 2021-03-06 02:22:31.741+0000 [id=41] INFO jenkins.install.SetupWizard#init:jenkins    |jenkins    | *************************************************************jenkins    | *************************************************************jenkins    | *************************************************************jenkins    |jenkins    | Jenkins initial setup is required. An admin user has been created and a password generated.jenkins    | Please use the following password to proceed to installation:jenkins    |jenkins    | 4c2361968cd94323acdde17f7603d8e1jenkins    |jenkins    | This may also be found at: /var/jenkins_home/secrets/initialAdminPasswordjenkins    |jenkins    | *************************************************************jenkins    | *************************************************************jenkins    | *************************************************************登录上去之后，建议选择 选择插件来安装，尽可能少地安装插件，按需安装即可。在 Jenkins 的插件管理那里安装上 kubernetes 插件接下来开始配置 Jenkins 大叔如何与 kubernetes 船长手牵手 ‍‍ :-)。配置 kubernets 的地方是在 系统管理 > 节点管理 > Configure Clouds。点击 Add a new cloud，来添加一个 kubernetes 集群。配置连接参数参数值说明名称kubernetes也是后面 pod 模板中的 cloud 的值凭据kubeconfig 凭据 id使用 kubeconfig 文件来连接集群Kubernetes 地址默认即可Use Jenkins Proxy默认即可Kubernetes 服务证书 key默认即可禁用 HTTPS 证书检查默认即可Kubernetes 命名空间默认即可WebSocket默认即可Direct Connection默认即可Jenkins 地址http://jenkins.k8s.li:8080Jenkins pod 连接 Jenkins master 的 URLJenkins 通道50000Jenkins JNLP 的端口，默认为 50000Connection Timeout默认即可Jenkins 连接 kubernetes 超时时间Read Timeout默认即可容器数量默认即可Jenkins pod 创建的最大数量Pod Labels默认即可Jenkins pod 的 lables连接 Kubernetes API 的最大连接数默认即可Seconds to wait for pod to be running默认即可等待 pod 正常 running 的时间在 Jenkins 的凭据那里添加上 kubeconfig 文件，凭据的类型选择为 Secret file，然后将上面使用 kubeadm 部署生成的 kubeconfig 上传到这里。点击连接测试，如果提示 Connected to Kubernetes v1.19.8 就说明已经成功连接上了 kubernetes 集群。关于 pod 模板其实就是配置 Jenkins Slave 运行的 Pod 模板，个人不太建议使用插件中的模板去配置，推荐将 pod 的模板放在 Jenkinsfile 中，因为这些配置与我们的流水线紧密相关，把 pod 的配置存储在 Jenkins 的插件里实在是不太方便；不方便后续的迁移备份之类的工作；后续插件升级后这些配置也可能会丢失。因此建议将 pod 模板的配置直接定义在 Jenkinsfile 中，灵活性更高一些，不会受 Jenkins 插件升级的影响。总之用代码去管理这些 pod 配置维护成本将会少很多。Jenkinsfile流水线 Jenkinsfile，下面是一个简单的任务，用于构建 webp-server-go项目的 docker 镜像。// Kubernetes pod template to run.def JOB_NAME = "${env.JOB_NAME}"def BUILD_NUMBER = "${env.BUILD_NUMBER}"def POD_NAME = "jenkins-${JOB_NAME}-${BUILD_NUMBER}"podTemplate(# 这里定义 pod 模版){ node(POD_NAME) {    container(JOB_NAME) {      stage("Build image") {        sh """#!/bin/bash          git clone https://github.com/webp-sh/webp_server_go /build          cd /build          docker build -t webps:0.3.2-rc.1 .        """      }    }  }}pod 模版如下，将模板的内容复制粘贴到上面的 Jenkinsfile 中。在容器中构建镜像，我们使用 dind 的方案：将 pod 所在宿主机的 docker sock 文件挂载到 pod 的容器内，pod 容器内只要安装好 docker-cli 工具就可以像宿主机那样直接使用 docker 了。podTemplate(  cloud: "kubernetes",  namespace: "default",  name: POD_NAME,  label: POD_NAME,  yaml: """apiVersion: v1kind: Podspec:  containers:  - name: ${JOB_NAME}    image: "debian:buster-docker"    imagePullPolicy: IfNotPresent    tty: true    volumeMounts:    - name: dockersock      mountPath: /var/run/docker.sock  - name: jnlp    args: ["\$(JENKINS_SECRET)", "\$(JENKINS_NAME)"]    image: "jenkins/inbound-agent:4.3-4-alpine"    imagePullPolicy: IfNotPresent  volumes:  - name: dockersock    hostPath:      path: /var/run/docker.sock""",)构建 debian:buster-docker 镜像，使用它来在 pod 的容器内构建 docker 镜像，使用的 Dockerfile 如下：FROM debian:busterRUN apt update \    && apt install -y --no-install-recommends \        vim \        curl \        git \        make \        ca-certificates \        gnupg \    && rm -rf /var/lib/apt/lists/*RUN curl -fsSL "https://download.docker.com/linux/debian/gpg" | apt-key add -qq - >/dev/null \    && echo "deb [arch=amd64] https://download.docker.com/linux/debian buster stable" > /etc/apt/sources.list.d/docker.list \    && apt update -qq \    && apt-get install -y -qq --no-install-recommends docker-ce-cli \    && rm -rf /var/lib/apt/lists/*定义好 jenkinsfile 文件并且构建好 pod 模板中的镜像后，接下来我们开始使用它来创建流水线任务。流水线在 Jenkins 上新建一个任务，选择任务的类型为 流水线将定义好的 Jenkinsfile 内容复制粘贴到流水线定义 Pipeline script 中并点击保存。在新建好的 Job 页面点击 立即构建 来运行流水线任务。在 kubernetes 集群的机器上使用 kubectl 命令查看 pod 是否正常 Runningroot@jenkins:~ # kubectl get podNAME                              READY   STATUS    RESTARTS   AGEjenkins-webps-9-bs78x-5x204   2/2     Running   0          66sJob 正常运行并且状态为绿色表明该 job 已经成功执行了。在 kubernetes 集群机器上查看 docker 镜像是否构建成功root@jenkins:~ # docker images | grep webpswebps                                0.3.2-rc.1          f68f496c0444        20 minutes ago      13.7MB踩坑pod 无法正常 RunningRunning in Durability level: MAX_SURVIVABILITY[Pipeline] Start of Pipeline[Pipeline] podTemplate[Pipeline] {[Pipeline] nodeCreated Pod: kubernetes default/debian-35a11b49-087b-4a8c-abac-bd97d7eb5a1f-fkmzq-9wm0r[Normal][default/debian-35a11b49-087b-4a8c-abac-bd97d7eb5a1f-fkmzq-9wm0r][Scheduled] Successfully assigned default/debian-35a11b49-087b-4a8c-abac-bd97d7eb5a1f-fkmzq-9wm0r to jenkins[Normal][default/debian-35a11b49-087b-4a8c-abac-bd97d7eb5a1f-fkmzq-9wm0r][Pulling] Pulling image "debian:buster"[Normal][default/debian-35a11b49-087b-4a8c-abac-bd97d7eb5a1f-fkmzq-9wm0r][Pulled] Successfully pulled image "debian:buster" in 2.210576896s[Normal][default/debian-35a11b49-087b-4a8c-abac-bd97d7eb5a1f-fkmzq-9wm0r][Created] Created container debian[Normal][default/debian-35a11b49-087b-4a8c-abac-bd97d7eb5a1f-fkmzq-9wm0r][Started] Started container debian[Normal][default/debian-35a11b49-087b-4a8c-abac-bd97d7eb5a1f-fkmzq-9wm0r][Pulling] Pulling image "jenkins/inbound-agent:4.3-4-alpine"Still waiting to schedule task‘debian-35a11b49-087b-4a8c-abac-bd97d7eb5a1f-fkmzq-9wm0r’ is offline[Normal][default/debian-35a11b49-087b-4a8c-abac-bd97d7eb5a1f-fkmzq-9wm0r][Pulled] Successfully pulled image "jenkins/inbound-agent:4.3-4-alpine" in 3.168311973s[Normal][default/debian-35a11b49-087b-4a8c-abac-bd97d7eb5a1f-fkmzq-9wm0r][Created] Created container jnlp[Normal][default/debian-35a11b49-087b-4a8c-abac-bd97d7eb5a1f-fkmzq-9wm0r][Started] Started container jnlpCreated Pod: kubernetes default/debian-35a11b49-087b-4a8c-abac-bd97d7eb5a1f-fkmzq-qdw4m[Normal][default/debian-35a11b49-087b-4a8c-abac-bd97d7eb5a1f-fkmzq-qdw4m][Scheduled] Successfully assigned default/debian-35a11b49-087b-4a8c-abac-bd97d7eb5a1f-fkmzq-qdw4m to jenkins[Normal][default/debian-35a11b49-087b-4a8c-abac-bd97d7eb5a1f-fkmzq-qdw4m][Pulled] Container image "debian:buster" already present on machine[Normal][default/debian-35a11b49-087b-4a8c-abac-bd97d7eb5a1f-fkmzq-qdw4m][Created] Created container debian[Normal][default/debian-35a11b49-087b-4a8c-abac-bd97d7eb5a1f-fkmzq-qdw4m][Started] Started container debian[Normal][default/debian-35a11b49-087b-4a8c-abac-bd97d7eb5a1f-fkmzq-qdw4m][Pulled] Container image "jenkins/inbound-agent:4.3-4-alpine" already present on machine[Normal][default/debian-35a11b49-087b-4a8c-abac-bd97d7eb5a1f-fkmzq-qdw4m][Created] Created container jnlp[Normal][default/debian-35a11b49-087b-4a8c-abac-bd97d7eb5a1f-fkmzq-qdw4m][Started] Started container jnlp这是因为 Jenkins pod 中的 jnlp 容器无法连接 Jenkins master。可以检查一下 Jenkins master 上 系统管理 > 节点管理 > Configure Clouds 中 Jenkins 地址 和 Jenkins 通道 这两个参数是否配置正确。结束到此为止，我们就完成了让 Jenkins 大叔与 kubernetes 船长手牵手 ‍‍ 啦！上面使用了一个简单的例子来展示了如何将 Jenkins 的 Job 任务运行在 kubernetes 集群上，但在实际工作中遇到的情形可能比这要复杂一些，流水线需要配置的参数也要多一些。那么我将会在下一篇博客中再讲一下高级的用法：使用 Jenkins 完成 kubespray 离线安装包打包。

在Kubernetes中分配和管理CPU和内存资源可能很棘手，但也很容易。本文，我将向你展示什么是Kubernetes资源和限制以及如何管理它们。本文的目标是简单–如何帮助你快速调整项目中的Kubernetes资源信息，主要通过三种方式：1. 为容器和 Pod 分配CPU和内存资源2. Resources Quota: 限制namespace的资源消耗3. Limit Ranges：配置默认的CPU请求和限制为容器和 Pod 分配CPU和内存资源下图，解释了Kubernetes资源的度量单位，资源状态工作流以及如何使用资源限制。CPU和内存单位Kubernetes 中的一个 cpu 等于：1 AWS vCPU1 GCP Core1 Azure vCore1 Hyperthread 在带有超线程的裸机 Intel 处理器上以下，Deployment使用了内存资源和CPU资源的请求和限制将CPU和内存 请求 （request）和内存 限制 （limit）分配给一个容器更详细的信息和代码段：将内存资源分配给容器和Pod将CPU资源分配给容器和PodKubernetes最佳实践资源要求和限制应用程序开发人员在Azure Kubernetes Service（AKS）中管理资源的最佳实践Resources Quota: 限制namespace的资源消耗资源配额，通过 ResourceQuota 对象来定义，对每个namespace的资源消耗总量提供限制。它可以限制namespace中某种类型的对象的总数目上限，也可以限制命令空间中的 Pod 可以使用的计算资源的总上限。资源配额的工作方式如下：不同的团队可以在不同的namespace下工作，目前这是非约束性的，在未来的版本中可能会通过 ACL (Access Control List 访问控制列表) 来实现强制性约束。集群管理员可以为每个namespace创建一个或多个 ResourceQuota 对象。当用户在namespace下创建资源（如 Pod、Service 等）时，Kubernetes 的配额系统会 跟踪集群的资源使用情况，以确保使用的资源用量不超过 ResourceQuota 中定义的硬性资源限额。如果资源创建或者更新请求违反了配额约束，那么该请求会报错（HTTP 403 FORBIDDEN）， 并在消息中给出有可能违反的约束。如果namespace下的计算资源 （如 cpu 和 memory）的配额被启用，则用户必须为 这些资源设定请求值（request）和约束值（limit），否则配额系统将拒绝 Pod 的创建。 提示: 可使用 LimitRanger 准入控制器来为没有设置计算资源需求的 Pod 设置默认值。以下，是对持久卷声明和namespace资源的配额定义。你可以使用该kubectl apply命令来设置namespace的配额限制。kubectl apply -f resource-quota.yaml — namespace backend如何使用配额的详细说明，请参考https://kubernetes.io/docs/concepts/policy/resource-quotas/Limit Ranges：配置默认的CPU请求和限制如果你的namespace有资源配额，那么默认内存限制是很有帮助的。将 LimitRange 添加到namespace，不仅会限制cpu和内存，还会为存储请求大小强制设置最小值和最大值。存储是通过 PersistentVolumeClaim 来发起请求的。执行限制范围控制的准入控制器会拒绝任何高于或低于管理员所设阈值的 PVC。更详细的信息和代码段。为namespace配置默认的 CPU 请求和限制限制名称空间的存储使用量Kubernetes中的 Limit Range工具：管理Kubernetes的CPU和内存Popeye 会扫描集群中是否存在与配置，资源和网络漏洞有关的问题，并生成有关所有问题的详细报告。Goldilocks 扫描Pod中的资源限制，并使用建议的资源创建报告。Kube-advisor 来自Azure团队的工具，可扫描容器中缺少的资源并限制请求。K9s+benchmark 提供了一个命令行界面（CLI），使你可以轻松地管理，监视甚至对 你喜欢的终端软件中的集群进行基准测试你还可以将这些工具与 Datadog， Grafana + Prometeus，Azure Monitor结合使用，以改善资源并限制监视。总结设置资源请求：获取有关特定应用程序/容器的CPU和内存使用情况的信息。设置资源限制：运行负载测试以检测高负载下容器的CPU和内存。监视容器的CPU和内存使用情况。监视持久卷使用情况。检查是否可以使用Limit Range应用资源限制使用配额（不建议在生产环境中应用配额）文章来源：K8s中文社区译者：王延飞原文链接：https://dzone.com/articles/easy-and-fast-adjustment-of-kubernetes-cpu-and-mem

每天早晨，闹铃一响，窗帘自动拉开，屋外的阳光洒在自动播放早间新闻的床头音箱上。这是一个最简单的智能家居场景，也是最为典型的物联网应用，以家庭为平台，人与物、物与物之间能够互相通信，设备间可以对一个事件进行联动处理，极大方便我们的生活。不过，在资深系统工程师张玉云看来，IoT的万物互联只是第一步，让每个“物”都会学习、能思考，为人类社会产生价值，这才是物联网的价值点。 IoT的第一步：物和物的联接当研究操作系统的工程师碰上IoT会擦出什么火花？张玉云可以给出一个可参考的答案，有着三年操作系统维护，一年容器经验的他，既从事过欧拉操作系统外围包的维护，也定位过系统启动、运行等各层面的问题，这让他养成了一种全局观的思维意识：从系统维度去思考问题，从而更快地理解整个系统。举个例子，智能家居和智慧园区两个场景下的IoT联接，不仅规模数量不同，而且在系统性设计方面，也是各有乾坤。智能家居如果仅仅以家庭为单位，WiFi已经可以提供足够的设备接入能力，以及理想的信号覆盖范围。但是扩展到更大的地域范围，比如智慧园区，就需要系统性设计IoT各设备间的通信以及数据处理功能。在一个园区中，各类传感器采集到的数据，会通过网关设备进行数据清洗，然后再发往云平台完成遥测数据的上报。云平台上的数据，利用大数据等技术做进一步分析处理，让它们产生价值。这其中关键的环节包括数据的采集、上传以及分析。张玉云提到了华为云IoTDA云服务，其提供的物模型概念，可以很轻松地完成设备的抽象建模，定义设备的属性/命令，平台侧无需编码就能理解设备。再配合编解码插件，能够适应更多场景要求。另外，边缘侧可利用华为云提供的SDK完成设备的注册、数据上报等，也很方便。在实际应用中，他也提出了一些产品优化建议，比如IoT上报数据的展示部分是缺失的，需搭配其他云服务进行使用。同时，张玉云和我们分享了一个具体落地的案例，“之前工作中接触过一家传统设备生产厂商，典型的设备覆盖食品加工全过程。基于数字化转型的需求，需要对已有MES系统的数据加以清洗整理后发往平台，再从云端加以存储分析，以便挖掘其中的价值。我们基于华为云提供的云服务，很快为客户提供了解决方案，较好地贴合客户的业务场景。” IoT的第二步：“物”学会思考纯粹的“云—端”模式的物联网架构，存在着实时性、安全性以及成本居高不下的难题，此时如果要让IoT设备端产生的数据可以就近直接分析处理，让“物”学会思考，就需要边缘计算、5G等技术的加入。在张玉云看来，随着地理空间的扩大以及设备规模的增大，搭建局域网使这些设备接入网络的成本也在急剧增加。5G突破了地理位置限制的同时，提供了海量的设备接入能力，理所当然地成为智慧城市等项目网络层的解决方案。随着5G的普及，相信它会大大促进物联网的发展。参与项目的过程中，张玉云发现边缘计算也成为了不少客户关注的香饽饽。边缘计算减少了发往云平台的数据流量、节约成本的同时，使得事件更快地被处理。当前，市面上有不少开源的边缘框架正在帮助开发者完成相关的产品开发，这里就不得不提一嘴华为云开源的KubeEdge。KubeEdge基于kubernetes构建，也是CNCF首个提供云原生智能边缘计算能力的开源项目，它在架构上分为三个部分，其中云端负责云上应用和配置的校验、下发，边缘侧则负责运行边缘应用和管理接入设备，设备端运行各种边缘设备。它能完整的打通边缘计算中云、边、设备协同的场景。张玉云简单描述了它的工作原理，将部署KubeEdge的网关设备理解成node注册给kubernetes平台，所有网关设备又组成一个大的集群，这样的话，对有kubernetes经验的人员来说是零学习成本。张玉云认为，使用kubernetes原生的方式进行管理，还是极具创新精神的。不过，开源产品也存在诸多待改善的地方，需要开源社区的开发者们共同去发现、优化它。张玉云就提到了KubeEdge一些让他难以接受的“功能”，按照kubernetes网络模型，Pods之间无需NAT转换即可互相通讯，由于当前CNI支持的缺失，导致边缘侧Pod中的应用无法直接使用PodIP对接平台。除此之外，如何让边缘侧网关自动发现加入集群，将所有边缘网关组合形成一个集群进行管理，这样做是否有意义，也需要社区进一步讨论使之明朗。结语总而言之，即便当前的IoT工具产品还有待优化，但瑕不掩瑜，在经历了N个loT产品开发后，张玉云最后感慨道，“物联网包含的可能性是其魅力所在，或许，无人驾驶正在离我们越来越近，让我们拭目以待吧。”

每天早晨，闹铃一响，窗帘自动拉开，屋外的阳光洒在自动播放早间新闻的床头音箱上。这是一个最简单的智能家居场景，也是最为典型的物联网应用，以家庭为平台，人与物、物与物之间能够互相通信，设备间可以对一个事件进行联动处理，极大方便我们的生活。不过，在资深系统工程师张玉云看来，IoT的万物互联只是第一步，让每个“物”都会学习、能思考，为人类社会产生价值，这才是物联网的价值点。 IoT的第一步：物和物的联接当研究操作系统的工程师碰上IoT会擦出什么火花？张玉云可以给出一个可参考的答案，有着三年操作系统维护，一年容器经验的他，既从事过欧拉操作系统外围包的维护，也定位过系统启动、运行等各层面的问题，这让他养成了一种全局观的思维意识：从系统维度去思考问题，从而更快地理解整个系统。举个例子，智能家居和智慧园区两个场景下的IoT联接，不仅规模数量不同，而且在系统性设计方面，也是各有乾坤。智能家居如果仅仅以家庭为单位，WiFi已经可以提供足够的设备接入能力，以及理想的信号覆盖范围。但是扩展到更大的地域范围，比如智慧园区，就需要系统性设计IoT各设备间的通信以及数据处理功能。在一个园区中，各类传感器采集到的数据，会通过网关设备进行数据清洗，然后再发往云平台完成遥测数据的上报。云平台上的数据，利用大数据等技术做进一步分析处理，让它们产生价值。这其中关键的环节包括数据的采集、上传以及分析。张玉云提到了华为云IoTDA云服务，其提供的物模型概念，可以很轻松地完成设备的抽象建模，定义设备的属性/命令，平台侧无需编码就能理解设备。再配合编解码插件，能够适应更多场景要求。另外，边缘侧可利用华为云提供的SDK完成设备的注册、数据上报等，也很方便。在实际应用中，他也提出了一些产品优化建议，比如IoT上报数据的展示部分是缺失的，需搭配其他云服务进行使用。同时，张玉云和我们分享了一个具体落地的案例，“之前工作中接触过一家传统设备生产厂商，典型的设备覆盖食品加工全过程。基于数字化转型的需求，需要对已有MES系统的数据加以清洗整理后发往平台，再从云端加以存储分析，以便挖掘其中的价值。我们基于华为云提供的云服务，很快为客户提供了解决方案，较好地贴合客户的业务场景。” IoT的第二步：“物”学会思考纯粹的“云—端”模式的物联网架构，存在着实时性、安全性以及成本居高不下的难题，此时如果要让IoT设备端产生的数据可以就近直接分析处理，让“物”学会思考，就需要边缘计算、5G等技术的加入。在张玉云看来，随着地理空间的扩大以及设备规模的增大，搭建局域网使这些设备接入网络的成本也在急剧增加。5G突破了地理位置限制的同时，提供了海量的设备接入能力，理所当然地成为智慧城市等项目网络层的解决方案。随着5G的普及，相信它会大大促进物联网的发展。参与项目的过程中，张玉云发现边缘计算也成为了不少客户关注的香饽饽。边缘计算减少了发往云平台的数据流量、节约成本的同时，使得事件更快地被处理。当前，市面上有不少开源的边缘框架正在帮助开发者完成相关的产品开发，这里就不得不提一嘴华为云开源的KubeEdge。KubeEdge基于kubernetes构建，也是CNCF首个提供云原生智能边缘计算能力的开源项目，它在架构上分为三个部分，其中云端负责云上应用和配置的校验、下发，边缘侧则负责运行边缘应用和管理接入设备，设备端运行各种边缘设备。它能完整的打通边缘计算中云、边、设备协同的场景。张玉云简单描述了它的工作原理，将部署KubeEdge的网关设备理解成node注册给kubernetes平台，所有网关设备又组成一个大的集群，这样的话，对有kubernetes经验的人员来说是零学习成本。张玉云认为，使用kubernetes原生的方式进行管理，还是极具创新精神的。不过，开源产品也存在诸多待改善的地方，需要开源社区的开发者们共同去发现、优化它。张玉云就提到了KubeEdge一些让他难以接受的“功能”，按照kubernetes网络模型，Pods之间无需NAT转换即可互相通讯，由于当前CNI支持的缺失，导致边缘侧Pod中的应用无法直接使用PodIP对接平台。除此之外，如何让边缘侧网关自动发现加入集群，将所有边缘网关组合形成一个集群进行管理，这样做是否有意义，也需要社区进一步讨论使之明朗。结语总而言之，即便当前的IoT工具产品还有待优化，但瑕不掩瑜，在经历了N个loT产品开发后，张玉云最后感慨道，“物联网包含的可能性是其魅力所在，或许，无人驾驶正在离我们越来越近，让我们拭目以待吧。”

        以容器为代表的云原生技术，用开放、标准的技术体系，帮助企业和开发者在云上构建和运行可弹性扩展、容错性好、易于管理、便于观察的系统，已经成为释放云价值的最短路径。通过声明式API 和控制器模式（Controller Pattern），Kubernetes 构建出一套“面向终态”的编排体系，已经成为容器编排的事实标准，为用户提供了敏捷、弹性、可移植性等核心价值，被广泛用于自动部署、扩展和管理容器化应用。无状态应用容器化已是非常普遍地现状，但由于有状态应用基本上都是分布式的，其生命周期管理比无状态应用会复杂很多。        Kubernetes 现有资源类型无法实现有状态应用的合理抽象与描述，有状态应用对外部资源具有一定的绑定性依赖，多个实例之间往往有着拓扑关系，且这些实例本身并不完全等价。Kubernetes 内置的StatefulSet 资源类型在管理有状态应用方面仅解决了启动顺序、存储状态依赖性，无法实现应用“状态”的合理的抽象与描述，状态和容器进程本身无法解耦；有状态应用的管理经验无法得到有效沉淀，在当前环境下，开发者不得不去尝试编写一套复杂的管理脚本，而这些脚本、知识、和经验，并没有一个很好的办法能够有效的沉淀下来。这一现状制约着云原生应用更广泛的普及。        面向交付及运维的Operator 技术提供了打包、部署、管理Kubernetes 应用的全新方式。Operator 一种通过扩展Kubernetes 的资源模型，引入自定义控制器，实现对资源及其状态的灵活控制的技术。 Operator 把控制器模式的思想贯彻得更加彻底，在CRD 基础上加上自定义控制器，实现丰富、可扩展的调度及运维功能。Operator的本质是一段代码，这段代码通过实现Kubernetes 的控制器模式，来保证这个CRD 资源始终跟用户的定义完全相同，而在这个过程中，Operator 也有能力利用Kubernetes 的存储、网络插件等外部资源，协同的为应用状态的保持提供帮助。来源：云原生产业联盟

2020年10月13日上午11:02，作者：Mike MelansonRed Hat的Ansible自动化平台很快就会来到您附近的OpenShift Kubernetes集群。本周在AnsibleFest上，redhat预览了Ansible与高级集群管理（ACM）的集成，ACM是一个用于管理和扩展OpenShift集群的工具，该工具在今年早些时候发布。ACM提供了生命周期集群管理、基于策略的管理和高级应用程序部署，通过添加Ansible，Red Hat OpenShift用户现在可以在这些生命周期中直接插入Ansible自动化，而不需要特殊脚本或其他方法。“您可以在OpenShift环境中始终使用Ansible，但我们在这里所做的是将其插入工具。例如，在创建集群生命周期的过程中，有一个地方可以实际配置Ansible脚本，使其在适当的时间点运行，”Red Hat管理业务部门的副总裁兼总经理Joe Fitzgerald解释说。“您以前也可以这样做，但问题是，当有人去配置集群时，他们是在脚本之外执行的吗？他们是在控制台上做的吗？它可以是一个单行本，可以打开一单子，也可以这么简单，但现在，你可以把它**去，而在此之前，人们有责任说出在正确的时间点被调用的机制是什么。”Fitzgerald提供了许多可以使用Ansible自动化的示例，包括在部署后将应用程序连接到负载平衡器，或者在流程和治理方面，Ansible可用于修复目的，警告应用程序何时违反某些策略，并根据需要将其恢复到法规遵从性。至于Ansible可能实现的各种自动化操作，这是该平台在过去一年中一直关注的问题，因为它引入了Ansible内容集合。这些集合现在已经超过55个，提供由Red Hat维护的经过认证的Ansible内容，而私有自动化中心为Ansible用户提供了一种在内部共享自定义脚本的方法。虽然Advanced Cluster Management这个名字似乎暗示了该工具只适用于那些具有更复杂OpenShift部署的用户，但Fitzgerald说，相反，它已经看到了对该工具的兴趣，“无论范围和大小”，“几乎所有客户都对ACM感兴趣”。虽然一个组织可能只运行一个集群，但它们可能处于受管制的行业中，需要执行策略，ACM提供了这一点。类似地，对于运行几个集群的组织，ACM提供了对集群运行状况的可见性，现在通过Ansible集成，ACM充当了“一个管理控制平面，它允许我们非常清晰地构建这些Ansible点。”目前，Ansible与ACM的集成正在TechPreview中引入，尚未确定其通用性。同时，红帽也展示了一个“概念的证明”，菲茨杰拉德说，对于knative调用Ansible。Knative是一个开源项目，允许用户在Kubernetes上运行容器，作为无服务器、事件驱动的工作负载。“想想事件驱动的自动化，其中可以调用Ansible脚本，而不是Python或其他东西。然后，你可以在将来开始配置这样的东西：“当我收到这个事件时，我想运行这个脚本。”这是另一种方法，可以在发生事情时轻松地插入自动化，而不是通过非常复杂的管道或让一个团队参与进来，菲茨杰拉德说：“为了在适当的时间点实现自动化。原文参见：https://thenewstack.io/red-hat-brings-ansible-automation-to-kubernetes/

网站上给出的创建kubernetes.repo的命令有问题，感觉完全没做过测试嘛，原命令是这样的：使用这个命令后的结果，是这样的：

ONAP安装部署指南在Kubernetes（简称K8s）上安装部署ONAP。可以将ONAP各个组件以容器的形式进行部署，并通过Kubernetes进行管理。ONAP的所有组件均运行在Docker之中，而且需要一个Kubernetes集群进行编排管理。安装要求说明多种场景下部署，ONAP的部署可以分为物理裸机部署、私有云环境部署和公有云环境部署。ONAP的安装将以C版本为例ram 224GB  harddist 160GBvCPU 112ports:all open2.2　在物理裸机上部署ONAP2.2.1　资源准备—安装OS物理裸机安装Ubuntu Server 16.04 LTS。1.设置iptables默认规则为ACCEPT新安装的系统默认的规则可能是DROP，运行下列命令修改默认为ACCEPT。iptables -p INPUT ACCEPTiptables -p FORWARD ACCEPTiptables -p OUTPUT ACCEPTiptables-save> /etc/iptables.rules2.设置虚拟内存的最大值将进程可以使用的内存区域设置为最大值，以避免内存溢出等异常。sysctrl -w vm.max_map_count=10243.安装及配置openssh-server需要安装openssh-server之后才能远程登录服务器。安装openssh-server的命令如下：sudo apt updatesudo apt install openssh-server配置openssh-server机器的用户名/密码登录方式，脚本如下：#setup ssh access -default login:ubuntu/ubuntused -i 's/PermitRootLogin.*/PermitRootLogin yes/' /etc/ssh/sshd_configsed -i \'s/PasswordAuthentication yes/' /etc/ssh/sshd_configcat >> /etc/ssh/sshd_config <<EOFCiphers aes128-cbc,aes192-cbc,aes256-cbc,aes128-ctr,aes192-ctr,aes256-ctr,3des-cbc,arcfour128,arcfour256,arcfour,blowfish-cbc,cast128-cbcMACs hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-sha1-96,hmac-md5-96kexAlgorithms diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group-exchange-sha256,echhsha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group1-sha1,curve25519-sha256@libssh.orgClientAliveInterval 60ClientAliveCountMax 5EOF脚本运行之后service sshd restart2.2.2　在物理服务器上安装KubernetesKubernetes是Google开源的一款基于容器的集群管理系统，是其内部Borg工具的开源版。Kubernetes是目前公认的最成熟、先进的开源容器集群管理系统，发展非常迅猛，得到了容器生态圈厂商的全面支持。许多公有云服务厂商都提供基于Kubernetes的基础设施层支持。一个Kubernetes集群，是由Kubernetes Master及若干Worker（节点）组成的。节点上最小的操作单元被称为Pod：相关的一个或多个容器构成一个Pod，Pod包含的容器运行在同一个上下文中，可看作一个统一的管理单元，共享相同的volumes和network namespace空间。Kubernetes Master作为集群的中心控制节点，会运行3个关键进程：kube-apiserver、kube-manager及kube-scheduler。另外，在Kubernetes的Master和Worker上还需要安装ETCD及容器网络插件（例如Flannel），以负责存储Kubernetes的信息以及同一个集群内容器的内网规划和支持。kube-apiserverkube-managerkube-scheduler在一个Worker节点上，会运行两个进程：kubeletkube-proxy安装k8s步骤略2.2.4　在Kubernetes上安装部署ONAP1.部署工具安装在安装ONAP之前，需要先安装相关的工具—Kubectl和Helm。2.部署ONAP登录Kubernetes Master节点，从ONAP社区代码仓库下载OOM代码：git clone -b casablanca http://gerrit.onap.org/r/oomcd oom/kubernetes 拷贝Helm的deploy插件到helm目录下：sudo cp -R ./helm/plugins/ ~/.helm启动Helm Server，作为ONAP charts的本地仓库服务器：helm inithelm serve&添加本地Helm仓库：helm repo remove stablehelm repo remove localhelm repo add local http://127.0.0.1:8879/charts验证Helm仓库是否添加成功：helm repo list给Helm创建权限：kubectl create serviceaccount --namespace kubesystem tillerkubectl create clusterrolebinding tiller-cluster-rule --clusterrole=cluster-admin --serviceaccount=kube-system:tillerkubectl patch deploy --namespace kube-system tiller-deploy -p '{"spec":{"template":{"spec":{"ServiceAccount":"tiller"}}}}'构建ONAP各个组件的Helm Chart（如果想要选择性地构建，可以编辑oom/kuber-netes/onap下的values.yaml文件，把相应的组件开关改为true或false即可实现）：make all显示已经安装的Helm Chart的方法如下：helm search -l然后执行如下命令来部署ONAP：helm deploy dev local/onap --namespace onap如果要监控安装状态和是否成功完成安装，则执行以下命令：kubectl get pods -n onap如果所有pod的STATUS都是Running则表示ONAP安装结束，此时便可以进行health测试来验证ONAP是否安装成功了。如果ONAP健康检查通过，则可认为ONAP安装成功。运行以下命令验证：bash ./robot/ete-k8s.sh onap health如果需要安装ONAP的某一个组件，如SO，可执行以下命令，-n后面指定在Helm中的release名字：helm install onap/so --version 2.0.1 -n so可执行下面的命令删除ONAP：helm undeploy dev -purge如果需要删除Helm，需停止Helm相关服务，并且移除Kubernetes环境中的相关组件，即执行如下命令：helm reset -forcerm /usr/local/bin/helmrm -rf /root/.helmps /aux |grep helm#find the pid of helm related process and #kill -9 <pid>kubectl delete serviceaccount --namespace cubesystem tillerkubectl delete --namespace cubesystem tille-deploy2.3　在OpenStack私有云环境下部署ONAP在OpenStack上创建虚拟机部署ONAP，需要数据中心或者实验室有一个OpenStack的集群。可参见链接：https://docs.openstack.org/horizon/latest/user/index.html# 。使用Rancher安装Kubernetes，参见链接：https://docs.onap.org/en/casablanca/submodules/oom.git/docs/oom_setup_kubernetes_rancher.html 。2.4　在公有云虚拟机上部署ONAP以华为公有云为例1.注册账号华为公有云的主页https://www.huaweicloud.com/ ，注册华为公有云的账号账号注册完成后，依照匹配的类型完成实名认证2.购买弹性云服务器点击服务列表中的弹性云服务器（Elastic Cloud Server，ECS）订购云服务器（虚拟机），以便用于部署ONAP。3. CCE环境准备ECS服务器购买完成后，将基于购买的ECS服务器创建云容器引擎CCE（Cloud Container Engine，云容器引擎，一种Kubernetes集群服务）。和购买ECS服务器类似，点击服务列表选择云容器引擎CCE进行购买。集群的管理节点规模可以按照购买的ECS服务器个数来选择。完成Kubernetes集群的购买后就可以新增节点了然后安装Kubectl，作为Kubernetes控制节点的客户端。当前支持两种安装方式：第一种是选择一台和ONAP-Node在一个VPC下的服务器；第二种就是选择一台在互联网上的服务器。2.5　ONAP as A Service展望SaaS是SoftwareasaService（软件即服务）的简称。SaaS与on-demand software（按需软件）、the application service provider（ASP，应用服务提供商）、hosted soft-ware（托管软件）具有相似的含义。与传统软件需要先安装在本地再使用不同，SaaS是一种通过互联网提供软件的模式。厂商将应用软件统一部署在自己的服务器上，客户可以根据自己的实际需求，通过互联网向厂商定购所需的应用软件服务，按定购的服务多少和时间长短向厂商支付费用，最后通过互联网获得厂商提供的服务。SaaS形态的软件消除了传统软件在每一个用户主机上对软件安装、升级和维护的工作，可以有效降低成本。借鉴SaaS软件的思路，将ONAP部署在公有云中，可以有效减少本地搭建ONAP环境的开销，包括服务器的硬件资源开销和搭建基础设施层的人力开销等。而对云上的ONAP进一步改造也可以将ONAP作为SaaS服务提供出来，一些设计态组件的功能和认证功能甚至可以独立对外提供服务。实现ONAPaaS将很大程度上提升ONAP的易用性：不同地域的网络设计人员可以登录同一个位于云端的ONAP环境进行合作设计开发，提高网络设计的效率。运维人员可以远程登录ONAP并对指定地域的网络进行管理，不同地区的网络运行事件都将上报给云端的ONAP，事件的处理和策略的制定将变得简单。对于VNF的认证也只需要VNF供应商上传VNF Package到云端的ONAP，就能方便地进行认证测试，无须额外搭建测试环境来进行验证。对云端的ONAP进行升级维护后，所有用户都能立即获得最新的ONAP功能，不再需要对每一个区域的ONAP进行单独升级操作。2.6　本章小结本章介绍了在三种场景下如何使用OOM在Kubernetes上安装部署ONAP。三种场景分别是物理裸机、OpenStack私有云环境和公有云环境。使用OOM可以将ONAP各个组件以容器的形式进行部署，并通过Kubernetes进行管理。同时利用了容器轻量化以及Kubernetes成熟管理的优势，使得ONAP更易于安装并且更加稳定可扩展。最后，对ONAP的SaaS化进行了展望，展示了ONAP的SaaS形态易用性的提升和能为用户带来的好处。注：还是saas最方便。

金融、电商、在线教育、游戏等时延敏感型业务对算力和网络IO提出了极致的性能诉求，要求运行环境能够最大限度的提供计算和网络资源。业界通用的第一代裸金属容器虽然能为业务提供充足的CPU资源，但如何提供与算力匹配的高性能、低开销、快速弹性扩缩的网络资源，对现有的容器网络技术提出了一系列挑战。近一年多来，主流公有云容器服务和各家Kubernetes商业发行版都在容器网络方面加大投入，我们发现，这些商用增强特性和开源创新方案，虽然场景或目标有差别，但几乎都把“卸载”（Offloading)和“加速”（Acceleration)作为技术主线。 华为云基于擎天架构实现的容器网络，开创性的采用了软硬协同、卸载、Kubernetes Service下沉、高密直通等技术，构建了业内领先的容器网络方案，成为华为云构建全球独家零损耗裸金属容器的杀手锏之一。硬件直通 网络性能零损耗要彻底解决容器的互通性问题，必须赋予容器与节点同等的互通能力，这是容器网络的一次重大演进，即把容器网络与底层网络拉平，被Kubernetes社区称为VPC-Native的CNI。容器网络Yangtse就是采用VPC-Native组网，这种组网被称作ENI(Elastic Network Interface)模式，容器直接挂载具有VPC子网地址的ENI，具备完全VPC网络互通能力，即容器地址属于VPC子网，容器独占对应的ENI网口，容器实例可以在集群VPC网络和与之相连的其他VPC网络中进行原生路由，并且可以直接使用VPC原生的网络能力如 network policy、ELB、EIP、NAT等。同时基于华为云擎天架构的软硬协同能力，将管理和转发逻辑下沉到擎天卡上，实现容器网络主机资源0占用。数据面转发能力卸载至擎天卡后，还大大提高包转发率和降低时延，采用VF直通容器，实现零损耗的网络转发性能，容器内网卡与裸金属服务器主网卡性能持平动态队列 高算力自动匹配高IO当前容器网络方案中，无论是广泛采用的Calico路由或VPC路由模式的veth/ipvlan组网，还是新兴的VPC-Native弹性网卡(ENI)组网，都没有针对不同的容器规格提供差别化的网口规格。内核单队列虚拟网络设备veth/ipvlan或是固定队列的ENI网口，转发能力是受限的，原因在于网络报文的转发逻辑是在内核软中断中处理的。当网络设备的收发队列有报文到达需要转发时，会触发相应的软中断，内核通过中断负载均衡机制将不同网口队列的中断分发给不同的CPU核并行处理，从而提升转发性能。显而易见，单队列或固定队列网口是无法灵活满足HPC等计算与IO双密集的容器负载，使得网络IO成为瓶颈点，拉长了工作负载运行时间，提高了客户成本。而容器网络Yangtse支持网口动态多队列，能够根据容器负载的规格，比如：16核的容器负载，容器网络会自动分配16队列的直通ENI，实现计算与IO的自动匹配，提供最优的整体性能，达成了名副其实的高性能弹性计算。Service卸载 一跳直达性能倍增Kubernetes原生的Kube-proxy提供了集群内Service负载均衡能力，iptables/netfilter被誉为Linux内核的瑞士**，也是Kube-proxy的第一个实现方案。随着Kubernetes生产集群的规模越来越大，Service数量和后端数量也会同步增长，iptables的规则数是服务数与后端数的乘积，当规则数超过5000后，规则刷新性能和新建连接速率（线性查表）都会显著恶化，CPU、内存占用会急剧上升。容器网络Yangtse将Kube-proxy下沉至擎天卡，抽象出Internal LB的概念，利用流表的卸载能力实现Service访问一跳直达，不仅提升了Service性能，而且释放了裸金属服务器的计算资源，减少了资源损耗。综上所述，华为云在容器网络方面已经做出大量创新性的探索，并逐步应用到产品中提升产品的商业价值，或贡献给社区，以促进云原生技术发展。除了文中提到的三点外，容器网络Yangtse为支持大规模容器部署和快速扩容，还提供了更多的黑科技，我们将在下一篇文章中为您详细介绍。申请第二代裸金属容器：https://www.huaweicloud.com/product/cce.html

在刚刚结束的CLOUD NATIVE+ OPEN SOURCE Virtual Summit China 2020上，由华为云云原生团队主导的容器批量计算项目Volcano正式发布1.0版本，标志着Volcano项目已经开始走向成熟与稳定。Volcano项目介绍Volcano是基于Kubernetes的云原生批量计算引擎，基于华为云在AI、大数据领域的深厚业务积累，补齐了Kubernetes在面向AI、大数据、高性能计算等批量计算任务调度、编排等场景下的短板，向下支持鲲鹏、昇腾、X86等多元算力，向上使能TensorFlow、Spark、华为MindSpore等主流行业计算框架，让数据科学家和算法工程师充分享受到云原生技术所带来的高效计算与极致体验。Volcano架构示意图随着Kubernetes作为AI、大数据和高性能批量计算的下一代基础设施的趋势逐渐清晰，越来越多的企业对Kubernetes在深度学习、科学计算、高性能渲染等方面提出了更高的要求。然而Kubernetes作为普适的容器化解决方案，仍与业务诉求存在一定差距，主要体现在：K8s的原生调度功能无法满足计算要求K8s作业管理能力无法满足AI训练的复杂诉求数据管理方面，缺少计算侧数据缓存能力，数据位置感知等功能资源管理方面缺少分时共享，利用率低硬件异构能力弱Volcano的诞生正是基于这些痛点，在调度、作业管理、数据管理、资源管理四个方面进行了重点优化。增强了任务调度能力，如公平的调度（fair-share）、组调度（gang-scheduling）  进一步优化了作业管理能力,如multiple pod template能力、更灵活的error handling机制  增加计算侧数据缓存，提升数据的传输与读取效率引入多维度的综合评分机制，实现资源更高效的管理和分配多元算力支持：支持x86、鲲鹏和昇腾等算力   Volcano项目进展时间轴Volcano v1.0新特性介绍Volcano v1.0的核心概念和关键特性，主要包含以下要点：Queue、PodGroup、Volcano Job等核心概念均已实现支持Binpack、Conformance、DRF、Gang、Preempt、Reclaim、Priority、Proportion等多种调度策略支持Rest API、CLI等多种交互方式完成与Spark、Argo、MPI、Flink、Mxnet、Paddlepaddle、Tensorflow、MindSpore等主流高性能计算框架的无缝对接支持Job的全生命周期管理和动态扩缩容支持GPU异构与共享完备的golangCI-lint check、e2e以建立增强代码质量和稳定性除以上特性外，Volcano始终保持与Kubernetes社区、Golang最新版本保持一致。Volcano社区和生态建设进展经过一年多的发展，Volcano的社区和生态建设已经步入快车道。截至目前，社区和生态建设取得了以下成绩：社区贡献者80+社区贡献参与组织15+，包括华为、百度、腾讯、AWS、IBM、 Oracle等获得Star 1100+，Fork 220+代码库7个，Release 6个Issue 320+，PR 590+已完成对Spark、Argo、MPI、Flink、Mxnet、Paddlepaddle、Tensorflow、MindSpore、Cromwell等10+主流计算框架的支持华为云CCE（云容器引擎）、CCI（云容器实例）、ModelArts等多个云服务已将Volcano集成为基础设施底座并商用，服务领域已涵盖AI、大数据应用、基因计算、批处理等场景，并实现与华为鲲鹏、昇腾处理器深度融合，最快每秒1000个容器的调度发放，成为高性能、极致性价比的批量计算解决方案。深入了解Volcano如果想更加深入了解Volcano，可以参考以下资源：Volcano官网：https://volcano.sh/Github：https://github.com/volcano-shVolcano简介：https://github.com/volcano-sh/volcanoVolcano设计：https://github.com/volcano-sh/volcano/tree/master/docs/designVolcano路线图：https://github.com/volcano-sh/volcano/blob/master/docs/community/roadmap.mdVolcano社区交流微信群：Volcano CN未来可期随着Volcano v1.0的发布，Volcano社区建设与上下游生态的融合必将更加紧密，基于Volcano的商业应用也将极大地促进AI、大数据、科学计算、渲染等领域充分享受到云计算带来的极大便利和极致体验，助力企业数字化转型进入新的高度。展望未来，华为云也将在云原生领域持续耕耘，持续引领创新、繁荣生态，助力各行业走向快速智能发展之路。

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管理面在部署过程中需要提前下载相关镜像的时间。