kubernetes 云平台_kubernetes云平台 - CSDN
  • 本文个人博客地址为:http://www.huweihuang.com/article/kubernetes/paas-based-on-docker&kubernetes/本文个人博客地址为:...kubernetes/【编者的话】目前很多的容器云平台通过Doc...

    本文个人博客地址为http://www.huweihuang.com/article/kubernetes/paas-based-on-docker&kubernetes/

    本文个人博客地址为https://huweihuang.net/article/kubernetes/paas-based-on-docker&kubernetes/


    【编者的话】

    目前很多的容器云平台通过Docker及Kubernetes等技术提供应用运行平台,从而实现运维自动化,快速部署应用、弹性伸缩和动态调整应用环境资源,提高研发运营效率。

    从宏观到微观(从抽象到具体)的思路来理解:云计算→PaaS→ App Engine→XAE[XXX App Engine] (XAE泛指一类应用运行平台,例如GAE、SAE、BAE等)。

    本文简要介绍了与容器云相关的几个重要概念:PaaS、App Engine、Docker、Kubernetes。

    1. PaaS概述

    1.1. PaaS概念

    1. PaaS(Platform as a service),平台即服务,指将软件研发的平台(或业务基础平台)作为一种服务,以SaaS的模式提交给用户。
    2. PaaS是云计算服务的其中一种模式,云计算是一种按使用量付费的模式的服务,类似一种租赁服务,服务可以是基础设施计算资源(IaaS),平台(PaaS),软件(SaaS)。租用IT资源的方式来实现业务需要,如同水力、电力资源一样,计算、存储、网络将成为企业IT运行的一种被使用的资源,无需自己建设,可按需获得。
    3. PaaS的实质是将互联网的资源服务化为可编程接口,为第三方开发者提供有商业价值的资源和服务平台。简而言之,IaaS就是卖硬件及计算资源,PaaS就是卖开发、运行环境,SaaS就是卖软件

    1.2. IaaS/PaaS/SaaS说明

     

    类型
    说明
    比喻
    例子
    IaaS:Infrastructure-as-a-Service(基础设施即服务)提供的服务是计算基础设施地皮,需要自己盖房子Amazon EC2(亚马逊弹性云计算)
    PaaS: Platform-as-a-Service(平台即服务)提供的服务是软件研发的平台或业务基础平台商品房,需要自己装修GAE(谷歌开发者平台)
    SaaS: Software-as-a-Service(软件即服务)提供的服务是运行在云计算基础设施上的应用程序酒店套房,可以直接入住谷歌的Gmail邮箱

     

    1.3. PaaS的特点(三种层次)

    特点
    说明
    平台即服务PaaS提供的服务就是个基础平台,一个环境,而不是具体的应用
    平台及服务不仅提供平台,还提供对该平台的技术支持、优化等服务
    平台级服务“平台级服务”即强大稳定的平台和专业的技术支持团队,保障应用的稳定使用

    2. App Engine概述

    2.1. App Engine概念

    App Engine是PaaS模式的一种实现方式,App Engine将应用运行所需的 IT 资源和基础设施以服务的方式提供给用户,包括了中间件服务、资源管理服务、弹性调度服务、消息服务等多种服务形式。App Engine的目标是对应用提供完整生命周期(包括设计、开发、测试和部署等阶段)的支持,从而减少了用户在购置和管理应用生命周期内所必须的软硬件以及部署应用和IT 基础设施的成本,同时简化了以上工作的复杂度。常见的App Engine有:GAE(Google App Engine),SAE(Sina App Engine),BAE(Baidu App Engine)。

    App Engine利用虚拟化与自动化技术实现快速搭建部署应用运行环境和动态调整应用运行时环境资源这两个目标。一方面实现即时部署以及快速回收,降低了环境搭建时间,避免了手工配置错误,快速重复搭建环境,及时回收资源, 减少了低利用率硬件资源的空置。另一方面,根据应用运行时的需求对应用环境进行动态调整,实现了应用平台的弹性扩展和自优化,减少了非高峰时硬件资源的空置。

    简而言之,App Engine主要目标是:Easy to maintain(维护), Easy to scale(扩容), Easy to build(构建)。

    2.2. 架构设计

     

    2.3. 组成模块说明

    组成模块
    模块说明
    App Router[流量接入层]接收用户请求,并转发到不同的App Runtime。
    App Runtime[应用运行层]应用运行环境,为各个应用提供基本的运行引擎,从而让app能够运行起来。
    Services[基础服务层]各个通用基础服务,主要是对主流的服务提供通用的接入,例如数据库等。
    Platform Control[平台控制层]整个平台的控制中心,实现业务调度,弹性扩容、资源审计、集群管理等相关工作。
    Manage System[管理界面层]提供友好可用的管理操作界面方便平台管理员来控制管理整个平台。
    Platform Support[平台支持层]为应用提供相关的支持,比如应用监控、问题定位、分布式日志重建、统计分析等。
    Log Center[日志中心]实时收集相关应用及系统的日志(日志收集),提供实时计算和分析平台(日志处理)。
    Code Center[代码中心]完成代码存储、部署上线相关的工作。

    3. 容器云平台技术栈

    功能组成部分
    使用工具
    应用载体Docker
    编排工具Kubernetes
    配置管理Etcd
    网络管理Flannel
    存储管理Ceph
    底层实现Linux内核的Namespace[资源隔离]和CGroups[资源控制]
    • Namespace[资源隔离]
      Namespaces机制提供一种资源隔离方案。PID,IPC,Network等系统资源不再是全局性的,而是属于某个特定的Namespace。每个namespace下的资源对于其他namespace下的资源都是透明,不可见的。
    • CGroups[资源控制]
      CGroup(control group)是将任意进程进行分组化管理的Linux内核功能。CGroup本身是提供将进程进行分组化管理的功能和接口的基础结构,I/O或内存的分配控制等具体的资源管理功能是通过这个功能来实现的。CGroups可以限制、记录、隔离进程组所使用的物理资源(包括:CPU、memory、IO等),为容器实现虚拟化提供了基本保证。CGroups本质是内核附加在程序上的一系列钩子(hooks),通过程序运行时对资源的调度触发相应的钩子以达到资源追踪和限制的目的。

    4. Docker概述

    更多详情请参考:Docker整体架构图

    4.1. Docker介绍

    1. Docker - Build, Ship, and Run Any App, Anywhere
    2. Docker是一种Linux容器工具集,它是为“构建(Build)、交付(Ship)和运行(Run)”分布式应用而设计的。
    3. Docker相当于把应用以及应用所依赖的环境完完整整地打成了一个包,这个包拿到哪里都能原生运行。因此可以在开发、测试、运维中保证环境的一致性。
    4. Docker的本质:Docker=LXC(Namespace+CGroups)+Docker Images,即在Linux内核的Namespace[资源隔离]和CGroups[资源控制]技术的基础上通过镜像管理机制来实现轻量化设计。

    4.2. Docker的基本概念


    4.2.1. 镜像

    Docker 镜像就是一个只读的模板,可以把镜像理解成一个模子(模具),由模子(镜像)制作的成品(容器)都是一样的(除非在生成时加额外参数),修改成品(容器)本身并不会对模子(镜像)产生影响(除非将成品提交成一个模子),容器重建时,即由模子(镜像)重新制作成一个成品(容器),与其他由该模子制作成的成品并无区别。

    例如:一个镜像可以包含一个完整的 ubuntu 操作系统环境,里面仅安装了 Apache 或用户需要的其它应用程序。镜像可以用来创建 Docker 容器。Docker 提供了一个很简单的机制来创建镜像或者更新现有的镜像,用户可以直接从其他人那里下载一个已经做好的镜像来直接使用。

    4.2.2. 容器

    Docker 利用容器来运行应用。容器是从镜像创建的运行实例。它可以被启动、开始、停止、删除。每个容器都是相互隔离的、保证安全的平台。可以把容器看做是一个简易版的 Linux 环境(包括root用户权限、进程空间、用户空间和网络空间等)和运行在其中的应用程序。

    4.2.3. 仓库

    仓库是集中存放镜像文件的场所。有时候会把仓库和仓库注册服务器(Registry)混为一谈,并不严格区分。实际上,仓库注册服务器上往往存放着多个仓库,每个仓库中又包含了多个镜像,每个镜像有不同的标签(tag)。

    4.3. Docker的优势

     

    1. 容器的快速轻量

      容器的启动,停止和销毁都是以秒或毫秒为单位的,并且相比传统的虚拟化技术,使用容器在CPU、内存,网络IO等资源上的性能损耗都有同样水平甚至更优的表现。

    2. 一次构建,到处运行

      当将容器固化成镜像后,就可以非常快速地加载到任何环境中部署运行。而构建出来的镜像打包了应用运行所需的程序、依赖和运行环境, 这是一个完整可用的应用集装箱,在任何环境下都能保证环境一致性。

    3. 完整的生态链

      容器技术并不是Docker首创,但是以往的容器实现只关注于如何运行,而Docker站在巨人的肩膀上进行整合和创新,特别是Docker镜像的设计,完美地解决了容器从构建、交付到运行,提供了完整的生态链支持。

    5. Kubernetes概述

    更多详情请参考:Kubernetes总架构图

    5.1. Kubernetes介绍

    Kubernetes是Google开源的容器集群管理系统。它构建Docker技术之上,为容器化的应用提供资源调度、部署运行、服务发现、扩容缩容等整一套功能,本质上可看作是基于容器技术的Micro-PaaS平台,即第三代PaaS的代表性项目。

    5.2. Kubernetes的基本概念

    5.2.1. Pod

    Pod是若干个相关容器的组合,是一个逻辑概念,Pod包含的容器运行在同一个宿主机上,这些容器使用相同的网络命名空间、IP地址和端口,相互之间能通过localhost来发现和通信,共享一块存储卷空间。在Kubernetes中创建、调度和管理的最小单位是Pod。一个Pod一般只放一个业务容器和一个用于统一网络管理的网络容器。

    5.2.2. Replication Controller

    Replication Controller是用来控制管理Pod副本(Replica,或者称实例),Replication Controller确保任何时候Kubernetes集群中有指定数量的Pod副本在运行,如果少于指定数量的Pod副本,Replication Controller会启动新的Pod副本,反之会杀死多余的以保证数量不变。另外Replication Controller是弹性伸缩、滚动升级的实现核心。

    5.2.3. Service

    Service是真实应用服务的抽象,定义了Pod的逻辑集合和访问这个Pod集合的策略,Service将代理Pod对外表现为一个单一访问接口,外部不需要了解后端Pod如何运行,这给扩展或维护带来很大的好处,提供了一套简化的服务代理和发现机制。

    5.2.4. Label

    Label是用于区分Pod、Service、Replication Controller的Key/Value键值对,实际上Kubernetes中的任意API对象都可以通过Label进行标识。每个API对象可以有多个Label,但是每个Label的Key只能对应一个Value。Label是Service和Replication Controller运行的基础,它们都通过Label来关联Pod,相比于强绑定模型,这是一种非常好的松耦合关系。

    5.2.5. Node

    Kubernets属于主从的分布式集群架构,Kubernets Node(简称为Node,早期版本叫做Minion)运行并管理容器。Node作为Kubernetes的操作单元,将用来分配给Pod(或者说容器)进行绑定,Pod最终运行在Node上,Node可以认为是Pod的宿主机。

    5.3. Kubernetes架构


    展开全文
  • “中国-东盟信息港”是按照国家“一带一路”倡议总体布局要求、建设更为紧密...东信基于Rancher Kubernetes架构和建设了他们的容器PaaS平台,在原生、容器化、微服务、CICD、DevOps等方面的都有了相关实践和应用。

    “中国-东盟信息港”是按照国家“一带一路”倡议总体布局要求、建设更为紧密的中国—东盟命运共同体、21世纪海上丝绸之路的一个信息平台:caih.com。东信基于Rancher Kubernetes架构和建设了他们的容器云PaaS平台,在云原生、容器化、微服务、CICD、DevOps等方面的都有了相关实践和应用。6月28日,负责中国东信容器云PaaS 平台的研发和建设、中国-东盟信息港的研发总监王志雄出席了Rancher Labs举办的Container Day 2018容器技术大会,并做了题为《中国东信基于Kubernetes的容器云PaaS平台》的主题演讲,本文根据演讲内容整理而成。王志雄,中国-东盟信息港研发总监,负责中国东信公司容器云的研发和管理工作。硕士,曾就职于IBM、华为等公司,在IBM时任研发部门经理、技术专家。10年以上的云计算IaaS、PaaS、容器云、SDN/NFV、微服务、DevOps等研发经验。各位来宾,各位朋友,大家上午好,我是来自中国-东盟信息港的王志雄,在中国东信负责容器云PaaS 平台的研发和建设。今天我从技术角度、就如下四个方面,给大家分享中国东信基于Kubernetes建设容器云PaaS平台的经验。

    第一个是PaaS平台,PaaS平台在云计算刚出现的时候就已经和IaaS、SaaS已经共存了,但是刚开始只是不温不火,为什么到这几年PaaS平台才这么火了呢?如何来建设一个PaaS台?PaaS平台需要哪些技术内容来承载?我会在这里做一个分享。第二个是微服务,微服务我们说有两条路线,第一条是SpringCloud,第二条是Kubernetes,我们来看一看怎么使用Kubernetes来构建一个微服务的平台。第三个是CICD ,第四个是DevOps。我们会看到有些场合说的CICD,有的场合说的DevOps,这二者有什么关系,有什么区别,如何来构建CICD 和DevOps,我会在这里做一个揭晓。

    Kubernetes与容器云PaaS平台

    我们首先来看一下Kubernetes与容器云平台。Kubernetes这个PaaS平台要解决三个方面的IT架构方面的问题。第一,耦合,我们做研发的知道,除了应用程序之外,不管Java,还是Go,还是Python,都需要大量的应用配置,这些配置和我们的系统环境——Windows也好,Linux也好——都是耦合的,所以会经常出现我们在交付产品的时候,明明在研发的环境可用的,到了测试不可用,到了最后的生产发布也不可用,从而出现这样的神秘的BUG、神秘的配置。之前有人提出一个比较好的方法是写一个很好的文档以供参考,但是文档通常还是会遗漏,而且这还要依赖于我们人员写文档的能力,以及理解的能力。第二个,繁杂,现在不论是技术、工具还是语言都非常繁杂,例如语言有java、有Go、有python、有php。第三个,不灵活,我们现在互联网时代是需要从按周发布,提升为按天发布,甚至一天几次、十几次甚至上百次发布,这在以前的物理机或者虚拟机时代是不可能的。

    所以如何来解决这些问题?Cloud Native是这个答案。Cloud Native能做到什么呢?第一是容器化,把应用以及它的配置打包,保证开发、测试和运维的环境一致,从而避免神秘的配置、神秘的错误、神秘的文档、还有可能是神秘的人。第二是面向微服务,把以前的一体的区域式服务给分解为微服务,从而更灵活,并可以独立更新。第三方面是动态编排管理,如果容器很多,则需要大量的配置文件,需要部署很多容器则必然要用到编排管理,也就是我们在此选择的Kubernetes。

    下图是中国东信基于Kubernetes、Docker研发的四大场景。第一是企业应用平台,企业应用平台可以将应用在平台上做到一键部署,利用pod auto-scaling进行弹性自动伸缩,如果出现故障则可以通过health check实现故障自愈,另外还有强大的灰度发布功能。之前的互联网公司可能需要一个非常大的团队来做灰度发布,如今使用Kubernetes,Kubernetes已经自带灰度发布功能了。第二个是我们的微服务,用Kubernetes来构建我们的微服务平台,构建之后我们就可以组件化、松耦合、去中心,而且是灵活独立的。第三个我们做了这样一套CICD的系统,CICD的系统从我们的开发、从代码提交、从编译到构建到自动化测试、到容器化发布。第四个是DevOps ,DevOps是可以做到开发运维的协同。

    这是我们中国东信的PaaS 平台,我们从最底层看起,最底层是容器云的Infra,我们说Infra不是IaaS产品吗?其实不管是IaaS还是PaaS 都需要Infrastructure,当然它们是有区别的。我们不管做Iass做PaaS ,其中的难点归到最后其实都是存储和网络,我在后面会分享存储网络我们是怎么做的。再上来是容器资源管理,以及容器集群编排与调度,需要把这个Pod调度到众多集群节点中的哪一个?根据什么策略来调度?根据CPU调度还是根据内存调度?根据亲和策略还是反亲和策略?再上来是我们容器云应用Service,我们说PaaS 平台是以应用为中心,所以肯定需要这样一个强大的应用Service,PaaS平台应用的Service有服务发现、配置中心、负载均衡、弹性伸缩、服务编排这样一些强大的功能,那么就用我们的PaaS平台,上面我们会提供中间件、数据库、负载均衡、文件存储等等。如果需要哪一个,比如需要一个MySQL ,把一个MySQL容器拿过去用就可以了。再去用我们的中间件,PaaS平台上面就承载我们庞大的、灵活的企业应用。

    如果研发过Kubernetes应该对这个图很熟悉,这是个典型的Kubernetes集群,我们分两个层面来看。第一个层面一个是我们自己内部的管理,部署Service,Service都是通过Master进行来管理,通过API Server来和各个组件进行交互,用Controller Mananger来控制我们各个组件获得的调度,Scheduler是具体的应用策略,etcd 是一个数据库。那么会调度到我们的Node上,Node上存在我们的Pod ,一个Pod里可以有可以有多个Container,这是我们的内部的管理提供Service。第二个层面是我们从外部的访问,外部的访问一般就是通过Internet经过防火墙来访问我们对外提供一个ingress ,ingress是Kubernetes提供的一个非常强大的功能,有了ingress 之后,我们可以对外提供一个统一的域名系统,外部只要访问我们的统一域名,就可以访问我们内部的不同的应用,通过此域名就可以进行智能的分发。

    上面我们说的叫物理架构,而下面我会讲讲逻辑架构,这两个的关注面不一样。逻辑架构从我们研发内部看,最底层是容器基础设施层,包括我们的Runtime、Volume Plugin、Network Plugin;再上来是核心层,核心层对外提供API,对内提供Plugin环境;第三层是应用层,可以进行部署,可以进行ingress智能路由;再上来是管理层,可以进行智能化以及Network policy;接口层是对外提供我们的命令行管理工具;Ecosystem是我们的生态。

    刚才说PaaS的基础架构的终极难题是网络和存储。我们先来看一下中国东信是怎么解决网络问题的。网络的方案非常多,我们看到有单组区域的,开始是单组区域有bridge、host、container、NAT,也有原生的iptables;再上来有主机集群,有OVS,有IPSec;现在最主流的就是最上面一行,一个是Flannel,一个是calico,还有将这两个折在一起的Canal。这里我可以提一下我们的SDN(软件定义网络)。SDN起源于Openflow,什么是Openflow?Openflow是有强大的报文解析能力,可以对报文进行任意的更改,这个强大的能力刚问世时取得了瞩目的关注,并且在当年被评为未来10大创新技术的排名第二位,第一位是云计算,第二位是SDN。但最初Openflow在问世后的广大的应用中碰到了一些问题,因为它和以前传统的不兼容,所以实际上最后被应用最多的是VXLAN。VXLAN是一个overlay的技术。SDN在应用最多的是什么?是VXLAN overlay。第三个是BGP,BGP在网络中应该有二三十年的历史,经过不断地打磨、沉淀、优化,实际上BGP已经开始统一我们的SDN领域了,现在BGP已经可以取代我们的软件定义网络,虚拟化的网络。

    SDN网络通用的两个方向,第一个是Flannel,Flannel其实本质上是一个Overlay的方案,所以在主机的容器内是自动分布的IP,只是在主机之外,做了一个Overlay叠加的封装,但这个Overlay和我们传统的IaaS的overlay相比其实是不一样的,传统的IaaS的VXLAN除了Overlay的功能,还有多租户的功能,但是这里因为它只在出口做了个封装,所以没有多租户的功能。所以Flannel有什么缺点?它没有安全隔离的功能。第二个它封包解包必然带来开销,所以这个是我们要解决的问题。Flannel官方也表示如果用户想对数据中心做更好的网络安全隔离,推荐用Calico。

    Calico的核心是基于BGP,如果是小网络可以用BGP的client进行IP路由的自动分发以及路由互联。Calico的好处是什么?简单!若是使用Overlay网络出现故障,用户难以排查故障是来自overlay还是underlay;但用BGP,用户直接定位路由就好了。此外,Calico还带了一个很好的特性就是和network policy结合在一起,可以提供网络的微分段,若一个主机上有多个容器、有多个应用,可以提供很好的安全隔离。Calico的不足是什么?它需要取决于数据中心对于BGP的支持力度,可能现在还不是所有数据中心都是BGP。但我还是推荐BGP的,从最初的的Facebook到现在国内的大公司,很多都已经开使用BGP来取代所有的内部的路由协议,包括二层协议。这是一个很好的方案,可以简化运维工作,数据中心只有一种路由协议多好。

    谈完网络,另一个难题就是存储。Kubernetes和Docker相比除了普通的volume之外,还提供了persistent volume和storage class,通过PV和PVC来抽象存储细节。这有什么好处?可以做到管理控制与转化分离。管理员关注PV的存储细节,用户只要关注PVC使用存储就好了。通用的存储ceph、NFS、Gluster都没问题。

    容器云微服务

    下面我们来看一下怎样用Kubernetes来构建一个微服务。下图是我们很熟悉的微服务架构的特性,把一个单体的应用来分解拆分为多个灵活的微服务。微服务的特性是服务的组件化。怎样拆分一个微服务?不是按代码的行数,不是按函数,而是按功能、按产品模式来拆分。有了微服务就可以去中心化的管理。

    构建微服务,必然要有如下这些功能:有这么多的服务,怎样发现这个服务?所以要服务发现。多个服务如何做到负载均衡?多个应用service怎么样进行智能的路由分发?怎样管理成千上万个服务的配置?怎样弹性伸缩?怎样容错?怎样自动升级?访问控制怎么做?

    下图就是我们使用Kubernetes来构建的微服务。怎样来构建?把上述问题的答案汇聚在一起就是最终答案了。第一个服务发现,使用我们的service,包括我们Kubernetes内置的DNS就可以来做这样一个服务发现。第二个负载均衡,有node上的kube-proxy加上我们的service分发是负载均衡。第三个智能路由,通过ingress可以智能地将不同的应用通过统一的入口分发到后端的服务。配置中心通过我们的Kubernetes的config-map,可以在一个统一的服务器上进行远端多个微服务的配置的统一管理、统一更新。明文用config-map,如果重要的机密的配置可以secret。

    再接下来是我们的服务编排,deployment是实际使用过程中用户非常欢迎的一个特性。因为deployment把这个yaml文件写好之后,大家去自动部署了,需要几个副本,它会自动的去扩容以及缩容deployment。如果需要开发一个应用商店,可以去helm开发。

    再下来是我们的弹性伸缩,通过RS写好副本数,再通过auto-scaling指定需要自动伸缩的条件,比如说可以基于CPU伸缩,可以基于我们的内存访问伸缩。再下来是我们的容错,使用我们的liveness来监控我们的容器以及应用的健康状况,如果容器挂掉了,可以把它重启,如果这个节点挂掉了,那就把容器调度到另一个节点。熔断怎么做?可以用我们的readiness,readiness不但可以监控我们的容器的存活,还可以监控我们的service是否是健康的。

    限流,限流可以通过我们的quota限额,可以通过我们的namespace限额,也可以对我们的pod限额,也可以对容器限额。

    升级,rolling updates是自动升级,有问题可以一键回滚。那RBAC是可以提供基于角色的安全访问。Network policy在BGP Calico基础上提供微分段,可以很好的安全隔离,包括日志监控EFK和Prometheus。

    容器云CI/CD

    如何来做容器云的CI/CD,自然使用我们的容器云三剑客,Jenkins+Docker+Kubernetes。其实在容器云出现之前,其实已经有CI/CD了,那时CI/CD用Jenkins做,Jenkins可以提供编译、构件、测试、任务调度的流水线;那Docker有什么作用?可以让我们的环境标准化,可以隔离;Kubernetes可以提供一个大的平台,可以让资源共享、弹性伸缩。

    CI/CD也就是需要把开发、测试流水线做一个自动化,从开发、编译、构件、测试、打包到部署,所以在我们的测试报告出来之后,如果是通过了就把镜像上传到镜像仓库,然后再发布到Kubernetes的发布平台。

    DevOps

    谈完CI/CD我们来看一下很火的DevOps。通过这张图我们其实就可以看出CI/CD和DevOps有什么区别,有什么联系,什么场合该用CI/CD,什么场合该用DevOps。CI/CD在左边,CI/CD最关注的是开发和测试,关注的具体的序数是什么?是Jenkins来做个流水线,是Git来做一个源代码的仓库、源代码的拉取,Maven来做构建,SonarQube来做静态的代码分析,Robotframework来做自动化的测试。SonarQube这样一个代码分析工具对我们的编译通过之外的一个保证把它良好的代码是有非常好的好处。因为我记得还是在十年前,当时在一个国内特大公司入职培训的时候,一般的导师对每位员工都会培训一个案例:代码规范。好的代码并不是通过编译就行了,而且需要好的编程规范,避免通过了编译但却其实会出现神秘的故障,而且很难定位。

    看完CI/CD,我们来看看DevOps关注什么。DevOps的关注的是我们发布的环境要自动伸缩,要A/B Test,要灰度发布,要自动的升级,或者要滚动升级,滚动升级就是指不是一次性升级完所有的pod,还是可以选择性的升级一部分,比如升级20%,或者升级50%。有什么好处?可以使我们的应用服务不中断。它们两者的共同点,当然都需要基于Docker和Kubernetes来做这样的一个容器化封装和自动化。右边的这个DevOps其实是DevOps刚出现的时候,我们叫标准的DevOps。它和CI/CD有区别,但是其实有很大的联系,CI/CD和这样的标准DevOps组合起来就叫做我们的大DevOps,所以这两者是可以结合起来,CI/CD解决我们开发、测试、自动化、标准化的问题,标准DevOps解决我们的开发运维,主要是运维方面的问题,只有这两者结合起来就可以一键式解决我们的开发、测试、运维问题,并且可以形成一个闭环。

    下图就是滚动升级这一功能,可以通过逐个容器替代,升级其中的25%的容器,然后再确认一下,如果工作正常,我们再可以升级其中的下一批容器。

    下面是灰度发布。这在我们日新月异的频繁发布的互联网场景特别有用。因为我们有大量的互联网应用。所以有一个特别好的新功能,像看看它的这个功能,看看用户的反馈,用户的使用情况怎么样,我们的灰度发布。用Kubernetes的pod非常方便。开始可以给一个灰度版本1,内部用户使用的没问题,再给一个版本2,给我们的用户群,用户群A,再逐渐的扩大到所有的用户,这是互联网非常好的应用。

    总 结

    这里来回顾一下中国东信基于Kubernetes开发的这样四大场景。第一个是PaaS企业应用平台。第二个是Kubernetes的微服务,SpringCloud也是微服务,但SpringCloud微服务是主要关注在应用层面,而且它只是针对Java有效,对别的语言是没有的。Kubernetes是语言无关的,而且是比SpringCloud使用面更广的,但最佳的实践是可以把我们的SpringCloud的每个微服务通过容器化的方式进行封装,再通过Kubernetes进行平台的集群资源调度和自动伸缩。第三个就是我们CICD,第四个是我们的DevOps。

    微信号:RancherLabs

    展开全文
  • 文章目录一、云计算简介1、虚拟化技术与云计算的联系2、云计算的分类3、Kubernetes入门二、Kubernetes云平台搭建 一、云计算简介 1、虚拟化技术与云计算的联系 云计算概念: 云计算是一种将网络、存储、硬件、软件...

    一、云计算简介

    1、虚拟化技术与云计算的联系

    云计算概念:

    • 云计算是一种将网络、存储、硬件、软件整合在一起的技术,它强调的是资源池这一概念,而且资源池可以动态的无限扩容、缩容,最终让租户去租用这些资源。
    • 云计算最终是为租户提供服务,租户可以根据自身需求,去进行资源池的申请,提供资源池的平台称为云平台。

    虚拟化概念:

    • 虚拟化技术将物理资源转变成逻辑上可管理的资源,以打破物理资源结构壁垒,让虚拟机中的服务运行在虚拟的基础上,而不是直接运行在物理资源上。

    联系:虚拟化技术是云计算中的一个模块,而且是不可或缺的模块。云计算提供的是大量各种资源池,虚拟化技术便是合理分配这些资源池的资源给虚拟机。然后再把虚拟机按照不同的配置以不同的价格出售给各个中小企业租户进行租用。

    2、云计算的分类

    (1)以服务类型分类

    • IaaS(Infrastructure as a Server)
    • PaaS(Platform as a Server)
    • SaaS(Software as a Server)
      在这里插入图片描述图形解析:
    • 没有云计算时,我们需要做的是最左边绿色部分(即所有事)
    • 当我们引入IaaS,下面棕色部分的东西就交给了云平台,上面绿色部分自己处理(即提供诸如网络、存储等硬件设施)
    • 当我们引入PaaS,由图可知,我们只用自己部署软件服务。
    • 当我们引入SaaS,我们可以使用云提供者开发的软件,这些软件一般来说都是对现有开源,免费软件进行了二次开发的,具有更高的性能,更强大的支持和优化。像SaaS,我们基本上只用提供网站代码即可。其他维护什么都不用自己干。

    更形象的说明请见博客: https://blog.csdn.net/weixin_44571270/article/details/89737883

    (2)以服务对象分类

    • 公有云
    • 私有云
    • 混合云

    3、Kubernetes入门

    1、Kubernetes是干什么的?
    Kubernetes又称k8s,因其中间有8个字母而命名。它是一个自动化容器管理平台。天生就是为管理docker容器而诞生的。使用Kubernetes可以实现如下功能:

    • 自动化容器的部署和复制;
    • 随时扩展或收缩容器规模;
    • 将容器组织成组,并且提供容器间的负载均衡;
    • 很容易地升级应用程序容器的新版本;
    • 提供容器弹性,如果容器失效就替换它等。

    2、Kubernetes平台组件
    Kubernetes集群中主要存在两种类型的节点:master、minion节点,Minion节点为运行 Docker容器的节点,负责和节点上运行的 Docker 进行交互,并且提供了代理功能。master主要是管理大量的分布式的minion节点。

    master节点上的服务:

    • Apiserver:用户和 kubernetes 集群交互的入口,封装了核心对象的增删改查操作,提供了 RESTFul 风格的API 接口,通过etcd来实现持久化并维护对象的一致性。
    • Scheduler:负责集群资源的调度和管理,例如当有 pod 异常退出需要重新分配机器时,scheduler通过一定的调度算法从而找到最合适的节点。
    • Controller-manager:主要是用于保证 replication Controller 定义的复制数量和实际运行的pod 数量一致,另外还保证了从 service 到 pod 的映射关系总是最新的。

    minion节点上的服务:

    • Kubelet:运行在 minion节点,负责和节点上的Docker交互,例如启停容器,监控运行状态等。
    • Proxy:运行在 minion 节点,负责为 pod 提供代理功能,会定期从 etcd 获取 service 信息,并根据service 信息通过修改 iptables来实现流量转发(最初的版本是直接通过程序提供转发功能,效率较低。),将流量转发到要访问的 pod 所在的节点上去。

    核心附件:

    • Etcd:etcd 是一个分布式一致性k-v存储系统数据库,可用于服务注册发现与共享配置储数据库,用来存储kubernetes的信息的,etcd组件作为一个高可用、强一致性的服务发现存储仓库,渐渐为开发人员所关注。在云计算时代,如何让服务快速透明地接入到计算集群中,如何让共享配置信息快速被集群中的所有机器发现,更为重要的是,如何构建这样一套高可用、安全、易于部署以及响应快速的服务集群,etcd的诞生就是为解决该问题。
    • Flannel:Flannel是CoreOS 团队针对 Kubernetes 设计的一个覆盖网(Overlay
      Network)工具,Flannel 目的就是为集群中的所有节点重新规划 IP地址的使用规则,从而使得不同节点上的容器能够获得同属一个内网且不重复的 IP 地址,并让属于不同节点上的容器能够直接通过内网 IP通信。

    二、Kubernetes云平台搭建

    一般企业中,会有多个master节点,一般会做高可用,然后会有etcd分布式集群。但在我们学习技术时,便不需要这么复杂。最简单的架构体系,至少也需要两台或三台物理服务器。

    搭建环境

    在这里插入图片描述我这里采用了两台物理机。201为k8s master节点,200当minion节点,etcd做一台即可。在master节点上共用一台物理服务器。

    搭建流程

    1、安装前奏
    #两个服务器都要执行以下命令:
    setenforce 0
    或者 sed -i '/SELINUX/s/enforcing/disabled/g' /etc/selinux/config
    systemctl stop firewalld
    
    #ntp时间同步,master节点和million节点需要时间一致
    yum install ntp -y
    ntpdate pool.ntp.org
    systemctl start ntpd
    
    2、Master节点安装
    yum install kubernetes-master etcd -y
    
    3、配置etcd
    vim /etc/etcd/etcd.conf
    

    在这里插入图片描述
    注:2380端口是etcd服务器和etcd服务器之间通信的端口,又称分布式集群通信端口。
    2379端口是提供HTTP AP服务,即通过该端口给client提供服务,这里是给master和minion节点提供服务的端口。
    27.0.0.1:2379是为了本地执行etcd命令连接,172.16.193.201:2379是为了远程连接。

    mkdir -pv /data/etcd
    chown -R etcd.etcd /data/etcd
    
    4、配置k8s
    cd /etc/kubernetes/
    ll
    

    在这里插入图片描述
    k8s安装完产生三个服务:

    • apiserver:统一命令(操作)入口
      在这里插入图片描述
    • controller-manager:容器如果失效,会马上创建一个新容器,保证容器总数不变
    • scheduler:调度控制器,发现那个容器资源满了,会自动调度到其他容器。

    再修改k8s config配置:
    在这里插入图片描述启动三个服务:
    在这里插入图片描述

    5、minion节点安装
    yum install kubernetes-node docker *rhsm* -y
    
    6、配置k8s

    k8s minion节点安装完产生两个服务:

    • kubelet:用与docker交互,发布命令、任务。也即是以后就不用docker run、docker ps等等了。就可以使用kubelet这个了。还可以在web界面创建运行容器。

    在这里插入图片描述

    • proxy:SNAT、DNAT就是在这里做的。实现流量转发,具体过程目前还不清楚!

    编辑k8s minion配置文件:

    vim config
    

    在这里插入图片描述启动两个服务:
    在这里插入图片描述

    7、master端查看minion节点

    查看:
    在这里插入图片描述删除minion节点:
    在这里插入图片描述增添minion节点:
    只能重启k8s minion节点上的两个服务。

    8、安装flannel

    注:这个服务是为了给docker容器统一分配ip。

    #这个flannel所有节点都要安装,无论master还是minion。
    yum install flannel -y
    vim /etc/sysconfig/flanneld
    

    在这里插入图片描述

    etcdctl mk /atomic.io/network/config '{"network":"172.17.0.0/16"}'
    #             这个是key                     这个是value
    systemctl start flanneld
    

    安装了flannel服务的宿主机:
    在这里插入图片描述
    docker容器:
    在这里插入图片描述

    三、搭建k8s Dashboard UI界面

    1、master节点要做的操作

    (1)创建Dashboard-controller.yaml、Dashborad-service.yaml文件
    touch Dashboard-controller.yaml
    

    将下面内容写入文件:

    apiVersion: extensions/v1beta1
    kind: Deployment
    metadata:
      name: kubernetes-dashboard
      namespace: kube-system
      labels:
        k8s-app: kubernetes-dashboard
        kubernetes.io/cluster-service: "true"
    spec:
      selector:
        matchLabels:
          k8s-app: kubernetes-dashboard
      template:
        metadata:
          labels:
            k8s-app: kubernetes-dashboard
          annotations:
            scheduler.alpha.kubernetes.io/critical-pod: ''
            scheduler.alpha.kubernetes.io/tolerations: '[{"key":"CriticalAddonsOnly", "operator":"Exists"}]'
        spec:
          containers:
          - name: kubernetes-dashboard
            image: bestwu/kubernetes-dashboard-amd64:v1.6.3
            resources:
              limits:
                cpu: 100m
                memory: 50Mi
              requests:
                cpu: 100m
                memory: 50Mi
            ports:
            - containerPort: 9090
            args:
              - --apiserver-host=http://172.16.193.201:8080 #此处需要修改ip
            livenessProbe:
              httpGet:
                path: /
                port: 9090
              initialDelaySeconds: 30
              timeoutSeconds: 30
    

    touch Dashboard-service.yaml
    

    将下面内容写入文件:

    apiVersion: v1
    kind: Service
    metadata:
      name: kubernetes-dashboard
      namespace: kube-system
      labels:
        k8s-app: kubernetes-dashboard
        kubernetes.io/cluster-service: "true"
    spec:
      selector:
        k8s-app: kubernetes-dashboard
      ports:
      - port: 80
        targetPort: 9090
    
    (2)修改apiserver配置文件

    注:如果不去掉其中的ServiceAccount参数,api会拒绝访问UI界面。

    #KUBE_ADMISSION_CONTROL="--admission-control=NamespaceLifecycle,NamespaceExists,LimitRanger,SecurityContextDeny,ServiceAccount,ResourceQuota"
    KUBE_ADMISSION_CONTROL="--admission-control=NamespaceLifecycle,NamespaceExists,LimitRanger,SecurityContextDeny,ResourceQuota"
    

    如果你是最后才发现做这一步的话。你需要修改后,重启apiserver,然后执行:

    kubectl delete -f Dashboard-controller.yaml
    kubectl delete -f Dashboard-service.yaml
    

    2、minion节点上做的操作(此步骤可省略不要)

    注:这一步可不要,在下一步会自己下载镜像。了解下为啥改名就行了,k8s版本和dashboard版本不能相差太大,所以不建议自己docker pull镜像!

    下载pod-infrastructure、kubernetes-dashboard镜像:

    docker pull docker.io/tianyebj/pod-infrastructure
    docker pull docker.io/mirrorgooglecontainers/kubernetes-dashboard-amd64
    
    #这个改名是因为Dashboard-controller.yaml文件中调用过这个镜像
    docker tag docker.io/siriuszg/kubernetes-dashboard-amd64 bestwu/kubernetes-dashboard-amd64:v1.6.3
    
    #这个改名是因为minion节点中的/etc/kubernetes/kubelet文件中调用过它
    docker tag docker.io/tianyebj/pod-infrastructure registry.access.redhat.com/rhel7/pod-infrastructure
    

    3、创建并运行镜像

    kubectl create -f Dashboard-controller.yaml
    kubectl create -f Dashboard-service.yaml
    iptables -P FORWARD ACCEPT (全部节点都要配置)
    

    报错:error: yaml: line 38: did not find expected key
    这个错误害得我整了很久很久。
    解决方法这两个文件中有空格没有打对。格式不对。重新复制以下。.json格式的文件严格要求格式,空格不能多一个,也不能少一个。

    4、访问k8s UI界面

    查看是否成功生成dashboard界面:

    kubectl get pods -namespace kube-system
    

    这个是失败:
    在这里插入图片描述
    出现错误,可以看日志:

    kubectl logs kubernetes-dashboard-3584070908-vp0gl -n kube-system
    

    这个是成功:
    在这里插入图片描述在这里插入图片描述在这里插入图片描述成功!

    展开全文
  • kubernetes容器云平台实践.pdf 讲解云平台实现资料,讲解云平台实现资料
  • UCloud是国内领先的中立云计算服务商,自主研发IaaS、PaaS、AI服务平台、大数据流通平台等一系列云计算产品,并提供公有、私有、混合、专有在内的综合性行业解决方案。 Kubernetes 自2014年被 Google 开源...

    以下文章来源于UCloud技术 ,作者乐心医疗运维团队

    UCloud技术

    UCloud技术

    UCloud是国内领先的中立云计算服务商,自主研发IaaS、PaaS、AI服务平台、大数据流通平台等一系列云计算产品,并提供公有云、私有云、混合云、专有云在内的综合性行业解决方案。

    Kubernetes 自2014年被 Google 开源以来,很快便成为了容器编排领域的标准。因其支持自动化部署、大规模可伸缩和容器化管理等天然优势,已经被广泛接纳。但由于 Kubernetes 本身的复杂性,也让很多企业的 Kubernetes 探索之路充满挑战。

     

    从最初的自建 Kubernetes 到后来迁移至 UK8S 平台,整个过程遇到了哪些问题并如何解决的呢?本文将带来乐心医疗在 Kubernetes 平台建设方面的思考与实践。

     

    选择Kubernetes

     

    乐心医疗成立于2002年,业务采用的是基于 Dubbo 微服务框架的分布式架构,由于微服务存在数量多、配置冗杂等问题,最初我们使用了 Ansible 作为配置管理工具,虽然可以较好地解决批量系统配置、批量程序部署的问题,但依然难以应对上百个微服务的频繁扩缩容及快速迭代。

    图:Dubbo框架

    2016年初,随着容器技术的兴起,我们调研了诸如 Mesos、Swarm、Kubernetes 等方案,由于 Kubernetes 能完美解决调度、负载均衡、集群管理、伸缩等微服务面临的问题,因此在2016年6月份,经过内部评估之后,我们最终选择了 Kubernetes。

     

    自建Kubernetes

     

    最开始搭建 Kubernetes 需要手动依次打包下载环境需要的所有二进制文件、验证配置环境变量、安装各种网络存储等插件,整个一套搭建流程完成下来非常耗费时间且易出错。后续还需要持续进行手动维护 Kubernetes 集群,例如升级 Kubernetes 版本、内置组件版本等。

     

    2016年6月,乐心医疗的第一个生产用 Kubernetes 集群正式上线。在使用自建 Kubernetes 的过程中,产生了多次因网络、存储插件产生的故障,大部分问题都可以通过 Google 搜索解决,但存在一些涉及到 Kubernetes 核心组件的 BUG,只能通过手动升级 Kubernetes 集群来解决,而 Kubernetes 热升级非常麻烦,这对于当时我们只有两个人的运维团队来说是一个很大的挑战。

     

    除了耗费大量时间和运维人力成本外,自建 Kubernetes 在面临业务发展需要不断新增节点时,很难及时应对业务扩容的需求,不够灵活弹性。所以 UCloud 于2018年推出 UK8S 后,乐心医疗的运维团队在开会讨论之后一致决定尽快迁移到 UK8S。

     

    以下是乐心医疗自建 Kubernetes 过程中用到的开源工具(可供参考):

     

    • Ansible - 管理服务器配置。

    • kubespray - 安装 Kubernetes 集群(需要自行解决 Kubernetes 组件的下载网络问题)。

    • ROOK - 存储解决方案。

    • Harbor - 镜像中心(由于云厂商提供的免费镜像中心功能无法满足我们的业务需求,所以仍无法避免自建镜像中心)。

       

    迁移至UK8S

     

    图:UK8S 控制台界面

    使用 UCloud 的容器云 UK8S 解决了自建 Kubernetes 常见的网络、存储问题,特别是存储可直接使用 UDisk、UFS,之前自建 Kubernetes 使用到的 Nginx 也被负载均衡 ULB 所取代,极大地简化了运维 Kubernetes 的负担。

     

    下面以使用 Helm 部署应用的例子来说明:

    •  
    •  
    •  
    •  
    •  
    •  
    •  
    •  
    •  
    •  
    •  
    •  
    •  
    •  
    •  
    •  
    # 安装 openldap$ helm install --namespace openldap --name openldap \--set env.LDAP_ORGANISATION="xxx Inc" \--set env.LDAP_DOMAIN="xxx.com" \--set-string env.LDAP_READONLY_USER=true \--set env.LDAP_READONLY_USER_USERNAME="readonly" \--set env.LDAP_READONLY_USER_PASSWORD="xxx" \--set persistence.enabled=true \# 指定存储类别为 udisk-ssd--set persistence.storageClass=udisk-ssd \--set service.type=LoadBalancer \# 使用内网负载--set service.annotations."service\.beta\.kubernetes\.io\/ucloud-load-balancer-type"="inner" \--set service.annotations."service\.beta\.kubernetes\.io\/ucloud-load-balancer-vserver-protocol"="tcp" \stable/openldap
    

    如上,存储我们直接使用了 UCloud 的 SSD 云硬盘,运行在 UK8S 里面的 Service 通过内网 ULB 对 VPC 内暴露,集群外部的业务可直接通过 IP 调用。

     

    日志、监控、CI/CD是业务上 Kubernetes 绕不过的话题,接下来分享下我们在这几个模块的实践经验。

    日志平台

    图:架构图

    在日志管理上,我们的实现原理如下:

    1、采用 kafka 作为日志缓冲,在高并发情况下可以通过队列就能起到削峰填谷的作用,防止es 集群丢失数据。

    2、实现动态 schema,业务可以自定义 schema,方便日志检索和查询。

    3、每一个业务有独立的索引。

     

    • UK8S 保障高可用

    业务日志的采集流程为:微服务(log4j2.xml)-> kafka 集群 -> ES 集群 -> Kibana 呈现。

    日志的索引名称在 log4j2.xml 配置文件中定义。

     

    图:log4j2.xml 部分配置

     

    以下是日志中心的工作负载详情:

     

    图:logcenter 工作负载(截图来自 Rancher 控制台)

     

    从上图可以看出我们整套日志服务(kafka、ES)都部署在 UK8S 集群中,除了 kibana 之外,其他所有服务都是多副本,通过集群部署的方式,减少数据丢失的风险。各组件全部使用 helm 工具部署更新,其中存储采用了 UCloud 云硬盘 UDisk。

     

    Kibana 界面的索引名称来源于 log4j2.xml 中的定义的变量:

     

     

    图:索引管理

    由于乐心健康 APP 的设备业务会产生大量日志,导致 ES 节点不定期产生 yellow 状态,所以后期还需要与我们的研发人员协调,减少无用日志,并优化日志索引。

    监控平台

     

    针对 Kubernetes 集群的监控方案有很多,这里主要说明一下我们在性能监控和业务监控两个方面的方案选择。

     

    • 性能监控

     

    性能监控采用了美团点评开源的分布式实时监控系统—— CAT 工具,这里选择 CAT 的原因是由于它是一个实时系统且监控数据支持全量统计。

     

     图:CAT 架构

     

     图:CAT 状态界面

    •  业务监控

     

    业务监控我们采用业界通用的 Prometheus + Grafana 来实现。

     

    图:Grafana 监控仪表盘

    代码发布(CI/CD)

     

    当前使用内部研发的代码发布平台,通过调用 Jenkins API 实现代码的发布构建工作。

     

    图:Pipeline 发布流程

    每个业务有Beta 和 Prod两套环境,使用同一套 Pipeline 脚本,Beta 环境构建好的镜像直接拿来给 Prod 环境使用。

     

    不过由于 Beta 环境的脚本会定期做一些优化更新,为了避免对 Prod 环境的发布产生影响,所以后期会考虑不再使用两个 Pipeline。计划采用 Drone 替换掉 Jenkins,Drone 是云原生的持续化交付工具,配置采用了 yaml 格式,更加清晰易懂,而 Jenkins Pipeline 的语法坑比较多,插件管理混乱。

     

    服务暴露

     

    生产和测试环境我们目前使用的是两套方案,生产环境中是直接使用了 nginx-ingress,并通过外网 ULB 直接暴露到公网,测试环境目前在使用 Konga,后续运行稳定的话,会在生产环境上线替掉 nginx-ingress。服务网关选用 Konga,是因为其界面比 Kong更加友好,且可以直接部署在 UK8S 中。

     

     图:Konga 仪表盘

    配置中心

     

    之前使用 Disconf,目前已替换为 Apollo,所有的配置文件都放在 Apollo 中,同一个镜像运行在不同的 namespace 时,会根据预定义的 configmap 中的 ENV 环境变量,从 Apollo 获取不同的配置信息。替换掉 Disconf 的原因是其源码已长期未更新,不能满足当前日益增长的微服务架构扩展,且没有严格的权限管控,操作日志记录等功能。

     

    总结

     

    在迁移至 UK8S 平台后,乐心医疗深切体会到云服务商 UCloud 提供的 Kubernetes 平台的好处,除了可以免去 Kubernetes 集群自身的搭建及后期维护等运维工作,在 Kubernetes 集群的稳定性、高性能、自动伸缩等方面,UK8S 也能够提供更加专业的服务能力。

    乐心运维团队在迁移至 UCloud 提供的 Kubernetes 平台之前,一直忙于解决自建  Kubernetes 中的因网络、存储或 Kubernetes 组件自身 bug 引起的突发故障,几乎没有时间来做提升运维效率的工作。在抛弃自建 Kubernetes 之后,乐心运维团队实现了 CI/CD 全部由 Jenkins Pipeline groovy 脚本管理,进而开发了代码管理平台,使技术团队的每个成员都能更方便的参与到运维工作中。

    展开全文
  • Kubernetes 原生微服务实践》这一课程学完了,感觉有不少收获,至少能够确认之前的不少做法是正确的当然也有不少野路子。总想抽点时间做一下回顾,记录一下。 课程介绍 课程内容一共由94讲,内容还是比较丰富的,...
  • 参加完“基于Kubernetes私有云平台的建设”分享感受

    千次阅读 热门讨论 2018-01-29 08:24:30
    基于Kubernetes私有云平台的建设 待补充
  • 其实这个东西原理很简单,kubernetes的hpa使用的是heapster,heapster是k8s那帮家伙在搞的,所以k8s还是喜欢自己搞的东西,所以k8s的hpa默认使用的heapster,但在业内,还有一个比heapster更好的监控方案,那就是...
  • 一本深度讲解容器领域关键技术及应用实践的书。 以 Docker 技术基础介绍为开篇,详述了 Kubernetes 技术架构及原理,并提供了容器应用部署实例。 容器引擎 Containerd-shim 的目的主要是避免容器中出现...
  • 容器提供了将应用程序及其依赖项与操作系统解耦的能力。因为其不同于虚拟机镜像打包操作系统的方式,容器可以节省大量的系统资源:计算、内存和磁盘空间。同时,容器还可以进行更快的下载、更新、部署和迭代。...
  • 本节书摘来自华章出版社《开源容器云OpenShift:构建基于Kubernetes的企业应用云平台》一书中的第1章,第1.2节,作者 陈耿 ,更多章节内容可以访问云栖社区“华章计算机”公众号查看 1.2 开源容器云 如前文所述,...
  • kubernetes云原生纪元:kubernetes API && 容器管理平台 文章目录kubernetes云原生纪元:kubernetes API && 容器管理平台武汉加油,中国加油介绍`apiVersion`API Server 介绍如何访问kubernetes ...
  • 开源容器云OpenShift:构建基于Kubernetes的企业应用云平台
  • Rook是一个运行在Kubernetes集群中的开源原生存储服务编排工具,为各种存储方案提供平台、框架和支持,将存储软件转变为自我管理、自我扩展和自我修复的存储服务,以便与原生环境集成。Rook基于底层容器管理平台...
  • 本节书摘来自华章出版社《开源容器云OpenShift:构建基于Kubernetes的企业应用云平台》一书中的第1章,第1.3节,作者 陈耿 ,更多章节内容可以访问云栖社区“华章计算机”公众号查看 1.3 OpenShift OpenShift ...
  • 截至本文发稿(2019-2-10, 农历大年初六)时为止,访问SAP云平台的官方网站:...能看到下面的网页:SAP云平台上的Kubernetes环境,Coming Soon(即将推出) Build powerful container-native applications a...
  • GaiaStack介绍GaiaStack是腾讯基于Kubernetes打造的容器私有云平台。这里有几个关键词:腾讯:GaiaStack可服务腾讯内部所有BG的业务;Kub...
  • Kubernetes原理简介

    2017-03-08 13:44:45
    Kubernetes 的调度流程
  • 若说应用开发是不可避免的下一代开发热潮,那么Kubernetes就是你一定要认识的对象。做过传统应用的同学应该还记得,曾经多少次在开发环境运行正常的程序,在测试环境不行,在测试环境通过后的程序,部署到生产环境...
1 2 3 4 5 ... 20
收藏数 24,985
精华内容 9,994
关键字:

kubernetes 云平台