容器技术

Kubernetes 自身比较复杂，应用门槛较高，用户在开始容器化迁徙时常常遇到各种各样的问题，因为不足故障定位的技能和工具，用户经常产生挫败感，甚至放弃业务容器化。其中网络问题体现尤为突出，Kubernetes 网络虚拟化导致网络问题排查的难度微小。 KubeSkoop 是阿里云容器服务团队开源的 Kubernetes 容器网络诊断工具，反对支流的网络插件和云厂商的 Kubernetes 集群诊断。它正是为了升高网络问题排查难度，让没有网络常识的人也能够自动化地定位网络问题。 Kubernetes 容器网络诊断工具：https://github.com/alibaba/kubeskoopKubeSkoop 可能主动构建出给定源和目标地址在容器网络中的拜访门路，自动化地采集和剖析链路上每一个网络节点的配置，联合 eBPF 内核监控以及 IaaS 层的网络配置查看，定位出导致网络不通的根因，极大地升高了网络问题定位的工夫，即便没有任何网络技能的用户也能够应用。目前在阿里云容器服务的环境中，作为自运维工具解决了大量客户在大规模 Kubernetes 集群场景下遇到的网络问题。 本文将会对容器网络和传统定位伎俩带来的问题进行简略的介绍，以及对 KubeSkoop 的功能设计等方面进行总体讲解。 容器网络网络连通性-CNI容器网络是 Kubernetes 集群中及其重要的一部分，包含了形成集群网络连通性的 CNI 插件、Service 服务发现机制、NetworkPolicy 网络策略等。Kubernetes 集群网络保障了每个 Pod 领有本人独立的网络空间，并且可能与集群中的 Pod 和 Node 相互通信。 CNI 插件是形成集群容器网络中的外围，实现集群级别惟一的地址调配，将集群维度的网络买通。 不同的 CNI 插件，如 Flannel、Calico、Cilium、Terway 等，有其不同的网络实现，包含地址调配，网络虚拟化实现，网络连通性实现等。服务发现和网络策略除 CNI 插件外，Kubernetes 还提供了 Service 作为服务发现，以及 NetworkPolicy 作为网络策略能力。这些能力也是通过可替换的组件来实现的。 复杂性和网络问题定位因为概念繁多，以及插件实现抉择的丰富性，导致 Kubernetes 网络问题存在着相当的复杂性，包含： 逻辑概念的复杂性Ingress/Service/NetworkPolicy 配置灵便，可能导致配置谬误/规定抵触等问题。应用 ServiceMesh 或第三方 CNI 插件，带来更简单的网络策略和扩大能力。数据面实现的复杂性数据立体通过不同组件的多层解决，且存在多种实现。协定栈链路简单，波及到网卡驱动 /netfilter/route/bridge 等配置。不同云厂商的底层配置不同，平安组、路由表等配置简单。传统的容器网络问题定位伎俩，次要是通过抓包定位丢包点、压测复现、人工查配置等形式。存在着定位流程长、大量工夫开销、人员教训要求低等问题。 在日常的工作中，排查容器网络问题占用了相当大部分的精力。因而，咱们开发了 KubeSkoop 我的项目，来实现针对容器网络场景下问题的主动诊断系统。 KubeSkoop 性能在咱们的剖析中，常见的 Kubernetes 网络问题能够分为以下两类： ...

近日，火山引擎边缘云原生团队的同学在QCon寰球软件开发大会上分享了火山引擎容器技术在边缘计算场景下的利用实际与摸索，并在一众AIGC、LLM等当下热门议题中怀才不遇，入选观众满意度投票中“叫好又叫座议题Top5”。以下是演讲全文：大家上午好！ 我是来自火山引擎边缘云原生团队的李志明。明天给大家分享的议题是对于容器技术在边缘计算场景怎么去落地，以及咱们在哪些场景下做了实际。 首先做一下自我介绍。我本人始终在CDN和边缘计算行业从事技术研发和架构设计工作，集体比拟善于像比方Kubernetes、服务网格、容器网络相干的云原生技术，对于高性能的Nginx和高性能缓存服务器也比拟理解，目前次要是负责火山引擎边缘容器平台，以及边缘容器实例产品的研发落地。 明天我的分享议题次要从四个方面。第一个给大家介绍什么是边缘计算和边缘容器。而后就是给大家讲一下在边缘计算场景下，咱们落地边缘容器这样的云原生技术，面临着什么样的技术挑战，而后咱们在技术计划上是怎么去解决的。接下来也给大家分享一下咱们边缘容器技术在哪些内外部场景进行了落地，打造了什么样的产品技术能力。最初给大家分享咱们后续在云原生相干畛域会做哪些摸索。 01 边缘计算和边缘容器边缘计算次要就是在凑近客户的终端放一些边缘计算的算力资源，次要是给一些利用开发和服务商提供IaaS的计算存储网络的资源，升高客户的延时，升高客户的带宽。简略了解，绝对于核心云的产品，边缘计算次要宽泛散布在二、三、四线城市，它从资源散布上必定是比核心云散布得更广，更凑近客户。在规模上，它个别都是几台到几十台服务器，而后在一些区域核心上可能会有几百台服务器，就是规模必定比核心云更小。 边缘计算次要有三个方面的价值： 第一个，绝对于把服务部署在核心的场景，把服务部署在更凑近客户的端上可能大大降低客户拜访的提早。另外，比方提到像RTC、CDN、内容散发这样的一些场景，必定比间接去拜访客户核心要更短，响应时延个别都会在100毫秒以内。第二个就是带宽层面。传统的RTC或者一些服务间接回源到核心，它的回源带宽老本是比拟高的。这个时候当你把一些策略和执行的算法放到边缘上执行的话，能够大大减少客户的带宽，能够升高客户的老本。当然因为咱们边缘的带宽绝对于核心的BGP带宽必定也是比拟低的。另外，还有一些本地计算的场景，有些客户的数据有平安或者合规的要求，这种场景下是比拟适宜边缘计算这样一些场景的。介绍完边缘计算的介绍和边缘计算的价值，接下来重点介绍火山引擎边缘云的边缘容器。 什么是边缘容器呢？绝对于以后的核心容器，边缘容器散布于方才介绍的宽泛的边缘计算的节点，次要散布在二、三、四线这样的城市，依靠于像Kubernetes这样一些云原生的技术，给客户提供场景化的解决方案。 火山引擎边缘云的边缘容器次要是有以下的四个次要的个性： 资源笼罩广 绝对于核心容器，咱们的资源覆盖面必定会更广。因为宽泛散布在大量的边缘节点上，所以说咱们资源分布面更广，离客户更近。 疾速弹性交付 绝对于边缘虚机这样的产品，因为传统客户之前在核心云应用，比方像一些函数的服务或者RTC的服务，这些场景如果间接下沉到边缘，大部分的客户会面临一个问题就是如何去治理边缘的这些节点和机房，以及原来传统的公布零碎也是基于核心或者单机房去设计的，当服务下沉到边缘机房的时候，怎么去运维。所以说边缘容器第二个个性，就是绝对于边缘虚机的产品，可能提供疾速的弹性交付，客户不须要去感知广州有几个机房，深圳有几个机房，甚至华东区电信有几个机房，怎么去开明，怎么去保护。火山引擎会基于云原生的技术屏蔽底层的整体资源笼罩的差别，而后批量交付。举个简略的例子，广东电信的客户须要1000个几核几GB的算力资源，咱们就能够进行疾速交付，而不须要客户去针对于广东电信100个边缘节点一一去开明，咱们能够达到疾速交付能力。 全生命周期治理 很多客户，特地一些创新性场景，从核心下沉边缘，或者某些新业务场景是没有针对边缘场景去部署和运维的能力的。因为边缘机房太多了，节点也会面临裁撤、下线。所以说火山引擎边缘容器会屏蔽这些差别，给客户对立提供像边缘利用的部署、版本的治理，包含一些利用的迁徙等等一系列的Devops的全利用生命周期治理的能力。 全局布局调度 另绝对于一些核心容器的调度，个别都是基于Region的调度，而边缘的话，火山引擎有一个叫全局布局调度。因为咱们会把边缘所有的边缘机房的算力资源对立进行治理和管控，依照客户的算力需要来进行批量交付。比方客户说广东电信须要1000个，这个时候咱们就会看整个广东电信整体的算力散布状况，给客户进行批量交付，所以咱们有一个全局布局调度的技术能力。 02 火山引擎边缘容器技术挑战与应答火山引擎边缘容器技术挑战介绍完了边缘容器，来讲讲火山引擎边缘容器有哪些外围的产品技术挑战，重点介绍以下几个技术层面。 容器技术在边缘计算场景落地会面临什么样的技术挑战呢？ 因为传统的就像Kubernetes这样的技术，个别会去治理一个机房或者是治理多个Region，这样是比拟常见的。然而边缘机房，第一个咱们叫资源扩散。因为边缘的IDC机房散布太多了，有几百个，甚至上千个IDC机房。而且不同的IDC机房物理环境、硬件环境，甚至服务器数目都不太一样，有的只有几台，有的有几百台。怎么基于Kubernetes正当地去治理不同的业务以及不同的资源，其实就是咱们会面临的第一个问题。 第二个，绝对于核心的一些机房，其实边缘的网络环境是比拟差的。像弱网、核心跟边缘断网、边缘机房裁撤割接，这样的状况是比拟频繁的。当客户的业务下沉到边缘的时候，特地是在边缘跟核心断网的时候，怎么解决客户边缘容器上的业务、保障不会呈现被驱赶这样的一些状况，这就是咱们面临的第二个问题，怎么去解决这样的问题。 第三个，咱们边缘的机房规模太小了，不可能去做资源分池解决；不可能一部分机器去生产虚机，一部分去生产容器。有些机房可能总共就是几台服务器。那么如何去实现虚机、容器的混合生产，混合调度，达到资源高密的生产和应用。这是咱们面临的第三个技术问题。 最初，因为边缘IDC机房太多，很多客户，比如说我这个利用，须要在广州电信1发1.0.0的版本，在广东电信2发1.0.2版本，不同的机房，要部署不同的版本。同时它在利用降级的时候，要实现灰度公布。同时还有一种状况，很多客户是多个利用组合部署才能够对外提供服务。比如说它在一个机房内同时要部署日志服务、监控服务，以及它本人的一些计算服务。如何去帮客户解决这种多利用的组合部署  以及多利用之间的版本灰度，其实也是咱们面临的另外一个技术问题。这些问题都是在单机房或者说单kubernetes场景下不会遇到的。 我接下来重点讲一下火山引擎容器团队针对这四个技术难点，是抉择什么样的技术计划解决的。 火山引擎边缘容器技术解决方案首先就是重点给大家介绍一下咱们整体火山容器平台的技术架构，就是边缘容器平台架构。 最底层咱们定义为整个IaaS、PaaS的资源层。在资源层面，边缘的资源笼罩差异性是十分多的，咱们有自建的IDC资源，甚至有一些CDN的自建机房资源，包含多云的虚机资源以及其余场景的一些异构资源、三方资源。这些资源，咱们会依照节点、属性、地位、区域，依照标签进行对立的治理，进行辨别和分类。 当资源被标准化之后，咱们会引入一层PaaS的资源管控层，这一层咱们重点构建了第一个能力，就是解决第一个问题：海量资源的纳管问题。整个技术其实咱们也是基于Kubernetes技术打造的。前面我会重点去解释一下咱们整个PaaS资源层，怎么基于Kubernetes进行设计。当咱们把整个资源都纳入Kubernetes体系之后，再上一层咱们就须要对这些边缘的资源进行编排、进行利用的治理、进行镜像的治理，这一层叫metakubernetes，就是咱们的管控集群，咱们叫PaaS管控层。这一层会对立给客户提供，比如说像一些边缘的Kubernetes集群的治理，像集群联邦这样的一些能力，以及比如说客户业务部署的时候怎么基于Kubernetes帮客户被动熔断业务，或者咱们平台本身导致的一些故障，可能主动去熔断，咱们叫风控，就是风控的能力建设。 此外，因为边缘的环境比拟差，当客户的容器大量降级的时候，怎么去解决一个镜像散发的问题。 针对于海量纳管的资源之后，咱们须要给客户提供调度以及高密的生产，咱们怎么去解决这种交融调度、交融生产的问题呢？ 最初就是一些监控计费的通用能力。 当咱们整个PaaS管控层，整体建设了这些零碎之后，容器平台侧就会提供不同语义来应用整个火山引擎边缘计算的资源；比方基于利用维度的，客户齐全不去感知底层的资源差别，叫利用托管的模式。另外一种，用户可能只心愿应用容器算力资源，它有本人的公布零碎，咱们就能够间接交付边缘容器实例，就是相似于核心ECI的资源状态。此外，咱们也反对一种弹性的资源交付状态，比方依照分时、或者容器的负载主动扩缩容，咱们叫边缘Serverless这种状态。此外，有些用户曾经基于Kubernetes去建设运维公布平台了，他心愿基于Kubernetes的语义来应用容器资源，那么针对这种场景，咱们也会反对基于Kubernetes语义接口来应用边缘容器资源的能力。最上层就是咱们面对不同的业务场景，像一些点播、直播、RTC、动静减速、边缘函数、拨测、压测这样的场景，咱们基于PaaS整个服务层，针对不同用户提供不同的应用状态。这是咱们整个边缘容器的技术架构。 接下来重点讲讲针对于以上的技术问题，咱们到底怎么去设计和落地的。 边缘自治与资源纳管第一个问题是咱们怎么去解决边缘海量资源的纳管问题，以及像边缘这种弱网关系下，咱们怎么去解决断网状况下客户的pod不驱赶，达到边缘自治的能力。 针对第一个，因为边缘资源比拟扩散，其实咱们这边也是分两种场景进行解决的。第一种叫边缘计算的资源，就是说咱们自建IDC资源。咱们自建的IDC资源，相对而言是比较稳定的，而后基本上规模绝对比较稳定。这种状况下，因为它要去混合生产虚机和容器，在这种场景下，咱们采纳的是Kubernetes下沉的计划，在边缘机房外部内置一个Kubernetes集群。第二种就是绝对于一些单台服务器就是一个结点，或者是多云的一些异构机器，这种机器，它的网络环境不太规范，机型也不太规范，容易呈现一些硬件的故障。这样一些非凡的机器，咱们是采纳了一个叫边缘托管kubernetes的计划。 在这个时候，咱们在资源入库存的时候，咱们会针对不同的节点和机器进行标签治理，最上层的有一个叫异构资源纳管的容器管控平台。这个时候咱们主动会依据以后的一个节点的规模和机器的状态，依据主动布局的后果纳入到不同的像边缘托管的kubernetes集群或者说是节点外部的一个kubernetes集群。而咱们异构纳管平台，它就会主动去感知不同区域的资源散布状况，主动去管控边缘托管kubernetes集群，自适应的去纳管不同区域的资源。当初咱们落地个别都是依照大区维度去布局。一个边缘托管kubernetes，咱们大略会去纳管2000-3000台服务器。 通过这样的模式，从这里看到咱们这个架构是分布式的架构，当边缘机器越多的时候，咱们会主动布局出更多的kubernetes集群来纳管资源。这样其实是可能做到像边缘数万级别的机器，甚至数十万级别机器基于边缘的kubernetes进行纳管的。 当咱们解决了资源管理的问题之后，咱们必然要解决第二个问题。弱网环境下，咱们怎么去解决不会因为边缘跟核心的网络断连，导致用户的Workload或者pod被驱赶。在咱们这个计划外面就解决了这个问题。第一个，比如说像一些异构的资源池外面，咱们采纳的是边缘托管kubernetes的计划，边缘托管kubernetes这个计划，当呈现异构的机器跟核心的托管kubernetes断连的时候，它原生的一些机制是会把原先的一些Workload，包含一些要害的网络资源保护到边缘节点上。这个时候它并不会影响曾经失效的策略，从而也不会去驱赶在这些机器上的pod和要害的用户网络配置、存储的一些配置。 针对于边缘计算节点，就是咱们自建比较稳定的IDC机房，因为咱们采纳的是边缘kubernetes下沉的计划。这个计划外面，当核心跟边缘断网了之后，边缘的kubernetes，它原生就曾经缓存了原先核心曾经下发的各种Workload，各种的一些客户的网络配置，所以说它也是可能达到边缘自治的成果的。咱们次要是通过这样的一个技术架构来解决方才讲的面临的资源扩散治理以及像弱网环境下的资源管控问题、弱网环境下的边缘自治的问题。 混合调度&交融生产接下来次要讲一下第二个问题。方才讲边缘的机房很少，当然行业的解决方案也很多，有很多采纳分池的计划，咱们整体的技术架构都是基于Kubernetes来设计的。因为咱们须要达到高密生产，就是须要在一台机器上间接去交融生产容器和虚机。第二个，咱们须要在调度层面交融去调度容器和虚机。先讲第一个问题，咱们怎么去解决在一台服务器上交融去生产容器和虚机，同时在底层的网络和存储能力上是可能对立应用的。因为咱们整体的设计方案都是依照超交融这样的技术计划去设计。在虚机场景下，原生的Kubernetes是没法生产虚机的，咱们这里是引入了kubevirt这样一个技术架构。kubevirt这个技术架构外面，它是能够通过kubelet这样一个计划去拉起客户的虚机，这样咱们就能够把虚机的生产纳入到整个Kubernetes的体系外面。 第二个在容器场景，咱们须要在一台机上混合生产容器和虚机，就要解决一个平安的问题。在这外面咱们采纳的是平安容器的计划。平安容器当初倒退是比拟成熟的，就是间接基于Kubernetes能够生产。底层像咱们自研的VPC、基于DPDK自研的EVS网络、基于Ceph的块存储，或者基于SPDK的本地盘，因为平安容器和虚拟机底层采纳是对立虚拟化计划，所以咱们Iaas层的存储和网络能力是能够对立复用的。两种计算状态，像虚机和容器，底层的技术计划、实现体系是统一的，这里齐全能够进行复用，这样就能够达到咱们在一台物理机上去混合生产容器、虚机这样的能力。 当咱们达到了混合生产虚机和容器的技术能力之后，其实也面临着另外一个问题。举个例子，比如说我在广东电信1这个节点上，我总共就有10000核vcpu，这时候来了一个虚机大客户，他要8000核vcpu，来了一个容器客户，他要5000核vcpu，这个时候必然就会超过整个kubernetes能够调度的资源，其实就是超过了咱们整个资源的售卖状况。在这种状况下，如果间接调度到边缘的kubernetes集群，其实会呈现很多客户的虚机或者很多客户的容器呈现大量生产失败的状况。在这个状况下，咱们针对大客户，提出资源需要比拟多的时候，其实咱们在核心层面是做了对立调度的，咱们叫全局布局调度。 怎么去了解这个事件呢？当咱们要在某个IDC机房去给某个客户扩容资源的时候，咱们在调度体系外面能够通过肯定的资源经营策略来实现这样一个能力，咱们叫资源预占的计划。当这个节点，虚机须要8000核vcpu，然而客户又不肯定立马部署。在这个时候，在整个资源调度，在生产之前，就会针对这个节点把库存进行预占，咱们叫预占的计划。这个时候容器有一个客户来进行生产的时候，因为资源在核心层面曾经被预占掉了，所以说这个时候就会反馈失败，这样就能够解决当一个节点同时生产虚机和容器，资源没有做布局之前，导致大量客户生产失败的状况。咱们这个计划叫基于全局维度的资源预占。 利用生命周期治理除了方才解决问题之外，咱们面临另外一个问题，很多客户从核心部署到边缘的时候，其实是没有边缘的运维能力的。比如说咱们之前接了一些HttpDns的服务或者函数的场景，因为他们之前都是基于核心服务去部署的，只须要去治理一个Region或者两个Region，然而边缘的节点太多了，让客户间接去下沉保护，其实保护的复杂度十分高。另外因为边缘不同的机房，在能力上会存在肯定的差别，因为不同的机房服务器数目不一样，有的机房可能提供失常的7层LB，有的可能不提供7层LB，其实这个规范能力是不一样的，包含有的机房可能提供本地盘，有的机房只提供云盘。 因为咱们没法像核心那样每个机房都提供全套规范云产品能力，这种情景对于客户的运维复杂度是十分高的。就算他的业务想下沉边缘，对他原生的业务零碎革新也是十分大的。所以在这外面，客户就心愿咱们可能把边缘的资源这些能力进行一个高度的形象，他不须要去感知底层的差别，产品层面能够对立解决像边缘利用编排、针对集群的公布、针对集群的版本治理等问题。 在这个外面，咱们首先讲第一个，咱们怎么去解决利用的多功能编排以及利用的版本治理呢？针对不同的集群去治理客户不同的版本。这外面IDC1，客户须要公布V1.0.1版本，同时在IDC1上必定只提供了本地盘，在IDC2上提供了云盘，客户可能只有存储需要，他不想感知这些差别，同时客户又须要配套的LB、负载平衡的能力，甚至包含肯定服务发现能力。 这个外面咱们次要是引入了两层形象的概念。第一个叫利用集群，一个叫利用，就是咱们整体一个利用编排的体系设计是基于这两个维度在设计的，在利用集群外面有几个要害的语义，就是把咱们云产品的能力会交融到利用集群形容的语义外面。比如说网络的LB、ALB、Nat、PIP、存储的本地盘、云盘等，包含算力规格，针对集群级别，咱们形象进去了一个叫利用集群的概念。这个利用集群外面会把这些网络和存储能力交融进去。 这样的话，咱们针对于IDC1和IDC2做利用生产的时候，其实是打包生产的模式，当咱们要部署到IDC1的时候，咱们会把客户配套须要的LB、Workload、存储，对立会下发上来，而后在边缘IDC1上再进行真正的一个基于Kubernetes的生产，生产Pod的同时，而后把LB的配置生产进去，把存储的配置给它生产进去。 在这一层次要是在PaaS层实现。第二层形象，咱们叫利用(Application)。客户只须要针对利用去配置他的LB、配置他的Workload、配置他的EIP、配置他的存储。这样的话，当客户须要部署到IDC1、IDC2的时候，这个时候客户只须要在利用形容他针对于网络存储以及本人利用的形容。形容之后，咱们整个PaaS调度就会针对咱们的利用集群去打包部署到IDC1、IDC2，这样客户就不须要感知到底层不同网络、不同存储的状况。同时针对这个架构，咱们就能够实现客户针对不同集群的版本治理能力。比方刚刚讲的客户在利用外面就能够去形容，我须要在IDC1外面部署V1.0.1版本，我要在IDC2外面部署V1.0.2版本。当咱们PaaS平台打包部署到IDC1和IDC2的时候，这个时候咱们就会感知客户到抉择的对应版本，而后去部署对应的版本。通过这样一个利用集群以及面向客户的利用的设计概念，咱们解决了客户多集群的部署以及版本治理的问题。 其实还会面临另外一个问题，就是说很多客户业务部署到边缘的时候，不止有一个利用，会面临什么问题？其实他会部署多个利用，客户须要部署一个日志服务，同时要部署一个计算服务，还要部署一个监控服务。它只有多个服务同时在一个IDC上生产进去之后，才能够真正对外提供服务，这个叫多利用的编排。 在多利用的编排场景下，咱们这里引入了一个新的设计思路，叫主从利用的思路。当客户要抉择多利用编排的时候，他须要去抉择一个主利用(master application)，当客户创立实现多个子利用之后，在部署之前须要去配置哪些子利用和主利用去绑定。在这个时候咱们整个PaaS调度体系外面就会去感知到这样的主利用跟子利用之间的绑定关系，在资源调度和业务部署的时候就会依照客户的绑定关系进行整体的一个资源调度以及整体利用的部署。 同时针对刚刚讲的，咱们基于利用集群，客户能够配置部署的版本，基于利用集群的版本治理也能够同时实现客户就算在多个利用绑定部署的状况下，也能够去实现不同的利用在不同的集群，部署不同的版本。次要就是通过利用集群、利用和主从利用，在咱们设计外面引入这样的几个设计思路，最终可能解决客户在应用边缘算力资源的时候面临的版本治理、利用治理的问题。 稳定性体系建设最初，给大家讲一下咱们整个边缘容器平台在稳定性上是怎么去设计和落地的。 稳定性设计次要是三块，监控、告警，还有当平台发现客户的业务呈现问题的时候，咱们要可能熔断。在监控、告警上，跟通用的Kubernetes计划差不多，咱们也是将边缘托管Kubernets集群以及边缘的kubernetes集群，像事件、一些日志、指标对立都收集到核心，再去构建咱们整个监控大盘，再基于咱们本人的告警核心，当发现客户的异样指标的时候，进行业务告警。比如说客户某个要害的网络资源被删除掉了，客户本人的利用被删除掉了，咱们会触发一些告警。 重点讲一下咱们的整个风控。什么叫风控呢？咱们做风控的实质起因，是因为很多客户上容器平台的时候，之前客户在虚机的运维模式下或者裸机的运维模式下不会面临虚机资源被批量删除的问题，因为是比较稳定的IaaS资源，它是不会呈现批量开释、批量销毁、批量宕机的状况的。然而当客户去应用容器的场景下，可能因为客户本人的误操作，或者容器平台本身的一些问题，导致客户的容器或者一些要害的资源被谬误的批量删除掉。 咱们为了解决这个问题，引入了一个风控熔断的设计思路。咱们这里实现的计划就是基于Kubernetes的webhook。基于webhook的这个架构体系进行设计的，把客户的事件进行对立的收集和解决，在策略层面，咱们引入了两个策略，一个叫动态策略，一个叫动静策略。动态策略比较简单，就是针对一些大客户或者一些要害的，比方像网络、存储，咱们会进入封禁，当发现客户做了这样一些删除操作，或者咱们本人的零碎呈现问题了，在执行删除之前，咱们会间接熔断，或者客户做了删除，咱们会间接给他返回失败，这样客户的操作就会失败，这时候客户就不会因为误操作呈现规模故障。 第二个工夫维度的，咱们叫动静策略。动静策略次要是做了基于工夫维度的管控策略。最终实现的成果就是客户能够配过来的某一个时间段，客户的容器或者某个要害的资源不容许被删除，比方客户配置过来5分钟不容许删除超过100个Pod，如果产生了超过100个Pod被删除的状况，就认为是客户本人误操作或者平台本身呈现了问题，这个时候容器平台就会被动触发熔断，并且触发告警，从而解决客户规模故障的问题。 03 边缘容器的利用摸索与实际讲了咱们整个稳定性计划之后，接下来重点给大家讲一下咱们在边缘的场景下，咱们怎么去落地的，有哪些典型的案例。 ...

Photo by Elaine Casap on Unsplash本文核心内容整顿自 Brian Holt 的 workshop 《Complete-Intro-Containers》 。与 Docker 相似的容器技术并不是操作系统与生俱来的能力，而是通过组合一些 Linux 个性，实现过程组隔离的一种技术。 本篇文章将从介绍容器技术的倒退开始，进而阐明哪些 Linux 个性组成了容器技术的外围局部。心愿您可能借由浏览本篇文章，对 Docker 等容器技术有更粗浅的意识。 1. 为什么咱们须要容器容器技术并不是凭空出现的，它起源自时代倒退中人们对于如何更高效地利用计算机资源的思考和工程实际，在本章中，我将遍历容器技术呈现之前的各时代，帮忙您了解容器技术到底解决了什么样的问题。 1.1 裸机时代互联网服务晚期，想要架设 Web 服务器，就须要租用某个中央的服务器设施，运行程序代码。只有有短缺且称职的人员保护，就能最大限度的施展服务器性能。 裸机时代的问题在于扩大服务极度不足灵活性：如果想要增加设施，就须要找服务器供应商（Dell 或 IBM）购买新的物理设施，并指派业余人员进行装置，调试，启动，这大略须要一两个月的工夫。 并且，当部署好一个服务器集群，操作系统与驱动的降级，硬件的替换与培修，网络问题的修复，线材的整顿，机房管理权限的设置，数据中心温度的管制以及电费与 IPS 费用的领取...等等这些都须要业余的团队去解决。 1.2 虚拟机时代于是咱们进入了虚拟机时代，虚拟机是介于用户与硬件设施之间的一层形象。一开始，相较于裸机时代，一台计算机服务于繁多的用户主体，当初一台计算机容许多个用户主体登录，应用计算资源运行彼此的服务。只有设施性能短缺，用户便能够在须要时疾速增加新服务。这使得咱们取得了一些服务扩大的灵活性。 但在这种模式下存在着一些问题： 任何用户都有权限获取其余用户服务存储的数据；用户能够通过投放 Fork Bomb（见下方阐明） 的形式，掠夺服务器资源；一台物理设施上的任何租户都可能无意间使整个服务器解体；为了解决这一问题，呈现了虚拟机技术：即当用户创立服务时，在计算机的主操作系统上装置新的操作系统调度硬件资源以达成数据隔离的指标。并且当一个服务解体时，最多导致服务所属的操作系统解体，服务器设施上的其余租户将不受影响。 虚拟机技术的弊病在于在主操作系统中运行其余操作系统所带来的性能损耗。但只有计算机领有短缺的算力和内存，这些性能损耗都能够被承受。 Fork Bomb 是一种通过一直生成子过程，以达到占用大量系统资源的目标，从而导致系统无奈失常工作，甚至进行响应的攻打伎俩。它通常通过在操作系统中创立大量过程，以耗费零碎内存和处理器资源，并导致系统解体。1.3 私有云时代通过 Microsoft Azure，Amazon Web Services 或阿里云等私有云服务提供商提供的虚拟机服务，用户不再须要治理低廉且简单的数据中心，只须要治理本人的应用程序。云服务厂商尽管不会帮忙用户更新操作系统，然而会定期更新服务器设施。 但在这种模式下，虚拟机提供商向用户提供的，实质上依然是计算机的硬件设施（CPU 和内存），用户依然须要领取调度，保护整个操作系统的开销（例如网络管理，装置与更新软件等），这又须要业余的技术人员负责。 如果可能帮忙用户节俭掉保护操作系统的开销，让应用程序间接运行，那就太棒了。这种需要催生了下个时代的到来。 1.4 容器时代容器技术为用户提供了许多虚拟机平安和资源管理的性能，但节俭掉了运行整个操作系统的老本。它通过以下三个 Linux 命令胜利将过程组之间彼此隔离： chroot：实现目录级别的资源隔离；unshare：实现过程级别的资源隔离；cgroup：限度隔离环境中可调度的资源大小；上面咱们将具体介绍这三个命令。 2. 实现容器技术的三个要害 Linux 命令2.1 chroot命令chroot 是一个 Linux 命令，容许为一个新过程创立根目录。当为一个容器设置一个新目录后，容器内的过程将无法访问到任何根目录外的数据，这就打消了数据泄露的安全隐患。 运行以下命令开始实际： docker run -it --name docker-host --rm --privileged ubuntu:bionic命令解析： ...

本文译自 Avoiding CPU Throttling in a Containerized Environment。作者：Joakim Recht和Yury Vostrikov在 Uber，所有有状态的工作负载都运行在一个跨大型主机的通用容器化平台上。有状态的工作负载包含MySQL®、Apache Cassandra®、ElasticSearch®、Apache Kafka®、Apache HDFS™、Redis™、Docstore、Schemaless等，在很多状况下，这些工作负载位于同一台物理主机上。 凭借 65,000 个物理主机、240 万个内核和 200,000 个容器，进步利用率以降低成本是一项重要且继续的工作。但最近，因为 CPU限流，导致利用率晋升这件事没有那么顺利了。 事实证明，问题在于 Linux 内核如何为过程运行调配工夫。在这篇文章中，咱们将形容从 CPU 配额切换到cpusets（也称为 CPU pinning），如何使咱们可能以 P50 提早的轻微减少换取 P99 提早的显著降落。因为资源需要的变动较小，这反过来又使咱们可能将整个集群范畴内的外围调配缩小 11%。 Cgroups、配额和 CpusetsCPU 配额和 cpusets 是Linux内核的调度器性能。Linux内核通过cgroups实现资源隔离，所有容器平台均以此为根底。通常，一个容器映射到一个 cgroup，它管制着在容器中运行的任何过程的资源。 有两种类型的 cgroup（Linux 术语中的控制器）用于执行 CPU 隔离：CPU和cpuset 。它们都管制容许一组过程应用多少 CPU，但有两种不同的形式：别离通过 CPU 工夫配额和 CPU pinning。 CPU 配额CPU控制器应用配额来实现隔离。对于一个CPU 集，你指定要容许的 CPU 比例（外围）。应用以下公式将其转换为给定时间段（通常为 100 毫秒）的配额： 配额 = core_count 周期（quota = core_count period) 在下面的例子中，有一个须要 2 个内核的容器，这相当于每周期须要 200 毫秒的 CPU 工夫。 ...

6月30日-7月2日，由中国电子技术标准化研究院主办、全国信标委云计算规范工作组、云计算规范与利用工业和信息化部重点实验室承办的第十一届中国云计算规范和利用大会在京召开。本次大会共开设了“智能云、云原生、企业上云、超交融、边缘云、云迁徙”共六大分论坛，齐聚产学研用多方专家，独特探讨云计算产业倒退方向和将来时机，展现云计算标准化工作成绩。 在“边缘云”分论坛上，阿里云智能边缘云技术专家肖源分享了《容器技术在大规模边缘场景下的商业实际》主题演讲，本文为整顿内容。 边缘云介绍边缘云的状态和价值以后客户面临多方面的挑战，例如自建交付周期长、资产重，边缘集群常态化裁撤、割接导致SLA难保障，单集群规模小、业务弹性差，属地性利用多导致集群保护老本高、难度大等等。边缘云面对以上挑战可能充分发挥对应价值：通过秒级算力交付实现效率晋升；边缘资源按量付费、弹性扩容降低成本；采纳云原生交付形式升高运维投入；提供海量资源、实现宽泛笼罩打造低时延、晋升用户体验。总的来说以后客户需要次要聚焦在两类场景： 云端算力下沉：原本在核心的零碎和利用下沉到边缘，能够无效升高到拜访核心的带宽老本，同时缩短业务拜访时延，终端算力上移：通过将散布在端上的算力上移到边，晋升业务的灵活性和可用的算力范畴阿里云边缘云根底能力 最上层的垂直场景为边缘云应用服务，包含了智慧城市、车联网、智能制作、场景互动、图像处理、内容散发、AR/VR、人脸识别等； 第二层边缘能力开放平台次要提供行业撑持服务，包含了固网交融、边缘云原生能力、框架与工具链、IoT服务、工业服务、电信网元服务等； 第三层是边缘通用平台服务，涵盖了容器云核心技术，包含EdgeMesh、利用治理、DevOps、可观测性、大数据、边缘AI； 中间层负责云端对立管控，实现容器云平台的资源纳管工作，包含分布式多云交融管控、全域交融调度、边缘资源对立管控、边缘镜像服务； 上层为计算、存储、网络、平安、节点自治等局部，例如对于边缘异构场景、边缘弱网环境等，阿里云边缘云通过自研网络计划与共享存储计划来应答解决； 底层为边缘云基础设施，包含分布式IDC、多云交融、一体机、MEC、边缘网关等局部。 阿里云边缘云技术特点异构交融广覆盖：提供异构分布式云网交融资源底座规范云原生兼容：反对现有云原生利用生态云边体验一致性：全域资源对立交付，保障云边应用体验一致性算力全域流动性：基于GSLB对立接入层的全域算力流量调度 聚焦边缘云容器平台技术边缘云容器平台的技术挑战边缘容器云平台面临的技术挑战次要是以下三个方面：集群小而多：整体体现为集群小而多的状态，资源管控、调度都会面临较大的挑战。环境简单：边缘设施环境与数据中心环境相比较为顽劣，存在弱网、断网等一系列问题，给云边、边边协同能力带来较大的挑战。异构：出于老本、业务非凡需要等起因，计算、网络、存储等方面在边缘环境下都存在着异构的状况，给云化纳管带来较大挑战。 边缘云容器平台技术架构 最上层为边缘能力凋谢层，包含OpenAPI、工具链、能力开放平台； 中间层为边缘云平台服务，最要害的就是边缘利用治理模块，用于实现利用部署和资源调度，在客户提出算力需要后，边缘云服务平台通过边缘交融调度来帮忙客户申请资源或是抉择部署节点。通过利用K8S集群治理形式，联合边缘工作负载、镜像服务和服务网格、云边协同通道等模块，独特提供稳固的边缘云容器服务； 最底层为边缘云基础设施，资源建设和运维平台的根底上，边缘云构建了异构资源的云化纳管能力，向下管控和接入不同类型的资源，为下层边缘云平台服务所用。 基于“核心-边缘”实现利用的劣势 基于“核心-边缘”实现利用的劣势次要体现在以下三个方面： 分布式部署形式，有效应对高并发，卸载核心服务器负荷；流量边缘收敛，应答大带宽，带宽老本升高30%；边缘就近解决，边缘侧延时管制在10ms以内。商业实际案例介绍随着边缘云越来越被社区、被各种产业参与方从新熟识，同时云网边端架构的遍及与算力需要一直的精细化。大家开始从新扫视和找寻更优雅更正当的架构模式。更多的场景开始推动”云端算力下沉，终端算力上移“的策略。以谋求老本、效率、灵活性方面的最优化，接下来为大家介绍利用边缘云容器平台两个典型的商业实际案例。 云游戏产品实际案例背景云游戏概念近几年异军突起，阿里云边缘云游戏产品则将概念转换为产品进行了落地实际，基于边缘容器云技术底座，为客户交付高质量且稳固的云游戏实例。 价值对立管控：从上层的ARM阵列服务器到下层容器利用均通过容器云平台进行管控，全流程服务保障，确保云游戏实例高效率生产；标准化交付：基于边缘容器利用治理能力，通过容器化形式打包所有云游戏实例运行时以及配置依赖，以规范容器利用形式交付，进步交付效率；降本提效：通过容器利用实例编排能力，繁多板卡运行多个安卓容器，晋升效率升高资源老本。 云游戏产品场景流程如下图所示： 云游戏场景核心技术点异构资源纳管 ARM阵列接入/运维/管控依据集群水位，网络品质等指标实现智能接入边缘利用治理 自研workload，反对pod/node纬度独立管控多集群治理&交融调度 多租隔离实例漂移/智能容灾基于ARM环境的自研容器网络&容器存储流量计算产品实际案例背景流量计算产品是阿里云边缘容器云的一个典型落地案例，对CDN产品退出了可编程的能力，从而容许客户在全网流量散发的根底上应用全网算力资源，在就近地位接入计算服务，最大化施展流量的业务价值。 价值加强流量价值：在传统流量散发业务上减少算力散发能力，加强业务流量价值；边缘计算典型场景：基于阿里云海量边缘算力，在任意地位随用随取，加重终端压力；大数据及AI：在大流量大数据场景下提供了可编程能力，为大数据及AI计算提供根底。流量计算产品场景流程如下图所示： 流量计算场景核心技术点边缘服务网格 服务发现/服务编排智能路由/多协定接入中间件服务化（DAPR）边缘容器网络 网络多租隔离/智能策略计量计费/流量管制

本文来自：玩火的容器内存管制 CGroup - 容器根底拾遗 Part 1 。如图片不清，请回到原文。 引 咱们在谈容器内存时，到底在谈什么？CGroup 内存阐明 根底概念 Pageanonymous pagesLRU listLRU list 组CGroup 概述 主记账范畴内核内存记账范畴内存回收状态文件 memory.statmemory.usage_in_bytesmemory.numa_statmemory.failcnt管制与事件告诉 强制回收内存基于内存阈值水位的告诉不要 OOM Kill，只是暂停监控与指标 常被误会的 K8s 指标 container_memory_usage_bytescontainer_memory_working_set_byteskubectl top什么 metric 才是 OOM Kill 相干内存限度对 IO 性能的影响理解内核数据结构Page Cache 占用剖析工具上文未提到的有用的参考引容器内存限度是个矛盾而重要的抉择，给多了浪费资源，给少了服务随机解体。 CGroup 内存管制是容器资源管制的外围。她是个法则严明的看守者，在利用超限时狠心地 OOM Klll。她同时也有宽容的一面，在利用资源有余时，调配和开释 Cache 给利用应用。而其心田的记账算法却回味无穷。要察看和监控她的状态和行为，更是千条万绪。本文尝试用作剖析和梳理。 看完下面的看守者的比喻，如果你想到身边的那位，就与我无关了。在去年，我写了一篇：《把大象装入货柜里——Java容器内存拆解》其中简略提到了 CGroup 内存管制 和 Java 的关系。而最近在工作上又遇到到容器的内存问题，于是想比拟深刻和系统地去理解一下这个天坑。每个做容器化（上云）都必须面对，但最想回避的大坑。 咱们在谈容器内存时，到底在谈什么？先列几个问题： 容器内存应用，只是过程用户态应用的内存？如果是，包含哪些？如果包含内核态的内存，有哪些内核态内存？所有内存都是强占用的吗？还是能够由内核必要时伸缩和开释？在监控到个别指标靠近甚至超过下限时，肯定会 OOM Kill 吗？本文尝试剖析下面问题，<mark>并挖掘 CGroup 背地鲜为人知的秘技 ✨ 帮忙准确剖析 OOM Kill 问题</mark>。同时说说容器内存的估算与监控上的坑。 CGroup 内存阐明根底概念根底概念这一节有点干燥和 TL;DR，不喜可跳过。 Page操作系统为进步治理内存的效率，是以 Page 为单位治理内存的，个别一个 Page 是 4kb： ...

本文将分为3局部解释docker的概念，原理，和docker起步快的起因 docker的概念 Docker是一个开源的应用程序容器引擎，它容许开发人员将他们的应用程序和依赖包打包到一个可移植的容器中，而后公布到任何风行的Linux机器上，并且还实现了虚拟化。容器是齐全沙箱化的，它们之间没有接口。 Docker技术的三个外围概念是图像、容器和仓库。 Docker起步快的起因，为什么Docker很轻？ 置信你会有这样的纳闷：为什么Docker起步快？如何与主机共享内核？ 当咱们要求Docker运行容器时，Docker会在计算机上设置一个资源隔离环境。而后，打包的应用程序和相干文件被复制到Namespace中的文件系统，环境的配置就实现了。之后，Docker将执行咱们预先指定的命令并运行应用程序。 图像不蕴含任何动态数据，其内容在构建后不会扭转。 Docker的外围概念 1.建造、装运和运行(建造、运输和运行)； 2.一次构建，随处运行(一次构建，随处运行)； 3.Docker自身不是一个容器，它是一个创立容器的工具和一个应用程序容器引擎； 4.Docker有：镜像、容器和仓库存储库； 5.Docker技术应用Linux内核和内核函数(如Cgroups和名称空间)来拆散过程，这样每个过程就能够彼此独立运行。 6.因为Namespace和Cgroups函数只在Linux上可用，所以容器不能在其余操作系统上运行。那么Docker是如何在macOS或者Windows上运行的呢？Docker实际上应用了一个技巧，在非Linux操作系统上装置Linux虚拟机，而后在虚拟机中运行容器。 7.映像是一个可执行包，其中蕴含运行应用程序所需的代码、运行时、库、环境变量和配置文件，容器是映像的运行时实例。 对于Docker原理的更多信息，能够查看灵雀云的技术博客

作者魏后民，腾讯云后盾开发工程师，关注容器、Kubernetes、Cilium等开源社区，负责腾讯云 TKE 混合云容器网络等相干工作。 赵奇圆，腾讯云高级工程师，次要负责腾讯云容器网络设计和研发工作。 前言混合云 并不是一个陈腐的概念，但随着容器技术的倒退，混合云与容器的联合正在失去越来越多的关注。通过容器等云原生技术，能够屏蔽混合云异构集群底层计算资源基础设施的差别，实现多云场景、IDC 场景乃至边缘等场景的对立。混合云将不再是私有云和公有云的简略联合，而是计算负载无处不在的分布式云，能够充分发挥其在资源扩容、多活容灾、多集群混合部署等场景的劣势。 腾讯云 TKE 容器服务推出私有星散群增加第三方 IDC 计算节点服务，该服务能够让客户复用 IDC 计算资源，免去在本地搭建、运维 Kubernetes 集群的老本，最大化进步计算资源使用率。 在这个计划的底层实现中，买通 IDC 和私有云之间的网络是重要的一环。一个 Kubernetes 集群中可能蕴含泛滥不同网络环境的计算节点，比方 IDC 网络环境和私有云 VPC 网络环境的计算节点。为了屏蔽底层不同网络环境的差别，TKE 提出了混合云容器网络计划，在容器层面看到的是对立的网络立体，使得 Pod 无需感知其是运行在 IDC 的计算节点还是私有云的计算节点。 TKE 混合云容器网络同时反对基于 VxLAN 隧道模式的 Overlay 网络和基于间接路由的 Underlay 网络。当客户不心愿扭转其 IDC 根底网络设施时，能够应用 Overlay 网络；当客户对于混合云容器网络的性能有很高的要求时，能够应用基于间接路由的 Underlay 网络。本文将详述混合云中容器网络面临的挑战与解决方案，并介绍 TKE 混合云容器 Overlay 网络的实现。接下来还会有文章独自介绍 TKE 混合云容器 Underlay 网络的实现，敬请期待。 混合云容器网络面临的挑战在混合云场景下，一个 Kubernetes 集群的各个组件可能散布在不同的网络立体： Master Network：运行着 ApiServer 等管制面组件的网络立体VPC Network：蕴含有 TKE 私有星散群计算节点的网络立体IDC Network：蕴含有客户 IDC 计算节点的网络立体混合云简单的场景下，如何买通不同网络立体的链路，对容器网络设计提出了挑战： VPC Network 和 IDC Network 相互拜访混合云场景下，一个 Kubernetes 集群可能既蕴含 VPC Network 下的私有云计算节点，也蕴含 IDC Network 下的计算节点。买通这些处于不同网络环境下的节点网络，是下层容器网络互通的根底。 ...

家喻户晓，K8S的POD是不须要固定IP的，因为固定IP 会带来一些扩展性的问题，然而动态IP在平安ACL，业务管制方面有不少独到的长处，本文就是在揭示新也云如何在K8S上实现动态IP这个能力的。全方面满足业务须要。 一、Kubernetes 网络接口CNI插件的工作原理首先从Kubernetes网络接口(CNI) 说起，containernetworking/cni: Container Network Interface - networking for Linux containers (github.com) CNI（Container Network Interface）是 CNCF 旗下的一个我的项目，由一组用于配置 Linux 容器的网络接口的标准和库组成，同时还蕴含了一些插件。CNI 仅关怀容器创立时的网络调配，和当容器被删除时开释网络资源。 CNI 插件就是一个执行程序，容器启动时，它被调用，而后返回一个规范的JSON，通知容器该怎么设置本人的网络。 同样被销毁的时候，它也被调用一次，返回一个JSON，通知容器如何销毁本人的网络。这就是CNI 插件的工作形式。所以咱们须要做的就是理解CNI插件的工作。 二、CNI插件接口办法CNI插件的接口办法个别包含: ADD CHECK DEL VERSION 理论应用中，将一个容器增加进一个网络，调用的是ADD接口办法。将一个容器从网络中删除，则是调用DEL接口办法 在 plugins/plugins/main/macvlan at master · containernetworking/plugins (github.com) 我的项目 咱们能找到很多CNI 插件的源码，咱们只须要简略的批改一下就能够了。 三、原理透析默认装置插件后，简略关上CNI的配置 /etc/cni/net.d 咱们能大略看到这样的配置文件。 这里调配了 这台物理机上能够应用的IP段，IP分配模式等等信息。这些配置管制了Macvlan插件的工作。工作的时候，这个配置会作为参数被传入插件，从这里咱们会发现，咱们将应用host-local 模式调配IP。 通过浏览代码，咱们能够大略理解到默认的工作模式是这样 一台物理机上能够调配的IP 被寄存在本地文件里的，每次启动容器的时候，咱们就从文件里选一个，这样大家并不会抵触。然而这有个前提 那就是每台物理机上的IP都是互相隔离的，这样才不会抵触。如果要做动态IP， 这意味着随着调度算法的调配，一个IP可能呈现在不同的物理机上？这样的话，咱们怎么解决抵触呢？ 咱们解决的方法是把IP 调配中心化，将IP的调配放到 公布零碎里，这样的话，咱们就能够让任何一个容器都能有咱们想让它领有的IP。大略的流程 是这样， 从流程上看，咱们把IP调配这个局部的性能从各个节点，自主调配的模式，收口到了 公布零碎上，这样能做到对立治理，非常灵活。 在代码上看就很简略了，Macvlan 的插件是Go 语言所写，咱们只须要简略加一个利用Http Client 代码，用它去获取容器的标签就能够了。咱们曾经把这部分开源啦。请间接去 https://github.com/ppdaicorp/... 看看吧。 ...

-本文转自@TWT社区。【前言】至多，以Docker和kubernetes为代表的容器技术突飞猛进，但咱们在容器的应用过程中，也会碰到各种损坏和难题。出有针对性的阐明和解决方案，心愿能够帮忙到大家去疾速定位和解决相似问题故障。具备超过十年的互联网运维及五年以上团队治理教训，多年容器云的运维，尤其是在Docker和kubernetes畛域十分精通。 Docker是一种绝对应用较简略的容器，咱们能够通过以下几种形式获取信息：1，通过docker run执行命令，或者返回信息2，通过docker logs去获取日志，做有针对性的筛选3，通过systemctl status docker查看docker服务状态4，通过journalctl -u docker.service查看日志以下是整顿的docker容器类问题故障，分为9个类 一，启动类故障1，docker：无奈通过unix：///var/run/docker.sock连贯到Docker守护程序。泊坞窗守护程序正在运行吗？起因：Docker未失常启动解决形式：systemctl启动docker2，无奈创立Unix套接字/var/run/docker.sock：是目录起因：docker.sock不能创立解决形式：rm -rf /var/run/docker.sock而后重新启动docker3，docker.service的作业失败。无奈启动Docker应用程序 起因：Selinux引起解决形式：/ etc / sysconfig / selinux，将selinux值替换为禁用重启docker解决4，泊坞窗：来自守护程序的谬误响应：/ var / lib / docker / overlay / XXXXXXXXXXXXXXXXXXXXXXXXXX：无此类文件或目录。起因：docker没有指定目录或文件解决形式：systemctl进行dockerrm -rf / var / lib / docker / *systemctl启动docker重启run重新启动容器5，泊坞窗：来自守护程序的谬误响应：抵触。容器名称“ XXX”已被容器“ XXX”应用。您必须删除（或重命名）该容器能力重用该名称。起因：码头工人名字重名解决形式：改名容器或者删除重建容器6，谬误：连贯激活失败：找不到适宜此连贯的设施起因：网卡配置问题解决形式：重启网卡7，零碎重启后docker无奈启动报错为：docker0：iptables：该名称没有链/指标/匹配起因：docker服务iptables问题解决形式：重启docker服务零碎重启docker8，启动守护程序时出错：初始化graphdriver时出错：不反对驱动程序应用overlay2存储驱动启动docker daemon报错起因：daemon经济配置解决形式：增加配置：/etc/docker/daemon.json{“存储驱动器”：“ overlay2”，“存储选项”：[“ overlay2.override_kernel_check = true”]}9，无奈启动docker.service：单位docker.service被屏蔽。未知起因：docker被遮罩解决形式：systemctl勾销屏蔽docker.servicesystemctl勾销屏蔽docker.socketsystemctl启动docker.service10，无奈启动docker.service：单元未正确加载：参数有效。 未知起因：docker服务无奈失常加载解决形式：卸载docker，删除docker.service重新安装docker11，docker-compose启动容器时报错：/usr/lib/python2.7/site-packages/requests/init.py:80：RequestsDependencyWarning：urllib3（1.22）或chardet（2.2.1）与反对的版本不匹配！RequestsDependencyWarning）未知起因：pip相应组件版本不反对解决形式：pip卸载urllib3pip卸载chardet点装置申请12，docker容器重启故障强杀docker过程后，重启docker。docker中的容器无奈启动并报错docker restart XXXXXXX来自守护程序的谬误响应：无奈重新启动容器XXXXXXX：容器“ XXXXXXXXXXXXXXXX”：已存在起因：旧容器未平安退出解决形式：docker-containerd-ctr --address /run/docker/containerd/docker-containerd.sock --namespace c rm <容器hash_id>码头工人开始容器13，docker重启谬误-重启命令始终卡住systemctl重新启动docker卡住未知起因：可能是启动的容器数量过多，或者磁盘IO问题解决形式：systemctl启动docker-cleanup.servicesystemctl启动docker 二，权限问题报错14，尝试连贯到unix：///var/run/docker.sock的Docker守护程序套接字时取得的权限被回绝解决形式：查看/var/run/docker.sock其中用户组将用户重新加入docker组中，usermod -aG docker $ {USER}15，在步骤GROUP中应用chown socket：没有此类过程 起因：docker无奈找到Group组信息，docker组有可能被误删除，解决形式：groupadd泊坞窗16，公布http：///var/run/docker.sock/v1.XXX / auth：拨打unix /var/run/docker.sock：权限被回绝。您是否要连贯到没有TLS的启用TLS的守护程序？起因：非Root用户治理Docker时，权限有余解决形式：groupadd泊坞窗usermod -a -G docker用户17，码头工人犯错误解决tar文件时出错（退出状态1）：意外的EOF起因：可能是权限问题引起解决形式：chmod + x加一个执行权限 三，总体和仓库问题报错18，获取https://registry-1.docker.io/...起因：Docker仓库无法访问解决形式：批改Docker仓库源为国内或者自建的仓库源批改/etc/docker/daemon.json19，推出本地可行性报错推送指向存储库[XXXX]获取https：// xxx / v1 / _ping：http：服务器向HTTPS客户端提供了HTTP响应起因：docker Registry未采纳https服务所致解决形式：/etc/docker/daemon.json文件写入：{“不平安的注册表”：[“”]}20，/ usr / bin / docker-current：来自守护程序的谬误响应：oci运行时谬误：container_linux.go：启动容器过程导致“ exec：\” / bin / bash \”：在$ PATH中找不到可执行文件”。起因：Docker自身的固有问题或Docker引擎版本比拟低导致解决形式：能够降级Docker版本服务21，精心设计，执行chown -R十分慢起因：Docker应用写时复制策略，所以chown命令执行时，将下层正本文件全副复制到以后层，而后再批改权限，再写入文件系统。解决形式：不应该应用chown -R类别大批量批改文件的命令22，docker build造就的的时候报错：来自syslogd内核的音讯：unregister_netdevice：期待lo开释。应用次数= 1起因：docker engine版本过高解决形式：docker引擎版本须要和docker外部附加的内核版本匹配23，泊坞窗：来自守护程序的谬误响应：容器：容器未在指定的超时之前启动。ERRO[0133]从守护程序获取事件的谬误：上下文已勾销起因：批改完docker root dir，重启后，下载多个报错解决形式：重启docker服务或者重启服务器 ...

5G将开启产业互联网改革的新篇章，推动5G交融利用倒退是业内共识。GTI最新公布的《5G智能化网络白皮书》强调，网络智能化是5G网络高效高质建设部署和经营不可或缺的能力。如何为用户提供更高质量、更有保障的通信服务，成为运营商乃至整个社会信息化倒退的重要课题。 5G核心网运维的新挑战5G核心网（_5G Core_）是电信运营商5G建设的重要组成部分，采纳全新技术，在实现网络部署、网络性能、新业务发展的同时，监控保障也面临全新挑战。在4G核心网（_EPC，Evolved Packet Core_）中，网元由专有设施承载，硬件属性较强。而在5G核心网环境中采纳基于服务架构（_SBA，Service Based Architecture_），融入云原生、微服务等设计思维， 以软件化，模块化、服务化的形式构建核心网。对于全新核心网的运维保障，面临如下挑战： 网络性能解耦使监控对象数量激增根据3GPP定义，5G核心网的各网络性能（_NF，Network Function_）在性能级别上解耦，拆分出若干个独立的网络性能服务(_NFS，Network Function Service_)，这些网络性能独立运行，提供标准化服务接口，通过互相调用拜访实现网络性能。在5G核心网计划中，虚拟化、云原生技术的融入，使通用服务器取代专有硬件设施，与此同时虚构网元，虚拟机、容器POD的数量飞速增长，每个工作负载同时提供多个IPv4、IPv6工作立体。 相较4G EPC，因为泛滥方面演进叠加在一起，在5G核心网SBA架构中虚拟化后的NFS实例数量以2个以上的数量级增长，须要监控的对象数量微小是5G核心网保障侧第一个挑战。 服务自动化减少了网络追踪的难度通过网络性能仓储(_NRF，NF Repository Function_)，5G 核心网的各类网络性能服务得以自动化治理，实现服务的主动发现以及注册、更新、状态检测等，防止服务拜访中进行大量手动配置工作；集中控制面能够将大量跨区域的信令交互变成数据中心外部流量，优化信令解决时延；依据业务利用的变动，按需疾速扩缩网络性能和服务，进步网络的业务响应速度。自动化治理在生产侧晋升了管理效率，同时在核心网保障侧减少了动态性强、难以跟踪的新挑战。 门路优化与交互解耦贬低了监控复杂度4G核心网的网元之间的通信遵循请求者和响应者的点对点模式，是一种互相耦合的传统模式。在 5G 核心网服务化架构下，各网络性能服务之间能够依据需要按需通信。5G 核心网架构下的网络性能服务间通信机制进一步解耦为生产者和消费者模式，具备灵便可编排、解耦、凋谢等长处，是 5G 时代迅速满足垂直行业需要的一个重要根底能力。各网络性能在理论利用过程中，防止了不必要的网络直达，但服务间的调用依赖，拜访追踪，性能剖析，故障定位等也成为运维保障侧的新挑战。 DeepFlow 5G核心网网络性能服务监控计划实际DeepFlow是一款面向5G核心网，基于对服务NFS间的通信拜访流量进行获取剖析，以保障核心网稳固运行的软件产品。在整体计划中，可按解决逻辑分为流量获取、数据散发传输、诊断剖析三大部分，通过流量采集预处理形象层，提供流量采集及预处理的北向治理接口，使整个监控平台具备可扩大的根底数据获取能力。 通常5G核心网环境中，次要波及到KVM虚拟机与容器POD的网络流量获取。DeepFlow 5G核心网网络性能服务监控计划反对IPv4、IPv6协定环境，紧密结合HTTP v2协定，实现服务间关联依赖监控。本文基于运营商理论5GC运行环境，化繁为简并以Free5GC环境为根底进行介绍。 What is free5GC?The free5GC is an open-source project for 5th generation (5G) mobile core networks. The ultimate goal of this project is to implement the 5G core network (5GC) defined in 3GPP Release 15 (R15) and beyond.Free5GC是5G核心网开源软件我的项目，总体架构基于3GPP规范、遵循SBA框架，采纳虚拟化形式实现网络性能，可运行5G核心网的规范服务，并且能够模仿相应工作流程。在理论5G环境中，少数厂商曾经采纳容器技术承载网络性能服务。在本文中，采纳虚拟机运行容器，创立Kubernetes集群， 搭建5G核心网验证环境，使能各网络性能。通过云杉网络的DeepFlow平台实现对各网络服务的监控保障。实际过程中部署的组件包含控制器、采集器以及数据节点。 由大到小追踪网络服务在5G核心网的监控实际中，由大到小，逐级有序地展现服务运行状态及关联关系。通常依据工作流程分为三大范畴，较大范畴以数据中心所属区域或资源池划分，其次为网络性能或服务类型，比方AMF、UDM、SMF等，最初将集中在IT单元，比方容器POD、宿主机、IP等。DeepFlow平台依照三类范畴由大到小的操作划分，为核心网所波及到的简单网络提供残缺的、逐级的监控跟踪。下图出现的是各类型网络性能服务运行及调用关系全景视图，将服务接口（_SBI，service-based interface_）中的网络各性能间的调用通信，以及性能指标进行主动绘制并出现。 ...

导语丨TKEStack 是腾讯开源的一款集强健性和易用性于一身的企业级容器编排引擎，是凋谢原子开源基金会的孵化我的项目之一。本文是对 TKEStack 开源我的项目负责人汝英哲、TKEStack 高级产品经理何鹏飞在云+社区沙龙online的分享整顿，介绍 TKEStack 的开源方法论，心愿与大家一起交换。点击此链接查看残缺直播回放~ 一、TKEStack 简介TKEStack 是腾讯云开源的容器平台，很多小伙伴们问：有了 Kuberentes 为何还要用 TKEStack？其实 Kuberentes 作为能力平台还有很多欠缺。比方它没有UI、镜像仓库、权限治理、日志、监控等根本运维能力，单把 Kuberentes 作为一个业务平台还是很薄弱的，而容器平台补齐了以上这些性能点，把 K8S 封装成了残缺的业务平台。 TKEStack 的开源历程腾讯很早就开始做容器相干的计算平台了。2009 年吴军博士从谷歌来到腾讯，便借鉴了谷歌做出了腾讯自研的业务平台 T-Borg。到了 2011~2013 年左右开始用社区成熟的公认的技术做业务平台。过后有一次重要的技术方向转变，转向应用业界支流技术计划后，Torca 转向专门做大数据业务平台，于是有了HOT（hadoop on torca）。到了 2014 年，Docker 技术也体现了威力，咱们十分看好 Docker、Kubernetes 技术，于是迅速进行了切换，并且着手开始做通用的业务平台。 2014 年也有了全新的产品 GaiaStack 用来反对腾讯外部业务，2019 年腾讯做了业务整合，有多条业务线的合并，Kuberentes 和私有云业务团队单干推出了 TKEStack 的容器平台，整合了 Kuberentes 的技术能力。Gaiastack和TKE的技术联合造成了 TKEStack 这个产品，并在 2019 年正式开源。 往年，又有一个十分重要的工夫节点，就是上个月 TKEStack 正式退出了凋谢原子开源基金会。 二、产品定位与方向1. 容器是云原生的事实底座在介绍整个产品的定位和方向之前，首先要提一下目前最炽热的技术方向 —— 云原生。 云原生是利用私有云、公有云和混合云构建和运行可拓展弹性的利用。容器基本上是整个云原生技术栈的底座角色，CNCF 官网来看容器族的产品中曾经有大量产品和厂商参加其中，基本上是百花齐放的态势。 泛滥产品中，真正耳熟能详的产品次要有两个，别离是 openshift 和 rancher，它们是容器开源界的标杆。 首先是红帽的 openshift，大家从 K8S 的代码奉献能够得悉，红帽 K8S 代码贡献率仅次于 google 排第二，技术能力十分强，产品也十分的欠缺，并且很早便开始做开源产品了。另一个是 rancher，往年被 suse 收买，产品体验十分好。 ...

简介： 云原生曾经成为业内云服务的一个趋势。在云原生上反对异构计算有助于晋升CPU的利用率。一文剖析业内支流GPU共享计划，并通知你阿里云cGPU牛在哪里！阿里云异构计算推出的cGPU（container GPU）容器技术，翻新地提出了一种不同于以往的GPU容器计划，克服了业内支流计划的一些常见的缺点，在保障性能的前提下，做到了容器之间的GPU显存隔离和工作隔离，为客户充分利用GPU硬件资源进行训练和推理提供的无效保障。 作者：阿里云异构计算高级技术专家 何旻 背景云原生曾经成为业内云服务的一个趋势。在云原生上反对异构计算，这个性能在规范的Docker上曾经能够很好的反对了。为了进一步提高GPU的利用率、防止算力节约，须要在单个GPU上能够运行多个容器，并且在多个容器间隔离GPU利用，这在规范的Docker上是无奈做到的。为了满足这一需要，业界也做了很多摸索。NVIDIA vGPU, NVIDIA MPS, 基于rCUDA的计划等，都为用户更小颗粒度的应用GPU提供了可能。 近日，阿里云异构计算推出的cGPU（container GPU）容器技术，翻新地提出了一种不同于以往的GPU容器计划，克服了业内支流计划的一些常见的缺点，在保障性能的前提下，做到了容器之间的GPU显存隔离和工作隔离，为客户充分利用GPU硬件资源进行训练和推理提供的无效保障。 业内罕用计划简介在介绍阿里云异构计算cGPU计算技术前，咱们先看看业内有哪些GPU共享计划吧： NVIDIA MPS NVIDIA MPS （NVIDIA Multi-Process Service）是NVIDIA公司为了进行GPU共享而推出的一套计划，由多个CUDA程序共享同一个GPU context，从而达到多个CUDA程序共享GPU的目标。同时，在Volta GPU上，用户也能够通过CUDA_MPS_ACTIVE_THREAD_PERCENTAGE变量设定每个CUDA程序占用的GPU算力的比例。 然而因为多个CUDA程序共享了同一个GPU context，这样引入的问题就是：当一个CUDA程序解体或者是触发GPU谬误的时候，其余所有CUDA程序的工作都无奈继续执行上来了，而这对于容器服务是灾难性的问题。 NVIDIA vGPU NVIDIA vGPU计划是GPU虚拟化的计划，能够对多用户的强GPU隔离计划。它次要利用于虚拟化平台中，每个vGPU的显存和算力都是固定的，无奈灵便配置；另外vGPU的应用须要额定从NVIDIA公司购买license，这里咱们就不再具体探讨。 rCUDA相似计划 业内还有一种罕用计划是通过替换CUDA库实现API层面的转发，而后通过批改显存调配，工作提交等API函数来达到多个容器共享GPU的目标。这种计划的毛病是须要对动态链接的程序从新编译，同时在CUDA库降级的时候也须要进行批改来适配新版本。 阿里云cGPU容器技术 阿里云异构计算GPU团队推出了cGPU计划，相比其余计划，这是一个颠覆性的翻新：通过一个内核驱动，为容器提供了虚构的GPU设施，从而实现了显存和算力的隔离；通过用户态轻量的运行库，来对容器内的虚构GPU设施进行配置。阿里云异构计算cGPU在做到算力调度与显存隔离的同时，也做到了无需替换CUDA动态库或动静库；无需从新编译CUDA利用；CUDA，cuDNN等版本随时降级无需适配等个性。 图1. cGPU容器架构图 cGPU内核驱动为一个自主研发的宿主机内核驱动。它的长处在于：• 适配开源规范的Kubernetes和NVIDIA Docker计划；• 用户侧通明。AI利用无需重编译，执行无需CUDA库替换；• 针对NVIDIA GPU设施的底层操作更加稳固和收敛；• 同时反对GPU的显存和算力隔离。 应用形式 1 利用阿里云容器服务 阿里云容器服务曾经反对cGPU容器组件了，通过登录容器服务 Kubernetes 版控制台，只须要简略的点击几下，为容器节点打标，就能够利用cGPU容器隔离，最大化的利用GPU的硬件能力了。同时，还能够通过Prometheus的监控能力查看每个cGPU容器内的显存用量，在享受低成本的同时，保障了利用的可靠性。 疾速部署和应用的形式，能够参见阿里云开发者社区的文章:https://developer.aliyun.com/article/762973更具体的应用文档，能够参考阿里云的帮忙文档：https://help.aliyun.com/document_detail/163994.html 2 在阿里云GPU实例上应用cGPU容器 为了更灵便的反对各种客户的须要，咱们也凋谢了阿里云GPU实例上应用cGPU容器的能力。cGPU依赖 Docker 和 NVIDIA Docker，在应用cGPU前，请确保环境能够失常创立带GPU的容器服务。 装置:下载cGPU 安装包:wget http://cgpu.oss-cn-hangzhou.aliyuncs.com/cgpu-0.8.tar.gz 解压后执行 sh install.sh 命令装置。装置后应用lsmod | grep cgpu 命令验证是否依照胜利：lsmod | grep cgpucgpu_km 71355 0 ...

集群安装准备工作请参考https://segmentfault.com/a/11900000201191901.环境介绍一共三台 CentOS Linux release 7.6.1810 (Core) 192.168.1.100 master 192.168.1.101 node1 192.168.1.102 node2 2.Master、Node节点安装、配置Docker# 卸载原来的dockersudo yum remove docker \ docker-client \ docker-client-latest \ docker-common \ docker-latest \ docker-latest-logrotate \ docker-logrotate \ docker-engine# 安装依赖sudo yum update -y && sudo yum install -y yum-utils \ device-mapper-persistent-data \ lvm2 #添加阿里云yum源（官网的源比较慢）sudo yum-config-manager --add-repo http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo # 安装docker的指定版本查看版本$ yum list docker-ce --showduplicates | sort -r$ sudo yum install docker-ce-<VERSION_STRING> docker-ce-cli-<VERSION_STRING> containerd.io例如：yum install docker-ce-18.09.5 docker-ce-cli-18.09.5 containerd.io -y# 查看docker版本docker --version# 开机启动systemctl enable --now docker修改docker cgroup驱动，与k8s一致，使用systemd ...

Docker入门基础之容器使用Docker简介Docker 是一个开源的应用容器引擎，基于Go语言并遵从Apache2.0协议开源。 Docker 可以让开发者打包他们的应用以及依赖包到一个轻量级、可移植的容器中，然后发布到任何流行的 Linux 机器上，也可以实现虚拟化。 容器是完全使用沙箱机制，相互之间不会有任何接口（类似 iPhone 的 app）,更重要的是容器性能开销极低。 Ubuntu Docker 安装1、Docker官方安装方法Docker 要求 Ubuntu 系统的内核版本高于 3.10 ，查看本页面的前提条件来验证你的 Ubuntu 版本是否支持 Docker。获取安装包： root@ubuntu:~# wget -qO- https://get.docker.com/ | sh安装完成后有提示： If you would like to use Docker as a non-root user, you should now consider adding your user to the "docker" group with something like: sudo usermod -aG docker runoob Remember that you will have to log out and back in for this to take effect! 启动docker服务 ...

据相关调研机构出具的报告数据显示，目前应用容器市场规模将从2016年的 7.62亿美元增⻓到2020年的27亿美元。 显而易见，引入容器所展现的巨大灵活性有效推动了其采用速率，使企业日益依赖该技术，与此同时容器技术也逐渐成⻓为虚拟机的实力替代品。对此，调研机构Forrester公司曾指出，58%的开发商计划在未来一年内使用容器或正在计划使用容器。 总结一句，使用容器可以帮助企业提高效率、降低成本，甚至在安全性方面有更可靠的保障， 这些易于打包以及轻量级的组件可以与同一虚拟机中的其他组件一起运行。 此外容器的大力采用也让开发者通过创建虚拟“沙箱”来更快、更好地工作，从而完成编写、管理和操作软件代码，可以在不影响服务器或虚拟机(VM)上运行其他应用程序和系统的情况下就可完成此操作。 基于此，CSDN特邀京东云事业部IaaS产品研发部资深技术专家陈峰采访，并以技术社区专业、客观的角度，探讨当前云服务商眼中的“容器服务”并为开发者选择合适的容器服务提供部分可参考的建议，以帮助其实现容器技术的创新应用等。 以下为部分采访内容，为了便于阅读与学习，我们对文本内容进行了编辑整理，内容如下： CSDN：总结一下，如何看待目前容器技术的发展，市场格局产生了怎样的变化？ 关键词：成熟、生产 京东云陈峰：过去一两年容器快速成熟普及，越来越多的用户开始使用容器部署生产核心业务。Kubernetes已经成为容器服务平台的事实标准。国内外各大云服务商都推出了托管的Kubernetes服务，也充分说明了这一点。 CSDN：样技术的创新迭代趋势对京东云有何启示？ 关键词：开源、普适性 京东云陈峰： （1） 开源的重要性 开源社区经过多年的发展，已经成为成熟的软件产品开发和运营模式。和闭源专有软件相比较，开源有平台中立、代码透明、快速需求功能迭代、快速获取客户群体、快速获取客户反馈、全社区的协作完善等优点。大家可以看到，虽然每个公有云服务商也开发了专有服务，但是最流行的服务仍然是开源托管软件服务，或者至少接口和开源软件兼容。我们今天看到的流行开源软件都是在开源生态中经过多轮优胜劣汰、进化存活下来的强者。Kubernetes能够这么流行，和它是以开源方式运作是分不开的。云服务商需要思考一种和开源互利共赢的合作模式。 （2） 技术的普适性是普及的关键 大家可能还记得，多年前曾经有过一波PAAS平台浪潮，但最终没有流行起来。我认为原因还是上一代PAAS平台多数和语言绑定，要求固定的框架使用模式。客户如果要使用的话，需要对系统做大量的适配和改造，导致很难大规模的流行使用。容器镜像这个核心设计创造性地解决了软件的部署依赖问题，并且不和具体底层OS绑定，不和语言绑定，不和具体框架绑定。容器技术的普适性正是其快速普及的关键。从京东云角度来说，我们做技术规划时，一定要考虑技术的普适性，这样的技术才能带来更大的价值。 CSDN：相较于过去，目前的企业级用户对容器技术有何新需求？ 关键词：完整、理性 京东云陈峰：企业级用户希望云服务商能提供一个容器的整体解决方案。以容器编排为例，用户不单单需要托管Kubernetes，还希望能和云上的网络、存储、监控、日志、CI/CD等方方面面的功能紧密集成，降低用户的使用门槛和难度。 另外随着容器用于部署生产业务，用户对安全相关的问题也越来越关注。 CSDN：在应对这些发展时，京东云有何技术与产品上的创新？如何评价这些应运而生的新技术以及新产品，能够帮助用户带来怎样的价值？ 关键词：原生容器、便捷高效 京东云陈峰：目前京东云推出了托管的Kubernetes服务，该服务和京东云产品的计算、网络和存储均做了深度集成，充分利用了公有云产品的优势，可以提供一个整体的方案，未来还会涉及到托管服务并集成更多云服务，做到开盒即用。 此外，京东云还同时推出了基于虚拟化技术的原生容器。原生容器在设计强调了两点：容器运行时的安全隔离、简单便捷的使用方式。 如今Kubernetes平台功能日益强大的同时，使用也变得越来越复杂，这个产品可以有效降低用户的学习成本以及使用难度；原生容器把自身定位成一种镜像格式做到与平台无关，部署更友好的“虚机”，目标是降低用户的学习成本和使用难度。基于原生容器，京东云也推出了Serverless Kubernetes服务，该服务不用创建虚机节点，可以直接使用Kubernetes接口调度管理原生容器，对于希望使用Kubernetes服务抽象，但是不希望自己管理资源节点的用户提供了一个很好的选择。 京东云容器技术目前已经支撑了零售、物流等众多京东核心业务。具体实施模式是混合云模式，由京东零售专有数据中心和京东云构成多活架构，并且通过大容量专线互联互通。基于容器的一个巨大好处就是实施混合云非常方便。618和11.11备战期间，京东团队各业务会根据业务流量预估和真实的全链路压测确定资源缺口，然后直接在云申请容器资源扩容即可，业务和部署流程无需做任何改造。 CSDN： 如今Serverless的火爆对容器技术创新发展产生了怎样的影响？ 关键词：未来 京东云陈峰：在我看来，Serverless是一种产品理念和服务提供方式，意味着客户不需要再关注基础设施，而将关注点放到业务上。 具体展开来讲，对用户来说，Serverless意味着更简单的使用体验、更高的可用性和弹性、服务按量付费。对云服务商来说，目前用户按规格购买资源的方式利用率仍然不高，存在着很多浪费。Serverless可以进一步提升云整体资源的利用率，从而降低资源的使用成本，最终可以将成本收益回馈给客户，降低整个行业和社会的IT使用成本。所以从长远来看，Serverless的意义巨大。 具体到容器技术创新的影响方面，Serverless对容器的安全和毫秒级快速启动提出了更高的要求。除了容器的挑战之外，Serverless在计算和存储分离技术、网络架构支持更高性能的网络资源分配也都还有诸多挑战待解决。 CSDN：新的一年，京东云将重点关注哪些容器的技术点？ 关键词：Serverless 京东云陈峰：新的一年中，我们会继续完善托管的Kubernetes服务，支撑超大企业级的Kubernetes集群服务能力。混合云、跨Cluster的微服务架构、安多租户都是我们关注的点；底层技术上，我们会做轻量级容器相关的研发来更好的支撑Serverless服务。 CSDN：在云计算的技术方向，预测一下2019年会有哪些新的技术趋势以及产业方向？例如随着技术的发展，云计算在向着多云、边缘计算领域发展等，对于这些领域京东云都有何规划？ 关键词：多云、边缘 京东云陈峰：多云方向，我们会去探索基于K8S的多云产品。传统的多云我认为还是挺困难的。K8S给实施多云提供了一层很好的抽象，拉平了多云的API，给多云架构提供了很好的基础。 京东云非常看好边缘计算。因为边缘计算能够在成本和体验上都带来大幅的改善。成本上，能降低核心城市数据中心使用和核心骨干大网带宽的成本。体验上，就近计算、存储可能带来更低的延迟。相信5G的到来，会进一步提速边缘计算的落地。 具体到京东，我们正在根据场景需求去分析提炼合适的边缘计算模式。小到设备的边缘，中到厂区的边缘，大到城市的边缘。边缘节点的规模大小、提供的具体服务类型都和需求场景相关。最重要的还是逐步去落地，实实在在带来客户价值。另外边缘计算也需要逐步抽象出来标准的产品服务形态和使用方式。包括部署、监控、数据同步等等云核心数据中心已经标准化的基础服务在边缘节点也全部要逐步标准化。京东集团各种业务本身就有大量的边缘计算场景，我们现在正在思考和实践合适的落地方式。 预知详情可点击“京东云”查看相关产品信息

2019年7月9-10日，国泰君安信息产业投资峰会在上海陆家嘴举办。作为国内容器PaaS领域的龙头公司，灵雀云受邀出席本次大会，在“数字化转型从云做起”的论坛中，CTO陈恺发表了《云原生助力企业持续创新》的主题演讲，与现场200余位科创企业高管、PE、VC和产业基金领导共同探讨传统企业数字化转型的新机遇、新挑战，以及云原生等新兴技术的价值与趋势。 云原生技术成为传统企业关注重点 陈恺在演讲伊始首先指出，2019年将是云原生理念和技术体系在企业落地的元年。云原生的概念受到越来越大范围的关注，从容器开始，围绕Kubernetes 周边生态催生出繁荣的云原生技术体系。灵雀云作为容器和云原生技术的先行者，目前已经帮助200余家传统企业做了容器平台的落地。 软件正在吞噬整个世界。每家企业都会受到以软件为中心的商业模式的冲击。在这种环境下，只有变成一家软件公司才能继续具备核心的竞争力。陈恺强调，企业要保持核心的商业模式，仅仅具备软件能力是不够的，更关键的是如何加快软件开发和交付的方式，快速持续地将软件产生的价值交付给企业用户，才是云原生的最大价值。“云原生是能够最大化地释放云计算生产力的应用设计、开发、交付和管理方式。” 很多企业客户都在组建和扩充自己的开发团队，建设现代化应用开发和架构能力，这就需要平台化的基础设施支撑现代化应用交付方式。他结合灵雀云的大量客户实践强调，云原生技术是每家转型中的传统企业都离不开的。 后Kubernetes时代云原生“黄金三角” 容器化、DevOps、微服务构成了云原生技术的“黄金三角”，已经是大家对云原生的共识。云原生应用本身是容器化应用交付变革的副产品。今天对于传统企业来说，只有容器化远远不够，企业客户期待业务跑在Kubernetes平台上可以做动态交付和管理。其次，希望拥抱DevOps理念和文化，快速交付价值，并通过合适的DevOps工具去落地最佳实践。第三，当快速交付成为必须的要求，IT架构又可能成为敏捷交付的瓶颈，这时企业就不得不考虑架构的改造，向微服务架构转型。 DevOps包含三层含义：鼓励沟通与协作的文化、思维方式与组织架构；一系列工程化的最佳实践（规范、流程、方法论）；落地最佳实践的工具链和平台。DevOps 覆盖应用全生命周期管理，从需求、规划、开发到测试、运维。灵雀云帮助很多传统企业落地DevOps的过程中得出许多观察：整个流程中涉及的工具类别非常多，每个类别都有大量工具。而且每家企业的工具选型都不同，没有标准可言。随着时间的推移，工具选型还会发生变化。 基于这些观察，灵雀云并没有推出新的DevOps工具，而是致力于打造一个开放式的DevOps工具链集成和编排平台，去兼容客户已有和未来的工具选型，通过集成将工具串成工具链，通过编排把工具链和容器平台进行联动，形成完整的系统。在这个过程中提炼DevOps 落地的最佳实践，最终将最佳实践自动化以后作为服务进行输出。 谈及微服务陈恺指出，云原生应用提倡应用和状态的分离，微服务架构下，每个微服务都要掌控自己的数据，云原生应用依赖外部的数据服务（backing services），微服务架构下多元化存储是常态，应用依赖很多backingservices，基础设施要很好地去支撑管理这些backing services，让应用可以很容易地去消费数据服务。而狭义上的微服务治理，关注的则是服务与服务之间的连接和通讯，即Service mesh。 他强调，微服务治理本身也进入到了后Kubernetes时代。早期微服务作为一个用例，在推动容器技术的发展。当Kubernetes变成标准后，会反过来推动微服务治理的最佳实践。今天社区里已经形成共识，在Kubernetes平台之后，Service mesh是微服务治理的最佳实践。 其中，Istio是Service Mesh中最主流的技术选型，它的推出让业界对Service mesh的整体架构有了共识：数据平面和控制平面解耦，通过控制平面对服务网格有全局性的可观测性和可控制性。Envoy是数据平面领导者，Istio是控制平面明星级项目，未来数据平面会趋于大众化，而创新会更多聚焦在控制平面。目前灵雀云已经在产品线当中全面集成了Istio，为企业客户提供企业级的服务网格，以及基于Kubernetes之上的微服务治理最佳实践。 灵雀云云原生企业落地实践 灵雀云的使命是通过云原生技术助力企业持续创新，成功数字化转型。在产品层面形成了完整的产品矩阵，AKS（Alauda Kubernetes）企业就绪Kubernetes发行版、ACP（AlaudaContainer Platform）一站式云原生应用赋能平台、ACE（Alauda Cloud Enterprise ）企业级PaaS平台（技术中台）三大产品构成灵雀云的产品线。 其中，AKS对Kubernetes发行版进行了大量加固，经过了三年来100+企业客户生产环境的考验。ACP聚焦云原生三大核心场景，提供面向开发者的友好体验。ACE面向大型企业平台部门，构建企业专属的技术中台。灵雀云还围绕三大云原生技术提供培训、咨询、联合开发等完善的专业服务，帮助企业客户实现三大云原生技术的落地。 凭借优秀的技术和产品能力，完善的交付和服务体系，灵雀云先后服务了招商银行、民生银行、中信银行、光大银行、华泰证券、中石油、国家电网、中移动、南航、宇通客车等中国最优秀的企业，涵盖金融、制造、能源、航空、汽车、运营商等领域的诸多五百强客户。 通过最先进的技术、最专业的服务、最可靠的合作，灵雀云希望成为传统企业数字化转型中最可信赖的云原生技术合作伙伴。

Redis集群概述Redis作为当前非常热门的内存型数据结构存储，可用于数据存储，缓存和消息代理等。本文将讲解如何基于docker搭建Redis集群，Redis的集群设计包括两个部分：主从复制和哈希Slot。1.1. 主从复制主从复制在数据库中很常见，一般用来做读写分离，Redis中也是如此。要求只有1个Master（主节点），可以有N个slaver（从节点），而且Slaver也可以有自己的Slaver，由于这种主从的关系决定他们是在配置阶段就要指定他们的上下级关系，而不是Zookeeper那种平行关系是自主推优出来的。读写分离，Master只负责写和同步数据给Slaver，Slaver承担了被读的任务，所以Slaver的扩容只能提高读效率不能提高写效率。Slaver先将Master那边获取到的信息压入磁盘，再load进内存，client端是从内存中读取信息的。当一个新的Slaver加入到这个集群时，会主动找Master来拜码头，Master发现新的小弟后将全量数据发送给新的Slaver，数据量越大性能消耗也就越大，所以尽量避免在运行时做Slaver的扩容。优点：读写分离，通过增加Slaver可以提高并发读的能力。缺点：Master写能力是瓶颈，维护Slaver开销也总将会变成瓶颈。1.2. 哈希Slot哈希Slot名字上可能不好理解，其实就是数据库中的“水平划分”。如果你之前有了解过数据库的表分区的话，就会发现下来对于哈希Slot的描述，就和数据库表分区里面的“HASH分区”原理上大致相同。对象保存到Redis之前先经过CRC16哈希到一个指定的Node上，例如图中Object4最终Hash到了Node1上。每个Node被平均分配了一个Slot段，对应着0-16384，Slot不能重复也不能缺失，否则会导致对象重复存储或无法存储。Node之间也互相监听，一旦有Node退出或者加入，会按照Slot为单位做数据的迁移。例如Node1如果掉线了，0-5640这些Slot将会平均分摊到Node2和Node3上,由于Node2和Node3本身维护的Slot还会在自己身上不会被重新分配，所以迁移过程中不会影响到 5641-16384 Slot段的使用。优点：将Redis的写操作分摊到了多个节点上，提高写的并发能力，扩容简单。缺点：每个Node承担着互相监听、高并发数据写入、高并发数据读出，工作任务繁重。1.3. 合二为一看到这里大家也就发现了，主从和哈希的设计优缺点正好是相互弥补的，将二者结合在一起，就是Redis集群的终极形态，先Hash分逻辑节点，然后每个逻辑节点内部是主从，如图：2.集群安装默认我们已经有了docker环境，现在开始基于docker安装Redis集群。redis 5.0 版本之前，网上有很多教程都是通过redis-trib.rb 来创建集群，但是redis 5.0 版本以后，就只能通过 redis-cli 来实现。本文即通过 redis-cli 创建集群，因为redis集群的节点选举方式是需要半数以上的master通过，所以建议创建奇数个节点。本例中创建3个Master节点，并为每个Master节点各分配1个Slave节点。2.1. 宿主机环境首先需要找一份原始的redis.conf文件，将其重命名为：redis-cluster.tmpl，并配置如下几个参数，此文件的目的是生成每一个redis实例的redis.conf:vi redis-cluster.tmpl然后执行下列脚本，给3个Master和3个Slave创建各自的挂载卷目录当前目录结构为2.2. 创建Redis节点假设我们只考虑单纯的docker环境，并无docker-compose和k8s之类的服务编排，每个redis容器之间必须要保证通讯，可以通过创建docker network。（使用微服务编排的情况，后续再讨论）现在我们就可以运行docker redis 的 master 和 slave 实例了查看已创建的redis容器2.3. 构建集群通过redis-cli 命令构建集群，随便找一个redis容器，运行redis-cli --cluster create --cluster-replicas 1 ip:port 命令即可记住构建集群时，要保证节点redis数据为空，否则会出现下列错误。2.4. 集群验证集群搭建完成后，我们通过 redis-cli 命令连接集群节点验证一下。redis 集群节点的连接命令是通过 redis-cli -c -h ${ip} -p ${port}可以看到通过 "cluster info"命令看到集群的基本信息，所有的slot (16384) 都分配完毕。然后通过 "cluster nodes" 命令查看到每个master节点的slot分配的区域。至此，redis集群基本安装成功。3.后期运维3.1. 基本命令集群节点槽(slot)3.2. 常见问题（1）redis-cluster 把所有的物理节点映射到[ 0 ~ 16383 ]个slot（哈希槽）上，cluster负责维护 node<->slot<->value。（2）集群任意一个节点中，如果master挂掉，但是还有slaver，slave将自动升为 master，系统正常。（3）集群任意一个节点中，如果master挂掉，并且没有slaver，集群将进入fail状态。（4）如果集群超过半数以上节点的master挂掉，不管是否有slaver，集群都将进入fail状态。（5）节点判断是否失效的选举，是集群中所有的master参与的，如果半数以上的master节点与当前被检测的master节点通讯检测超时（cluster-node-timerout），就认为当前master节点挂掉了。本人创业团队产品MadPecker，主要做BUG管理、测试管理、应用分发网址:www.madpecker.com，有需要的朋友欢迎试用、体验！本文为MadPecker团队技术人员编写，转载请标明出处

要使用和维护Kubernetes集群，最常用且直接的方式，就是使用自带的命令行工具Kubectl。这里梳理下常用的子命令及参数，方便查找参考。 参考文档：Overview of kubectlkubectl.docskubernetes-handbookkubectl概述祭出一张图，转载至kubernetes-handbook/kubectl命令概述，可以对命令族有个整体的概念。 环境准备kubectl安装后，默认是没有比如自动补全等功能的，频繁使用比较不方便。目前已经有各类kubectl小工具可以提高效率，还有kubectl专用的shell了。个人感觉比较好用有以下这些： 自动补全kubectl 命令在bash中默认是没有自动补全的，需要安装bash_completion，添加自动补全脚本。这里以CentOS为例，其他操作系统配置可以参看Install and Set Up kubectl # 安装bash-completionyum install -y epel-release.noarchyum install -y bash_completion# 添加补全脚本kubectl completion bash >/etc/bash_completion.d/kubectl重新登录shell，可以发现kubectl的子命令，包括资源名称都可以用Tab键自动补全了: 快速切换集群和Namespace生产环境一般是多集群，至少也是多NS的环境，免不了经常在不同集群和不同NS间切换。切换集群要修改环境变量、切换NS要在命令跟上 -n namespace，都不是太方便。而用kubectx和kubens两个小工具可以实现快速切换。这俩在同一项目里：ahmetb/kubectx # 安装sudo git clone https://github.com/ahmetb/kubectx /opt/kubectxsudo ln -s /opt/kubectx/kubectx /usr/local/bin/kubectxsudo ln -s /opt/kubectx/kubens /usr/local/bin/kubens# 使用kubectx# kubectx : 列出所有上下文# kubectx <NAME> : 切换到某个上下文$ kubectx minikubeSwitched to context "minikube".# kubectx - : 切换回上一个上下文$ kubectx -Switched to context "oregon".# kubectx <NEW_NAME>=<NAME> : 重命名一个集群上下文$ kubectx dublin=gke_ahmetb_europe-west1-b_dublinContext "dublin" set.Aliased "gke_ahmetb_europe-west1-b_dublin" as "dublin".# kubectx <NEW_NAME>=. : 重命名当前上下文# kubectx -d <NAME> : 删除上下文# 使用kubens# kubens : 列出所有的NS# kubens <NS-NAME> : 切换当前NS$ kubens kube-systemContext "test" set.Active namespace is "kube-system".# kubens - : 切换回上一个NS$ kubens -Context "test" set.Active namespace is "default".关于多集群切换的配置和上下文的概念可以参看官方文档，有中文。 ...

在上篇文章minikube部署中，有提到Minikube部署Kubernetes的核心就是Kubeadm，这篇文章来详细说明下Kubeadm原理及部署步骤。写这篇文章的时候，Kubernetes1.14刚刚发布，所以部署步骤以1.14版为主。Kubeadm原理简述Kubeadm工具的出发点很简单，就是尽可能简单的部署一个生产可用的Kubernetes集群。实际也确实很简单，只需要两条命令：# 创建一个 Master 节点$ kubeadm init# 将一个 Node 节点加入到当前集群中$ kubeadm join <Master 节点的 IP 和端口 >kubeadm做了这些事执行 kubeadm init时：自动化的集群机器合规检查自动化生成集群运行所需的各类证书及各类配置，并将Master节点信息保存在名为cluster-info的ConfigMap中。通过static Pod方式，运行API server, controller manager 、scheduler及etcd组件。生成Token以便其他节点加入集群执行 kubeadm join时：节点通过token访问kube-apiserver，获取cluster-info中信息，主要是apiserver的授权信息（节点信任集群）。通过授权信息，kubelet可执行TLS bootstrapping，与apiserver真正建立互信任关系（集群信任节点）。简单来说，kubeadm做的事就是把大部分组件都容器化，通过StaticPod方式运行，并自动化了大部分的集群配置及认证等工作，简单几步即可搭建一个可用Kubernetes的集群。这里有个问题，为什么不把kubelet组件也容器化呢，是因为，kubelet在配置容器网络、管理容器数据卷时，都需要直接操作宿主机，而如果现在 kubelet 本身就运行在一个容器里，那么直接操作宿主机就会变得很麻烦。比如，容器内要做NFS的挂载，需要kubelet先在宿主机执行mount挂载NFS。如果kubelet运行在容器中问题来了，如果kubectl运行在容器中，要操作宿主机的Mount Namespace是非常复杂的。所以，kubeadm选择把kubelet运行直接运行在宿主机中，使用容器部署其他Kubernetes组件。所以，Kubeadm部署要安装的组件有Kubeadm、kubelet、kubectl三个。上面说的是kubeadm部署方式的一般步骤，kubeadm部署是可以自由定制的，包括要容器化哪些组件，所用的镜像，是否用外部etcd，是否使用用户证书认证等以及集群的配置等等，都是可以灵活定制的，这也是kubeadm能够快速部署一个高可用的集群的基础。详细的说明可以参考官方Reference。但是，kubeadm最重要的作用还是解决集群部署问题，而不是集群配置管理的问题，官方也建议把Kubeadm作为一个基础工具，在其上层再去量身定制适合自己的集群的管理工具（例如minikube）。Kubeadm部署一个高可用集群Kubernetes的高可用Kubernetes的高可用主要指的是控制平面的高可用，简单说，就是有多套Master节点组件和Etcd组件，工作节点通过负载均衡连接到各Master。HA有两种做法，一种是将etcd与Master节点组件混布在一起：另外一种方式是，使用独立的Etcd集群，不与Master节点混布：两种方式的相同之处在于都提供了控制平面的冗余，实现了集群高可以用，区别在于：Etcd混布方式：所需机器资源少部署简单，利于管理容易进行横向扩展风险大，一台宿主机挂了，master和etcd就都少了一套，集群冗余度受到的影响比较大。Etcd独立部署方式：所需机器资源多（按照Etcd集群的奇数原则，这种拓扑的集群关控制平面最少就要6台宿主机了）。部署相对复杂，要独立管理etcd集群和和master集群。解耦了控制平面和Etcd，集群风险小健壮性强，单独挂了一台master或etcd对集群的影响很小。部署环境 由于机器资源不足，下面的部署测试，只会以混布的方式部署一个1haproxy，2master，2*node，共5台机器的集群，实际上由于etcd选举要过半数，至少要3台master节点才能构成高可用，在生产环境，还是要根据实际情况，尽量选择风险低的拓扑结构。机器：master-1：192.168.41.230 (控制平面节点1)master-2：192.168.41.231 (控制平面节点2)node-1：172.16.201.108 (工作节点1)node-2：172.16.201.109 (工作节点2)haproxy：192.168.41.231 (haproxy)系统内核版本：# cat /etc/redhat-releaseCentOS Linux release 7.6.1810 (Core) # uname -r 5.0.5-1.el7.elrepo.x86_64集群版本kubeadm：1.14.0Kubernetes：1.14.0Docker：Community 18.09.4haproxy: 1.5.18部署步骤机器准备在所有节点上操作：关闭selinux,firewallsetenforce 0sed -i ’s/SELINUX=enforcing/SELINUX=permissive/’ /etc/selinux/config systemctl stop firewalldsystemctl disable firewalld关闭swap，(1.8版本后的要求，目的应该是不想让swap干扰pod可使用的内存limit)swapoff -a修改下面内核参数，否则请求数据经过iptables的路由可能有问题cat <<EOF > /etc/sysctl.d/k8s.confnet.bridge.bridge-nf-call-ip6tables = 1net.bridge.bridge-nf-call-iptables = 1EOFsysctl –system安装kubeadm、docker在除了haproxy以外所有节点上操作将Kubernetes安装源改为阿里云，方便国内网络环境安装cat << EOF > /etc/yum.repos.d/kubernetes.repo[kubernetes]name=Kubernetesbaseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64/enabled=1gpgcheck=1repo_gpgcheck=1gpgkey=https://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg https://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpgEOF安装docker-cewget -O /etc/yum.repos.d/docker-ce.repo https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repoyum install -y docker-ce安装kubelet kubeadm kubectl yum install -y kubelet kubeadm kubectl安装配置负载均衡在haproxy节点操作：# 安装haproxyyum install haproxy -y # 修改haproxy配置cat << EOF > /etc/haproxy/haproxy.cfgglobal log 127.0.0.1 local2 chroot /var/lib/haproxy pidfile /var/run/haproxy.pid maxconn 4000 user haproxy group haproxy daemondefaults mode tcp log global retries 3 timeout connect 10s timeout client 1m timeout server 1mfrontend kube-apiserver bind :6443 # 指定前端端口 mode tcp default_backend masterbackend master # 指定后端机器及端口，负载方式为轮询 balance roundrobin server master-1 192.168.41.230:6443 check maxconn 2000 server master-2 192.168.41.231:6443 check maxconn 2000EOF# 开机默认启动haproxy，开启服务systemctl enable haproxysystemctl start haproxy# 检查服务端口情况：# netstat -lntup | grep 6443tcp 0 0 0.0.0.0:6443 0.0.0.0: LISTEN 3110/haproxy部署Kubernetes在master-1节点操作：准备集群配置文件,目前用的api版本为v1beta1，具体配置可以参考官方referencecat << EOF > /root/kubeadm-config.yamlapiVersion: kubeadm.k8s.io/v1beta1kind: ClusterConfigurationkubernetesVersion: v1.14.0 # 指定1.14版本controlPlaneEndpoint: 192.168.41.232:6443 # haproxy地址及端口imageRepository: registry.cn-hangzhou.aliyuncs.com/google_containers # 指定镜像源为阿里源networking: podSubnet: 10.244.0.0/16 # 计划使用flannel网络插件，指定pod网段及掩码EOF执行节点初始化systemctl enable kubeletsystemctl start kubeletkubeadm config images pull –config kubeadm-config.yaml # 通过阿里源预先拉镜像kubeadm init –config=kubeadm-config.yaml –experimental-upload-certs安装成功，可以看到输出You can now join any number of the control-plane node running the following command on each as root:# master节点用以下命令加入集群： kubeadm join 192.168.41.232:6443 –token ocb5tz.pv252zn76rl4l3f6 \ –discovery-token-ca-cert-hash sha256:141bbeb79bf58d81d551f33ace207c7b19bee1cfd7790112ce26a6a300eee5a2 \ –experimental-control-plane –certificate-key 20366c9cdbfdc1435a6f6d616d988d027f2785e34e2df9383f784cf61bab9826Then you can join any number of worker nodes by running the following on each as root:# 工作节点用以下命令加入集群：kubeadm join 192.168.41.232:6443 –token ocb5tz.pv252zn76rl4l3f6 \ –discovery-token-ca-cert-hash sha256:141bbeb79bf58d81d551f33ace207c7b19bee1cfd7790112ce26a6a300eee5a2 原来的kubeadm版本，join命令只用于工作节点的加入，而新版本加入了 –experimental-contaol-plane 参数后，控制平面（master）节点也可以通过kubeadm join命令加入集群了。加入另外一个master节点在master-2操作：kubeadm join 192.168.41.232:6443 –token ocb5tz.pv252zn76rl4l3f6 --discovery-token-ca-cert-hash sha256:141bbeb79bf58d81d551f33ace207c7b19bee1cfd7790112ce26a6a300eee5a2 --experimental-control-plane –certificate-key 20366c9cdbfdc1435a6f6d616d988d027f2785e34e2df9383f784cf61bab9826mkdir -p $HOME/.kubecp -i /etc/kubernetes/admin.conf $HOME/.kube/configchown $(id -u):$(id -g) $HOME/.kube/config 现在，在任何一个master 节点，执行kubectl get no,可以看到，集群中已经有2台master节点了# kubectl get noNAME STATUS ROLES AGE VERSIONmaster-1 NotReady master 34m v1.14.0master-2 NotReady master 4m52s v1.14.0加入两个工作节点分别在两个node节点操作：kubeadm join 192.168.41.232:6443 –token ocb5tz.pv252zn76rl4l3f6 \ –discovery-token-ca-cert-hash sha256:141bbeb79bf58d81d551f33ace207c7b19bee1cfd7790112ce26a6a300eee5a2 再次执行kubectl get no# kubectl get noNAME STATUS ROLES AGE VERSIONmaster-1 NotReady master 45m v1.14.0master-2 NotReady master 15m v1.14.0node-1 NotReady <none> 6m19s v1.14.0node-2 NotReady <none> 4m59s v1.14.0可以看到两个node节点都加入集群了。可是，各个节点状态为什么都是NotReady呢。通过执行kubectl describe master-1，可以看到这样的提示：runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized原来是因为网络插件没有就绪导致的。所以 ，我们来安装一波kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/a70459be0084506e4ec919aa1c114638878db11b/Documentation/kube-flannel.yml再次查看节点状态，可以看到所有节点都已经ready了。# kubectl get noNAME STATUS ROLES AGE VERSIONmaster-1 Ready master 134m v1.14.0master-2 Ready master 104m v1.14.0node-1 Ready <none> 94m v1.14.0node-2 Ready <none> 93m v1.14.0至此，一个2主节点2工作节点的k8s集群已经搭建完毕。如果要加入更多的master或node节点，只要多次执行kubeadm join命令加入集群就好，不需要额外配置，非常方便。集群测试跟上篇文章minikube部署一样，这里部署一个简单的goweb服务来测试集群，运行时暴露8000端口，同时访问/info路径会显示容器的主机名。准备deployment和svc的yaml：# deployment-goweb.yamlapiVersion: apps/v1kind: Deploymentmetadata: name: gowebspec: selector: matchLabels: app: goweb replicas: 4 template: metadata: labels: app: goweb spec: containers: - image: lingtony/goweb name: goweb ports: - containerPort: 8000# svc-goweb.yamlapiVersion: v1kind: Servicemetadata: name: gowebsvcspec: selector: app: goweb ports: - name: default protocol: TCP port: 80 targetPort: 8000部署服务kubectl apply -f deployment-goweb.yamlkubectl apply -y svc-goweb.yaml查看pod及服务[root@master-1 ~]# kubectl get po -o wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATESgoweb-6c569f884-67z89 1/1 Running 0 25m 10.244.1.2 node-1 <none> <none>goweb-6c569f884-bt4p6 1/1 Running 0 25m 10.244.1.3 node-1 <none> <none>goweb-6c569f884-dltww 1/1 Running 0 25m 10.244.1.4 node-1 <none> <none>goweb-6c569f884-vshkm 1/1 Running 0 25m 10.244.3.4 node-2 <none> <none># 可以看到，4个pod分布在不同的node上[root@master-1 ~]# kubectl get svcNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEgowebsvc ClusterIP 10.106.202.0 <none> 80/TCP 11mkubernetes ClusterIP 10.96.0.1 <none> 443/TCP 21h# 暴露80端口测试访问[root@master-1 ~]# curl http://10.106.202.0/infoHostname: goweb-6c569f884-bt4p6[root@master-1 ~]# curl http://10.106.202.0/infoHostname: goweb-6c569f884-67z89[root@master-1 ~]# curl http://10.106.202.0/infoHostname: goweb-6c569f884-vshkm#可以看到，对SVC的请求会在pod间负载均衡。小结本文简单介绍了kubeadm工具原理，以及如何用它部署一个高可用的kubernetes集群。需要注意的是，kubeadm工具总体已经GA，可以在生产环境使用了。但是文中通过"kubeadm join -experimental-contaol-plane"参数增加主节点的方式，还是在alpha阶段，实际在生产环境还是用init方式来增加主节点比较稳定。kubeadm更多详细配置可以参考官方文档 ...

2019年微服务概念继续火爆，随着Docker容器技术的快速普及，特别在一线互联网公司。使用Docker技术可以帮助企业快速水平扩展服务，从而到达弹性部署业务的能力。在云服务概念兴起之后，Docker的使用场景和范围进一步发展，如今在微服务架构越来越流行的情况下，微服务+Docker的完美组合，更加方便微服务架构运维部署落地。如何快速入门docker，开发属于自己的容器应用？咱今天不整虚的，来点实打实的干货：利用URLOS快速开发docker应用，并可随意将应用导出给他人使用。对URLOS不了解的朋友，这里大概介绍一下，URLOS是一个容器云管理面板，基于Docker容器技术打包和运行应用，可自动识别机器和云应用的故障并将云应用转移至可用的机器上，单机故障并不影响业务开展，配合云存储便可轻松搭建7x24小时持续运行的应用环境。URLOS官网：https://www.urlos.com/URLOS安装方法：https://www.urlos.com/center-…URLOS开发交流QQ群：695164700，147882180URLOS创始人微信：安装URLOS：curl -SO https://www.urlos.com/install && chmod 544 install && ./install安装完成后，地址栏输入 http://ip:9968 即可访问。划重点：利用URLOS开发docker应用的最基本的流程：这里我们以制作一个LNP（linux+nginx+php）网站环境为例，快速制作一个可以导出给他人使用的docker应用。在开始制作之前，我们先到docker官网注册一个账号，这样我们才能将制作好的镜像上传到docker仓库，打开https://hub.docker.com/ 有了hub账号，那么我们开始制作吧！第一步：拉取镜像，启动容器，进入容器使用SSH工具连接主机，输入以下命令拉取一个php:7.3.3-fpm-stretch镜像，启动容器并进入这个容器内部：docker run -it php:7.3.3-fpm-stretch bash看到类似上图中类似的字符串时，表示已经成功进入容器内部，这个便是当前容器的ID第二步：更新镜像，安装我们要的nginx以及PHP相关扩展先更新一下镜像源，国内用阿里的会快一些set -ex \ && sed -i ’s@security.debian.org@mirrors.aliyun.com@’ /etc/apt/sources.listset -ex \ && sed -i ’s@deb.debian.org@mirrors.aliyun.com@’ /etc/apt/sources.listapt-get update更新完成之后，再来安装nginx，默认安装目录为/etc/nginxapt-get install -y nginx官方镜像默认是没有ps -ef 命令，因此需要手动安装apt-get install -y procps安装PHP扩展。安装php自带的一些扩展时，可以使用docker-php-ext-configure和docker-php-ext-install。例如我们要安装pdo_mysql：docker-php-ext-configure pdo_mysqldocker-php-ext-install pdo_mysql然后使用 php -m查看我们的扩展是否安装成功。使用这种方式安装，系统会自动生成一个配置文件，提供给php加载，使用命令查看：ls -l /usr/local/etc/php/conf.d/gd扩展安装apt-get install -y libfreetype6-dev \libjpeg62-turbo-dev \libpng-devdocker-php-ext-configure gd –with-freetype-dir=/usr/include/ –with-jpegdir=/usr/include/docker-php-ext-install gd如果需要安装memcached、redis扩展，则需要下载扩展到容器，然后手动编译安装。地址：https://pecl.php.net/package/…https://pecl.php.net/package/...memcached扩展安装：curl -O https://pecl.php.net/get/memcached-3.1.3.tgztar xf memcached-3.1.3.tgz && cd memcached-3.1.3phpize./configure编译过程中若出现以下错误提示：则执行安装命令，然后重新编译安装memcached扩展：apt-get install -y libmemcached-dev./configuremake && make install添加extension=memcached.so语句到php.ini文件。安装完成后通过命令查看扩展存放的位置ls /usr/local/lib/php/extensions/no-debug-non-zts-20170718/php安装目录：/usr/local/phpphp.ini的配置文件目录：/usr/local/etc/php/。在这个目录下有两个文件：php.ini-development和php.iniproduction。因此，我们需要将php.ini-production文件重命名为php.ini。以后手动编译安装php扩展后需要添加extension=xx.so到php.ini。启动Nginx和php，检查是否正常运行。nginx && php-fpm -D第三步：打包镜像在打包成镜像之前，我们先将nginx、php-fpm关闭，删除一些不需要的应用以及清理一些安装的缓存文件，从而减小最终打包成镜像的大小。apt-get purge vim makeapt-get autoremoveapt-get autocleanrm -f /usr/local/etc/php/conf.d/* #统一将php扩展写入到php.ini文件然后，输入exit退出容器，通过以下命令将更新过的容器重新打包成一个新镜像：docker commit -m=“php-nginx-website” -a=“yourname” 96b3f038590b yourhubid/php-nginx:v0.1.0参数说明：-m：提交的描述信息-a：指定镜像作者96b3f038590b：容器IDyourhubid/php-nginx:v0.1.0：指定要创建的目标镜像名可以使用docker images命令来查看我们的新镜像第四步：上传镜像使用docker login命令登录 hub.docker.com，按提示输入账号和密码即可使用docker push命令将打包好的新镜像上传至镜像仓库：docker push yourhubid/php-nginx:v0.1.0第五步：登录URLOS制作应用注意：需要修改将/data/urlos/master-config/config.jsonc文件的envType的值设置为dev（开发环境）：vim /data/urlos/master-config/config.jsonc添加镜像浏览器地址栏输入http://主机ip:9968，登录URLOS，在左侧菜单栏选择镜像管理，然后点击右上角的添加按钮。输入镜像名称镜像地址开发者信息添加LNP应用在左侧菜单中选择应用管理。然后点击右上角的添加应用按钮：应用的基本信息如上图所示。镜像：选择上一步骤添加的镜像。URLOS最低版本号：如设置此选项则表示安装URLO的版本高于或者等于当前设置的值，才允许用户安装使用。容器端口：容器启动时对外通信的端口，即参数-p。网站的80、443等端口默认是对外开发的，在这里可以不用设置。如必须特定端口时，设置的格式{“22”:true}。标签：应用标签多用于搜索场景。选项开关注解：固定节点运行：若勾选，则表示用户在安装此应用时（创建此应用的服务）需要选择安装在某个节点（云主机）。若取消勾选，则表示此应用安装在选择的集群(单容器运行也取消勾选)，可达到负载均衡，故障转移的效果。单容器运行：若勾选，则表示安装此应用时，每个服务只运行一个容器。与固定节点运行配合使用，即固定节点运行时，则单容器运行。允许特权允许：若勾选，则容器内的root拥有了真正的root权限（宿主机器的root）,在容器内部就可以做任何事情（包括修改宿主机器的文件，启动宿主机器其他容器，执行mount等操作），不建议勾选。以root用户允许容器：这里的root用户是容器外部的一个普通用户，默认勾选。若容器内部的程序禁止root用户允许，则取消（如：MySQL）。挂载存储目录：如需要从宿主机器挂载文件到容器，则勾选。即参数 -v。挂载时区定义文件：容器的时间与宿主机器的时间保持一致。容器只读：禁止向容器写数据。全局网络：允许同一集群不同容器网络的容器通信。允许快照备份：勾选则允许执行快照备份（仅挂载了本地存储时有效）开启反向代理，则可以实现多容器共享端口，反之则不能。注解：插件：由PHP语言编辑的脚本文件组成。插件的使用会让用户在安装应用（创建服务）时更便捷，更智能。这里选择phpWebSite:v0_1_0 — Liu Xin —php网站环境这个插件即可。（制作插件后续会有详细说明）服务别名：创建服务时，在左上角显示的描述。应用数据别名：创建服务完成后，服务产生的数据或者用户基于创建的服务需要添加新的数据，对这些数据管理取的名字，即为应用数据别名。（如：创建MySQL数据库服务，用户可以手动添加数据库，创建网站服务时也可以新增数据库。）服务表单步骤：创建服务时，用户填写表单的步骤。（数字表示必填，其他符号表示选填）额外挂载：将宿主机器的除存储目录外的其他目录挂载到容器。额外启动参数：通过docker run运行容器时的额外参数，如：–add-host a.com:192.168.0.1注解：安装脚本：安装应用时需要执行的脚本命令。test -d /etc/nginx/conf.d/ || mkdir -p /etc/nginx/conf.d/启动脚本：需要启动程序的命令。nginxphp-fpm -D状态脚本：每隔2秒执行此脚本，用来检查程序是否正常允许。当前的脚本命令用来检查apache是否启动。status1=0 && (ps -ef|grep “php-fpm”|grep “master process”|grep -v “grep”) &&status1=1;status2=0 && (ps -ef|grep “nginx”|grep “master process”|grep -v “grep”) &&status2=1;if [ ${status1} != 0 ] && [ ${status2} != 0 ]; thenstatusScriptResult=1fi监控脚本：每隔1秒执行此脚本，检查状态脚本返回的结果判断程序是否正常允许。若异常，则执行退脚本。{w:statusScript:w}[ “$statusScriptResult” != 1 ] && exit 1退出脚本：容器关闭时之前，执行的脚本。如同，我们关闭电脑时，系统会关闭正在允许的程序。添加LNP模板在这个应用，我们需要添加模板php.ini、vhost.conf，然后在这两个模板的参数设置一些变量，这样用户在安装应用时，就可以根据自己的需要动态的调整。（如：设置php的上传大小，最大内存等）那么如何添加模板呢？我们在应用管理列表中找到上述创建的应用，然后点击右侧的更多选择管理模板。添加一个php.ini模板，然后在模板内容将php.ini文件内容复制进入，同时设置变量{w:upload_max_filesize:w}、{w:PHP_memory_limit:w}。[PHP]engine = Onshort_open_tag = Offprecision = 14output_buffering = 4096zlib.output_compression = Offimplicit_flush = Offunserialize_callback_func =serialize_precision = -1disable_functions =disable_classes =zend.enable_gc = Onexpose_php = Onmax_execution_time = 30max_input_time = 60memory_limit = 128Merror_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICTdisplay_errors = Offdisplay_startup_errors = Offlog_errors = Onlog_errors_max_len = 1024ignore_repeated_errors = Offignore_repeated_source = Offreport_memleaks = Onhtml_errors = Onvariables_order = “GPCS"request_order = “GP"register_argc_argv = Offauto_globals_jit = Onpost_max_size = {w:PHP_memory_limit:w}auto_prepend_file =auto_append_file =default_mimetype = “text/html"default_charset = “UTF-8"doc_root =user_dir =enable_dl = Offfile_uploads = Onupload_max_filesize = {w:upload_max_filesize:w}max_file_uploads = 20allow_url_fopen = Onallow_url_include = Offdefault_socket_timeout = 60extension=gd.soextension=memcached.soextension=sockets.soextension=mysqli.soextension=pdo_mysql.so[CLI Server]cli_server.color = On[Date][filter][iconv][imap][intl][sqlite3][Pcre][Pdo][Pdo_mysql]pdo_mysql.default_socket=[Phar][mail function]SMTP = localhostsmtp_port = 25mail.add_x_header = Off[ODBC]odbc.allow_persistent = Onodbc.check_persistent = Onodbc.max_persistent = -1odbc.max_links = -1odbc.defaultlrl = 4096odbc.defaultbinmode = 1[Interbase]ibase.allow_persistent = 1ibase.max_persistent = -1ibase.max_links = -1ibase.timestampformat = “%Y-%m-%d %H:%M:%S"ibase.dateformat = “%Y-%m-%d"ibase.timeformat = “%H:%M:%S”[MySQLi]mysqli.max_persistent = -1mysqli.allow_persistent = Onmysqli.max_links = -1mysqli.default_port = 3306mysqli.default_socket =mysqli.default_host =mysqli.default_user =mysqli.default_pw =mysqli.reconnect = Off[mysqlnd]mysqlnd.collect_statistics = Onmysqlnd.collect_memory_statistics = Off[OCI8][PostgreSQL]pgsql.allow_persistent = Onpgsql.auto_reset_persistent = Offpgsql.max_persistent = -1pgsql.max_links = -1pgsql.ignore_notice = 0pgsql.log_notice = 0[bcmath]bcmath.scale = 0[browscap][Session]session.save_handler = filessession.use_strict_mode = 0session.use_cookies = 1session.use_only_cookies = 1session.name = PHPSESSIDsession.auto_start = 0session.cookie_lifetime = 0session.cookie_path = /session.cookie_domain =session.cookie_httponly =session.cookie_samesite =session.serialize_handler = phpsession.gc_probability = 1session.gc_divisor = 1000session.gc_maxlifetime = 1440session.referer_check =session.cache_limiter = nocachesession.cache_expire = 180session.use_trans_sid = 0session.sid_length = 26session.trans_sid_tags = “a=href,area=href,frame=src,form=“session.sid_bits_per_character = 5[Assertion]zend.assertions = -1[COM][mbstring][gd][exif][Tidy]tidy.clean_output = Off[soap]soap.wsdl_cache_enabled=1soap.wsdl_cache_dir="/tmp"soap.wsdl_cache_ttl=86400soap.wsdl_cache_limit = 5[sysvshm][ldap]ldap.max_links = -1[dba][opcache][curl][openssl]添加Nginx的虚拟站点配置vhost.conf模板server {server_name {w:domains:w};{w:listenLines:w}set $websiteRoot “/data/www/{w:indexDirName:w}";root $websiteRoot;index index.html index.htm index.php;client_max_body_size {w:upload_max_filesize:w};client_body_buffer_size 128;location / {{w:rewriteContents:w}}location ~ .(php|phtml)$ {include fastcgi.conf;fastcgi_pass 127.0.0.1:9000;}location ~ /.ht {deny all;}}添加变量变量分为：环境变量、数据变量和扩展变量。在这里只需要添加扩展变量。环境变量：在操作系统中用来指定操作系统运行环境的一些参数，与平常使用的环境变量相同。有时容器启动需要设置一些参数提供给容器内部的程序。如：MySQL容器启动时可以设置MYSQL_ROOT和MYSQL_ROOT_PASSWORD。数据变量：添加存储数据时设置的一些参数。如：往MySQL数据服务添加数据库时，需要填写dbName，dbPassword，status，charset。具体可以使用可以创建MySQL服务，然后在管理数据库中添加数据库。扩展变量：即普通变量。如：上述在模板中设置的变量{w:upload_max_filesize:w}、{w:PHP_memory_limit:w}。变量的格式：{w:变量名:w}。添加PHP最大内存变量：PHP_memory_limit添加上传大小限制：upload_max_filesize至此，LMP应用已经制作完成，我们在应用管理列表中，选择刚才制作好的应用，点击创建服务部署完成后，地址栏输入域名访问一下，如果访问正常，说明我们制作的应用没有问题了，可以导出供他人安装！第六步：导出应用将我们制作的应用导出，可将导出的文件发布到任何地方，供他人安装使用，只要对方的主机安装了URLOS，都可以完美运行（无需考虑兼容性问题）我们制作的应用。导出的文件为txt文本。只要其他用户使用URLOS直接导即可。下面是导入方法：打开文本，全选复制其中内容登录ＵＲＬＯＳ，在左侧菜单点击导入应用，将内容粘贴进去，提交导入成功！！点击安装即可。哈哈，太爽了吧。任何服务器环境可以使用的应用都可以用这个方法来制作，比如微信小程序后端部分等等都可以这样制作，方便分发和安装。 ...

本文由云+社区发表作者：cocoding前言听到上下文切换，大家第一反应肯定是：一定要减少这货出现的次数。确实上下文切换对性能的影响显而易见，但有时又无法完全避免，这就要求我们对上下文性能损耗了然于胸，才能更准确地评估系统性能。另外，现在云厂商提供的机器种类如此之多，虚拟机在这方面是否有区别。以上都需要有科学的方法来衡量上下文的耗时，进而帮助系统评估以及机型选择。本文将从这以下两个方面来展开上下文切换有哪些类型以及可能出现的场景衡量各场景上下文切换耗时1， 上下文切换类型及场景上下文大体上可以分为两类进程上下文中断上下文进程上下文具体包括：（1）用户级上下文: 正文、数据、用户堆栈以及共享存储区；（2）寄存器上下文: 通用寄存器、程序寄存器(IP)、处理器状态寄存器(EFLAGS)、栈指针(ESP)；（3）系统级上下文: 进程控制块task_struct、内存管理信息(mm_struct、vm_area_struct、pgd、pte)、内核栈。中断上下文具体包括：（1）硬件传递过来的参数因此上下文切换可以分为以下几类：（1）进程之间的上下文切换：A进程切换到B进程（2）进程和中断之间的上下文切换：进程A被中断打断（3）中断之间的上下文切换：低级别中断被高级别中断打断其中第一种上下文切换最为常见，第二种次之，第三种最少见，因此本文接下来主要讨论前面两种上下文切换的耗时。模式切换这是要说一种特殊的上下文切换：模式切换，即进程A从用户态因为系统调用进入内核态，这种切换之所以特殊，是因为它并没有经过完整的上下文切换，只是寄存器上下文进行了切换，所以模式切换的耗时相对完整进程上下文更低。虽然模式切换较完整上下文切换耗少，但仍不能小觑，在物理机上，一次系统调用（以SYS_gettid为例）在5060ns。（本文所有数据均是Intel(R) Xeon(R) V4和V5 CPU上得到）而在虚拟机上，一次系统调用更是可能达到240ns ，从perf来看，system_call_after_swapgs函数消耗CPU较物理机多很多，网上有人说可能是为了解决Spectre漏洞，在每次系统调 用返回用户空间时，会清理一次BTB（branch target buffer），需要进一步确认。1.png因此，我们在代码里面也要尽量减少系统调用，常见的优化方法有：每次读写磁盘时，使用buffer减少read/write调用次数等。2，上下文切换性能评估测试上下文切换性能的工具有unixbenchtsuna/contextswitch两个工具的原理类似，都是创建两个进程，然后互相唤醒：（1） unixbench是创建两个进程，两个进程之间创建两个管道（pipe），通过管道来互相读写数据，结果是10s内完成的切换次数。（2） contextswitch同样是创建两个进程，通过futex（快速用户区互斥）来互相唤醒，结果是循环500000次的耗时进程之间的上下文切换使用这两个工具在测试进程上下文时，需要注意一点：把两个进程绑定到同一个核上运行，否则可能测试的就不仅仅是进程上下文切换了，下面会介绍不绑核的情况。unixbenchtaskset -c 1 ./Run -c 1 context1对于contextswitchtaskset -c 1 ./timectxsw或者直接运行make或者./cpubench.sh2.png从上图可以看到，一次ctx的耗时在10121263ns ，但其实perf看，绑核情况下，运行timectxsw实际的ctx是在300w次（这里一次循环需要6次ctx），所以实际的ctx应该是674842ns3.png进程和中断上下文切换上文提到如果要测试进程上下文切换耗时就一定要绑核，否则测试的很可能会包含进程和中断上下文切换的耗时，因为默认内核会把测试程序产生的进程调度到不同的核上，进程之间的唤醒，需要先发送IPI中断，对方CPU在收到IPI中断之后，会完成一次中断上下文切换，执行中断函数，进而再唤醒相应进程。所以在不绑核的情况下，测试的就包含了进程-中断上下文以及中断处理函数的耗时。4.pngunixbench 如果使用unixbench在腾讯云上，默认调度到1个核上，这样就测试的进程上下文切换，所以需要手动修改代码绑核，或者用git上的unixbench-fix，强制将两个进程放到不同的核上5.pngcontextswitch contextswitch这里还增加了在同一个NUMA上的测试，从测试数据看，两个进程如果调度到同一个NUMA上时，耗时会更短。6.png从测试数据看：如果两个进程跨NUMA，一次上下文切换的耗时在2500ns如果两个进程在同NUMA，一次上下文切换的耗时在1500ns在虚拟机里面，跨核的上下文切换会更大，因为vcpu无法处理IPI中断，需要退出的宿主机上处理，从而增加了上下文切换的耗时，总体上虚拟机跨核ctx的耗时是宿主机的23倍。下一篇文章我们会对IPI中断的测试方法以及虚拟化之后可能的优化方法进行介绍，欢迎订阅，及时查看。此文已由腾讯云+社区在各渠道发布获取更多新鲜技术干货，可以关注我们腾讯云技术社区-云加社区官方号及知乎机构号

一、概述前一篇文章讲解了 Kubernetes 亲和性调度, 所涉及的内容都是描述 pod 的属性，来声明此 pod 希望调度到哪类 nodes。而本文介绍的 Taint(污点) 刚好相反，它是node 的一个属性，允许 node 主动排斥 pod 的调度。对应的 k8s 又给 pod 新增了配套属性 toleration(容忍) ，用于表示这些 pod 可以（但不强制要求）被调度到具有相应 taints 的 nodes 上。这两者经常一起搭配，来确保不将 pod 调度到不合适的 nodes。看下 taint & toleration 结构体，下面足点介绍时会涉及相关字段。type Taint struct { Key string Value string Effect TaintEffect // add taint 的时间点 // 只有 Effect = NoExecute, 该值才会被 nodeController 写入 TimeAdded *metav1.Time}type Toleration struct { Key string Operator TolerationOperator Value string Effect TaintEffect // 容忍时间 TolerationSeconds *int64}type TaintEffect stringconst ( TaintEffectNoSchedule TaintEffect = “NoSchedule” TaintEffectPreferNoSchedule TaintEffect = “PreferNoSchedule” TaintEffectNoExecute TaintEffect = “NoExecute”)type TolerationOperator stringconst ( TolerationOpExists TolerationOperator = “Exists” TolerationOpEqual TolerationOperator = “Equal”)二、Taint我们可以对 node 设置多个 taints，当然也可以在 pod 配置相同个数的 tolerations。影响调度和运行的具体行为，我们可以分为以下几类：如果至少有一个 effect == NoSchedule 的 taint 没有被 pod toleration，那么 pod 不会被调度到该节点上。如果所有 effect == NoSchedule 的 taints 都被 pod toleration，但是至少有一个 effect == PreferNoSchedule 没有被 pod toleration，那么 k8s 将努力尝试不把 pod 调度到该节点上。如果至少有一个 effect == NoExecute 的 taint 没有被 pod toleration，那么不仅这个 pod 不会被调度到该节点，甚至这个节点上已经运行但是也没有设置容忍该污点的 pods，都将被驱逐。三、Toleration再看下 PodSpec 配置 Tolerations，其中的 key、value、effect 与 Node Taint 设置需要保持一致，operator 支持两类:Exists: 这个配置下，不需要指定 value。Equal: 需要配置 value 值。(operator 的默认值)有几个特殊情况:key 为空并且 operator 等于 Exists，表示匹配了所有的 keys，values 和 effects。换句话说就是容忍了所有的 taints。tolerations:- operator: “Exists"effect 为空，则表示匹配所有的 effects（NoSchedule、PreferNoSchedule、NoExecute）tolerations:- key: “key” operator: “Exists"还有一个 TolerationSeconds，该值与 effect 为 NoExecute 配套使用。用来指定在 node 添加了 effect = NoExecute 的 taint 后，能容忍该 taint 的 pods 可停留在 node 上的时间。例如:tolerations: - key: “key1” operator: “Equal” value: “value1” effect: “NoExecute” tolerationSeconds: 3600表示如果这个 pod 已经运行在 node 上并且该 node 添加了一个对应的 taint，那么这个 pod 将会在 node 上停留 3600 秒后才会被驱逐。但是如果 taint 在这个时间前被移除，那么这个 pod 也就不会被驱逐了。来个比较形象的图，描述下：该图参考: Taints and tolerations, pod and node affinities demystified · Banzai Cloud四、内置行为kubernetes 1.6 版本，node controller 会跟进系统情况自动设置 node taint 属性。内置 taint key 如下:node.kubernetes.io/not-ready: 节点尚未就绪node.kubernetes.io/unreachable: 节点无法被访问node.kubernetes.io/unschedulable: 节点不可调度node.kubernetes.io/out-of-disk: 节点磁盘不足node.kubernetes.io/memory-pressure: 节点有内存压力node.kubernetes.io/disk-pressure: 节点有磁盘压力node.kubernetes.io/network-unavailable: 节点网络不可用node.kubernetes.io/pid-pressure: 节点有 pid 压力node.cloudprovider.kubernetes.io/uninitialized: 云节点未初始化node.cloudprovider.kubernetes.io/shutdown: 云节点已下线kubernetes 会通过 DefaultTolerationSeconds admission controller 为创建的 pod 添加两个默认的 toleration: node.kubernetes.io/not-ready 和 node.kubernetes.io/unreachable，并且设置 tolerationSeconds = 300。当然这个默认配置，用户可以自行覆盖。这些自动添加的默认配置，确保 node 出现问题后，pod 可以继续在 node 上停留 5 分钟。DefaultTolerationSeconds admission controller 设置的 tolerationSeconds 值，也可以由用户指定。具体参考: https://github.com/kubernetes…还有一个默认行为，就是 DaemonSet。所有 DaemonSet 创建的 pod 都会添加两个 toleration: node.alpha.kubernetes.io/unreachable 和 node.alpha.kubernetes.io/notReady。设置 effect = NoExecute，并且不指定 tolerationSeconds。目的是确保在 node 出现 unreachable 或 notReady 的问题时，DaemonSet Pods 永远不会被驱逐。示例专用节点如果你希望将一组节点专用于特定的用户，那可以将这些节点设置 taints: kubectl taint nodes nodename dedicated=groupName:NoSchedule, 然后为 pods 设置对应的 tolerations。如果你希望节点被专用并且确保服务仅使用这批节点，那么你还应该向这批节点设置 labels (dedicated=groupName)，并且为对应的 pods 设置 NodeAffinity，以控制 pods 只能跑到这批节点上。具有特殊硬件的节点有部分带有特殊硬件的节点，比如 GPU、FPGA 等，要确保不将不需要专用硬件的 pods 调度到这些节点。也可以和 专有节点 一样的方式设置 taints：kubectl taint nodes nodename special=true:NoSchedule 或 kubectl taint nodes nodename special=true:PreferNoSchedule。建议还可以通过 Extended Resources 和 ExtendedResourceToleration admission controller 来更方便的调度依赖特殊硬件的 pods，而不需要手动添加容器的 toleration基于 taint 的驱逐前面也提到了，可以通过 NoExecute taint 来驱逐节点上已经运行的 pods。五、参考资料community/taint-toleration-dedicated.md at master · kubernetes/community · GitHubcommunity/taint-node-by-condition.md at master · kubernetes/community · GitHubTaints and TolerationsTaints and tolerations, pod and node affinities demystified · Banzai Cloud ...

作者：Diane Mueller，红帽云平台社区发展总监开发者和Kubernetes管理员面临的重要挑战之一，是缺乏快速查找在Kubernetes提供运营就绪的公共服务的能力。通常情况下，存在特定服务的Operator - 这种模式在2016年推出并获得了动力 - 对于Kubernetes服务的运营就绪是一个很好的信号。但是，迄今为止还没有Operator注册表来简化发现此类服务。为了帮助应对这一挑战，今天Red Hat与AWS、Google Cloud和Microsoft合作推出OperatorHub.io。OperatorHub.io使开发者和Kubernetes管理员能够查找和安装策划好的、Operator支持的服务，其中包括基础文档、社区或供应商的主动维护、基本测试以及Kubernetes优化生命周期管理的打包。目前在OperatorHub.io中的Operator只是开始。我们邀请Kubernetes社区加入我们，通过在OperatorHub.io上开发、打包和发布Operator，为Operator建立一个充满活力的社区。OperatorHub.io提供什么？OperatorHub.io旨在满足Kubernetes开发者和用户的需求。对于前者，它提供了通用的注册表，他们可以在其中发布他们的Operator以及描述、相关的详细信息，如版本、镜像、代码仓库，并打包准备方便安装。他们也可以对已发布的Operator发布更新版本。用户可以在一个中心位置发现和下载Operator，该Operator的内容已根据前面提到的标准进行筛选并扫描已知漏洞。此外，开发者可以使用他们引入的CustomResources的说明性示例，指导其Operator的用户，与应用程序进行交互。Operator是什么？Operator最初由CoreOS于2016年推出，并已被Red Hat和Kubernetes社区用作打包、部署和管理Kubernetes原生应用程序的方法。Kubernetes原生应用程序是一个部署在Kubernetes上的应用程序，使用Kubernetes API和众所周知的工具进行管理，如kubectl。Operator实现为自定义控制器，用于监视某些Kubernetes资源的显示、修改或删除。这些通常是Operator“拥有”的CustomResourceDefinition。在这些对象的spec属性中，用户声明应用程序或操作的所需状态。Operator的协调循环将选择这些，并执行所需的操作以实现所需的状态。例如，可以通过创建EtcdCluster类型的新资源，来表达创建高可用性etcd集群的意图：apiVersion: “etcd.database.coreos.com/v1beta2"kind: “EtcdCluster"metadata: name: “my-etcd-cluster"spec: size: 3 version: “3.3.12"这样，EtcdOperator将负责创建运行版本v3.3.12的3节点etcd集群。类似地，可以定义类型为EtcdBackup的对象，以表示创建etcd数据库一致备份到S3存储桶的意图。如何创建和运行Operator？一种入门方法是使用Operator框架，这是一个开源工具包，提供SDK、生命周期管理、计量和监视功能。它使开发者能够构建、测试和打包Operator。Operator可以用几种编程和自动化语言实现，包括Go、Helm和Ansible，这三种语言都直接由SDK支持。如果你有兴趣创建自己的Operator，我们建议你查看Operator框架以开始使用。Operator的功能范围各不相同，从基本功能到应用程序的特定操作逻辑，以及备份、恢复或调整等高级方案的自动化。除了基本安装之外，高级Operator可以更加无缝地处理升级并自动应对故障。目前，OperatorHub.io上的Operator来自不同成熟度范围，但我们预计它们会随着时间而持续成熟。虽然不需要使用SDK实现OperatorHub.io上的Operator，但它们是打包给通过Operator Lifecycle Manager（OLM）进行部署。格式主要由称为ClusterServiceVersion的YAML清单组成。它提供有关Operator拥有或要求的CustomResourceDefinitions的信息、所需的RBAC定义、存储图像的位置等。此文件通常附带定义Operator自己的CRD的其他YAML文件。OLM在用户请求安装Operator以提供依赖性解析和自动化时处理此信息。OperatorHub.io上的Operator列表是什么意思？要列出，Operator必须成功显示群集生命周期功能，打包为CSV并通过OLM维护，以及为其预期用户提供可接受的文档。目前在OperatorHub.io上列出的Operator的一些示例包括：Amazon Web Services Operator、Couchbase Autonomous Operator、CrunchyData’s PostgreSQL、etcd Operator、Jaeger Operator for Kubernetes、Kubernetes Federation Operator、MongoDB Enterprise Operator、Percona MySQL Operator、PlanetScale’s Vitess Operator、Prometheus Operator和Redis Operator。想要将你的Operator添加到OperatorHub.io？跟着这些步骤如果你有现有的Operator，请遵循贡献指南使用社区Operator仓库的分支。每个贡献包含CSV、所有CustomResourceDefinitions、访问控制规则以及安装和运行Operator所需的容器映像的资料，其功能描述和支持的Kubernetes版本等其他信息。EtcdOperator可以作为完整的示例，包括Operator的多个版本。在你自己的集群上测试Operator之后，将PR提交到社区存储库，其中包含此目录结构的所有YAML文件。可以以相同的方式发布Operator的后续版本。刚开始这将是手动审查，但往后会自动化。由维护者合并之后，它将显示在OperatorHub.io上，以及其文档和方便的安装方法。想了解更多？参加即将举行的Kubernetes Operator框架实践研讨会：3月7日在Pasadena的ScaleX举行，以及3月11日在Santa Clara的OpenShift Commons Gathering on Operating举行听听Daniel Messer和Diane Mueller关于“Operator现况”的OpenShift Commons简报加入社区Kubernetes-Operator Slack Channel和Operator框架Google Group的在线对话最后，阅读如何将你的Operator添加到OperatorHub.io：https://operatorhub.io/contri…KubeCon + CloudNativeCon和Open Source Summit大会日期：会议日程通告日期：2019 年 4 月 10 日会议活动举办日期：2019 年 6 月 24 至 26 日KubeCon + CloudNativeCon和Open Source Summit赞助方案KubeCon + CloudNativeCon和Open Source Summit多元化奖学金现正接受申请KubeCon + CloudNativeCon和Open Source Summit即将首次合体落地中国KubeCon + CloudNativeCon和Open Source Summit购票窗口，立即购票！ ...

今年的第一篇文章更新，带来一个重大的消息。CNCF（云原生计算基金会）在美国时间 2019 年 2 月 28 日宣布 containerd 今天正式毕业了。这是 CNCF 中毕业的第 5 个项目，之前已经毕业的项目为 Kubernetes、Prometheus、Envoy 和 CoreDNS 。containerd 2014 年从 Docker 孵化出来，最初是作为 Docker 引擎的底层管理器；在 2017 年 3 月被 CNCF 接受后，containerd 几乎成为了行业容器运行引擎的标准，它专注于简单，健壮和可移植性，任何人都可以使用它来构建自己的容器引擎/平台。“When Docker contributed containerd to the community, our goal was to share a robust and extensible runtime that millions of users and tens of thousands of organizations have already standardized on as part of Docker Engine,” said Michael Crosby, containerd maintainer and Docker engineer.截至目前，containerd 的 GitHub 项目有 3533 个 Star ；221 个 Watch 和 726 个 Fork，贡献者超过了 166 位。相信在之后也会发展的更好。下面附上 containerd 的架构图，以后会更新关于 containerd 相关原理的文章。再次恭喜 containerd 毕业。可以通过下面二维码订阅我的文章公众号【MoeLove】 ...