精华内容
下载资源
问答
  • 容器平台建设方案
    千次阅读
    2022-03-31 11:32:33

    一、概述

    随着蓬勃发展,业务规模的不断扩张、功能不断增多,用于支撑业务运行的系统和基础设施也日趋庞杂,企业需要采购越来越多的物理服务器,投入越来越多的人员保证系统的正常运行,同时系统的故障率也快速攀升,运行效率却呈下降趋势,这些都成为要面对的挑战和困难。

    基于云原生的容器技术,在很大程度上可以解决上述问题。容器云平台通过建成以Kubernetes为中心、容器技术为基础的高度自动化、智能伸缩的应用部署及运行环境的容器云管理平台,为业务系统可提供容器管理、自动化持续集成与交付、弹性伸缩、微服务治理、负载均衡管理、自动化运维、大规模集群调度等能力。

    二、背景及意义

    (一)背景

    传统架构的系统服务在性能、效率方面存在瓶颈,无法快速满足业务需要和市场响应。在资源集约化管理方面,需要通过云计算服务实现资源的动态池化管理、应用集成复用,以达成降本增效,减少重复建设、资源浪费的问题。

    (二)建设意义

    基于云原生的容器云平台实现对应用、服务、镜像、集群的统一管理,从而实现测试、开发和运维的一体化流程统一,做到云计算容器层和基础设施层联动上下层之间深度集成,方便资源的调度做到运维开发一体化,上层开发环境自动化、模块化、容器化,交付的应用更加轻量级,提高交付速度和质量,对服务进行细粒度监控和日志告警等;另一方面在平台上能够更加灵活快捷地迭代更新,满足快速高效的需求。

    三、项目重点解决问题及主要创新点

    (一)项目重点解决的问题

    1.同一系统的各类环境差异大。

    出于历史原因,应用配置和环境经常会耦合在一起,版本迭代发布过程中,很难保证开发、测试、生产环境始终是保持一致的,随着版本迭代次数的累加,环境问题会越来越多,因环境差异对业务的影响也会成线性增长。

    2.资源利用率低,交付时间长。

    基于虚拟机、物理机部署的应用,环境搭建周期较长,在开发、测试过程中会存在大量的资源空闲。业务复杂性带来了应用的复杂性,而应用与资源是成正比的。

    3.传统版本部署方式。

    传统的Web应用版本升级时多数都采用整体部署方式,存在应用在升级版本时需先停止服务,遇到问题版本回退、紧急修复耗时较长,影响业务作业、用户体验。

    (二)项目主要创新点

    平台以业务场景作为出发点,结合云原生发展趋势及行业现状,从理念、设计、管理三方面实现了以下创新:

    1.基于云原生的建设体系。以基础设施服务(IaaS)、平台服务(PaaS)、软件服务(Saas)为模型,以自动化部署、自动化运维、自动化交付为目标,建设一个有持续交付能力、高度自动化的研发运维一体化平台。

    2.智能统一的运维管理。平台可为相关业务系统支撑服务提供一键部署、服务扩展、实例伸缩、服务发现、负载均衡等能力。提供了监控告警、日志查询、资源报表等运维管理模块。

    3.丰富的DevOps模块。根据业务场景自主开发;兼容了多种代码管理工具,涵盖了编译、构建、部署、质量门禁、滚动升级、自动回滚、SQL脚本发布、服务健康状态检查、消息通知、定时触发等一系列功能,既提升了代码质量、版本发布效率,也降低了运营成本。

    4.安全合规,审计审核。生产与测试环境物理隔离、网络隔离,生产环境编译强管控;审计方面,平台已实现了操作日志全覆盖,审计日志中可记录用户名、IP地址、修改时间、修改内容等信息,高危操作待指定人员、系统管理员审核后才会生效,进一步提高了平台的安全性。

    5.易扩展、松耦合。平台所有组件都采用容器化方式部署,容器的多实例配合健康检查、弹性伸缩机制,使得平台层已具备了高可用、自愈特性;各个组件之间完全解耦,便于为应用提供更有效和灵活的服务。

    四、项目主要建设内容

    (一)架构设计

    平台包括六大模块:联邦集群、容器服务、交付中心、中间件服务目录、DevOps、运维中心,每个模块包括对应的主要功能点,系统的整体功能架构如下图:

    图1 容器云平台功能架构

    (二)建设内容

    平台提供多种管理功能及服务:

    1.统一集群

    实现了单一集群统一对多个Kubernetes 集群的管理。支持同时部署应用到多个集群(联邦集群)。特性如下:

    1)在多个集群之间分散工作负载,提升应用服务的可靠性;

    2)在不同集群中,能更快速更容易地迁移应用服务;

    3)跨集群的服务发现,服务可以就近访问,以降低延迟;

    4)实践多云(Multi-cloud)或混合云(Hybird Cloud)的部署。

    2.容器服务

    支持类型多样的容器调度设置,如:通过设置主机亲和性可将容器调度到指定的主机上运行;支持Flannel、Calico等多种主流的容器网络模式;支持对接不同类型的存储资源。

    支持以应用为中心的容器应用管理模式,让应用部署和底层服务器资源解耦,业务方只需关心应用本身,无需考虑底层资源,大大加快了应用部署上线的速度。秒级的弹性伸缩,用户可以设置每个服务的弹性策略,根据资源负载变化,自动调整实例数量,最大限度保障业务连续性,更好地服务敏捷开发、微服务化等场景。

    3.交付中心

    用于管理、维护镜像版本,其特点是支持保存文件、镜像,也支持与第三方仓库对接。支持镜像模版创建,通过保存的应用模版可视化创建应用,大大地降低了模板的配置门槛。

    4.中间件服务目录

    提供了数据库、中间件、缓存和流程管理等应用,支持再制定集群资源池,一键部署启动对应的应用,通过部署好的服务目录内应用,提供对应的操作管理,支持启、停、删除等操作。

    5.运维中心

    涵盖了资源监控、操作审计、日志管理、告警配置等功能,具备以下特性:

    1)对计算、存储、网络实时监控与告警,帮助项目组合理使用基础资源;

    2)细粒度的操作审计记录,支持形成报表;

    3)支持多维度的日志管理,标准日志与采集日志统一管控,并支持日志清理功能;

    4)提供自定义的监控面板,保证多维实时有效监控数据。

    五、项目效果

    平台已经建设公有云、私有云等多个集群,接入集团、财险、寿险、养老险、健养等子公司下的22个核心业务系统,部署了近2000个服务,近3000个实例。提高了业务运营效率,提升了服务化IT治理能力,满足业务对于IT系统高可用、高性能、灵活扩展的需要,支持大家保险业务的发展,确保IT应用的部署架构以可持续发展的模式演进。

    六、总结与展望

    本项目解决了企业在技术架构转型、部署架构转型、运维管理转型中遇到的痛点问题。部署在平台上的系统在监控、告警、运维、版本发布等方面都得到了一体化保证。在新浪潮技术发展下,拥抱变化、跟随变化,不仅仅是技术上的转变,更多的是职能的转型,传统的单一技术工程师往全栈技术工程师转变,只懂流程的运维岗已经被自动化、敏捷、技术岗位所替代。

    展望未来,容器云平台将在大家保险集团的公有云、私有云、混合云的建设中发挥更大作用,为整个集团的深刻转型提供强大基石。

     

    更多相关内容
  • 本文介绍美团点评的Docker容器集群管理平台(以下简称“容器平台”)。该平台始于2015年,是基于美团云的基础架构和组件而开发的Docker容器集群管理平台。目前该平台为美团点评的外卖、酒店、到店、猫眼等十几个事业...
  • Dockin容器平台资源管理器是用于应用程序定义和容器实例管理的核心模块,提供了容器分配,回收和查询功能。 有关更多Dockin组件,请访问 特征 0.1.0 支持Dockin CNI 支持Dockin Opserver 安装 最低要求 JDK ≥...
  • 基于rancher搭建k8s容器管理平台.pdf
  • 容器集群管理系统与容器平台的选择非常重要,因为容器管理系统是否先进智能、容器管理平台是否灵活易用且高效,直接影响企业开发运维的效率与速度、资源利用率的高低。在这个竞争激烈,风云突变的时代,应用的...
  • 业务研发基于容器云可以实现快速功能迭代,按需扩容缩容,整个平台每周变更次数超过1万次。携程容器云技术选型主要分为三个阶段:第一个阶段,携程从2013年开始实施OpenStack,2014年所有数据中心都具有了...
  • 利用 K8S 搭建容器管理平台 流行的管理工具
  • 容器集群管理平台.pdf
  • Kubernetes 是来自 Google 云平台的开源容器集群管理系统。基于 Docker 构建一个容器的调度服务。该系统可以自动在一个容器集群中选择一个工作容器供使用。其核心概念是 Container Pod。详细的设计思路请参考这里。 ...
  • 边缘容器:云边端超融合管理平台建设实践.pdf
  • 蓝鲸智云容器管理平台SaaS 重要提示: master分支是开发分支,可能处于不一致或不可用状态。请通过而非master去获取稳定的分支 蓝鲸智云容器管理平台(BCS,BlueKing Container Service)是高度可扩展,灵活易用的...
  • 我们为什么使用容器? 我们为什么使用虚拟机(云主机)? 为什么使用物理机? 这一系列的问题并没有一个统一的标准答案。因为以上几类技术栈都有自身最适用的场景,在最佳实践之下,它们分别都是不可替代的。 原本...

    本文源自一次技术选型的工作中所收集、整理、调研和撰写的技术资料,发布于2018年11月12日。

    我们为什么使用容器?

    我们为什么使用虚拟机(云主机)?
    为什么使用物理机?
    这一系列的问题并没有一个统一的标准答案。因为以上几类技术栈都有自身最适用的场景,在最佳实践之下,它们分别都是不可替代的。
    原本没有虚拟机,所有类型的业务应用都直接跑在物理主机上面,计算资源和存储资源都难于增减,要么就是一直不够用,要么就一直是把过剩的资源浪费掉,所以后来我们看到大家越来越多得使用虚拟机(或云主机),物理机的使用场景被极大地压缩到了像数据库系统这样的特殊类型应用上面。

    原本也没有容器,我们把大部分的业务应用跑在虚拟机(或云主机)上面,把少部分特殊类型的应用仍然跑在物理主机上面。但现在所有的虚拟机技术方案,都无法回避两个主要的问题,一个问题是虚拟化Hypervisor管理软件本身的资源消耗与磁盘IO性能降低,另一个是虚拟机仍然还是一个独立的操作系统,对很多类型的业务应用来说都显得太重了,导致我们在处理虚拟机的扩缩容与配置管理工作时效率低下。所以,我们后来发现了容器的好处,所有业务应用可以直接运行在物理主机的操作系统之上,可以直接读写磁盘,应用之间通过计算、存储和网络资源的命名空间进行隔离,为每个应用形成一个逻辑上独立的“容器操作系统”。除此之外,容器技术还有以下优点:简化部署、多环境支持、快速启动、服务编排、易于迁移。

    容器技术的一些缺点:仍然不能做到彻底的安全隔离,技术栈复杂度飚升,尤其是在应用了容器集群技术之后。所以如果只是小规模的使用,做实验或测试是可以的,上生产环境需要三思而后行。
    在这里插入图片描述

    容器与容器集群技术的演进

    容器技术的演进路线

    在这里插入图片描述
    注:上图取自《容器技术及其应用白皮书[v1.0]》

    容器集群技术的演进

    上图描述了容器技术的演进,此后的近三年来的容器技术演进发展为主要是以容器集群技术为中心,如下所示。
    在这里插入图片描述

    容器的运行原理与基本组件

    Docker容器主要基于以下三个关键技术实现的:

    • Namespaces
    • Cgroups技术
    • Image镜像
      在这里插入图片描述

    容器引擎
    容器引擎(Engine)或者容器运行时(Runtime)是容器系统的核心,也是很多人使用“容器”这个词语的指代对象。容器引擎能够创建和运行容器,而容器的定义一般是以文本方式保存的,比如 Dockerfile。
    在这里插入图片描述

    • Docker Engine :目前最流行的容器引擎,也是业界的事实标准。
    • Rkt:CoreOS 团队推出的容器引擎,有着更加简单的架构,一直作为 Docker 的直接竞争对手存在,是 kubernetes 调度系统支持的容器引擎之一。
    • containerd:这个新的Daemon是对Docker内部组件的一个重构以便支持OCI规范,containerd 主要职责是镜像管理(镜像、元信息等)、容器执行(调用最终运行时组件执行),向上为 Docker Daemon 提供了 gRPC 接口,向下通过 containerd-shim 结合 runC,使得引擎可以独立升级。
    • docker-shim: containerd通过调用shim 启动 docker 容器,所以每启动一个容器都会起一个新的docker-shim进程。docker-shim是通过指定的三个参数:容器id,boundle目录和运行时(默认为runC)来调用runC的api创建一个容器。
    • runC :是 Docker 按照开放容器格式标准(OCF, Open Container Format)制定的一种具体实现,实现了容器启停、资源隔离等功能,所以是可以不用通过 docker 引擎直接使用runC运行一个容器的。也支持通过改变参数配置,选择使用其他的容器运行时实现。RunC可以说是各大CaaS厂商间合纵连横、相互妥协的结果,

    注:RunC在各个CaaS厂商的推动下在生产环境得到广泛的应用。Kubernetes目前基本只支持RunC容器,对于Docker超出其容器抽象层之外的功能,一概不支持。同样,Mesos也通过其Unified Containerizer只支持RunC容器,目前还支持Docker,但是未来的规划是只支持Unified Containerizer。CF也通过Garden只支持RunC,不支持Docker超出RunC之前的功能。
    在这里插入图片描述

    为什么在容器的启动或运行过程中需要一个 docker-containerd-shim 进程呢?
    其目的有如下几点:

    • 它允许容器运行时(即 runC)在启动容器之后退出,简单说就是不必为每个容器一直运行一个容器运行时(runC)
    • 即使在 containerd 和 dockerd 都挂掉的情况下,容器的标准 IO 和其它的文件描述符也都是可用的
    • 向 containerd 报告容器的退出状态

    rkt与containerd的区别是什么?
    一个主要的不同之处是,rkt作为一个无守护进程的工具(daemonless tool),可以用来在生产环境中,集成和执行那些特别的有关键用途的容器。举个例子,CoreOS Container Linux使用rkt来以一个容器镜像的方式执行Kubernetes的agent,即kublet。更多的例子包括在Kubernetes生态环境中,使用rkt来用一种容器化的方式挂载volume。这也意味着rkt能被集成进并和Linux的init系统一起使用,因为rkt自己并不是一个init系统。kubernets支持容器进行部署,其所支持的容器不只是仅仅局限于docker,CoreOS的rkt也是容器玩家之一,虽然跟docker比起来还是明显处于绝对下风,但有竞争总要好过没有。

    容器编排和管理系统

    容器是很轻量化的技术,相对于物理机和虚机而言,这意味着在等量资源的基础上能创建出更多的容器实例出来。一旦面对着分布在多台主机上且拥有数百套容器的大规模应用程序时,传统的或单机的容器管理解决方案就会变得力不从心。另一方面,由于为微服务提供了越来越完善的原生支持,在一个容器集群中的容器粒度越来越小、数量越来越多。在这种情况下,容器或微服务都需要接受管理并有序接入外部环境,从而实现调度、负载均衡以及分配等任务。
    简单而高效地管理快速增涨的容器实例,自然成了一个容器编排系统的主要任务。

    容器集群管理工具能在一组服务器上管理多容器组合成的应用,每个应用集群在容器编排工具看来是一个部署或管理实体,容器集群管理工具全方位为应用集群实现自动化,包括应用实例部署、应用更新、健康检查、弹性伸缩、自动容错等等。
    容器编排和管理系统的分层结构图
    在这里插入图片描述

    容器编排和管理系统界的主要选手

    • Kubernetes:Google 开源的容器管理系统,起源于内部历史悠久的 Borg 系统。因为其丰富的功能被多家公司使用,其发展路线注重规范的标准化和厂商“中立”,支持底层不同的容器运行时和引擎(比如 Rkt),逐渐解除对 Docker 的依赖。Kubernetes的核心是如何解决自动部署,扩展和管理容器化(containerized)应用程序。目前该项目在github上Star数量为43k。
    • Docker Swarm: 在 Docker 1.2 版本后将 Swarm 集成在了 Docker 引擎中。用户能够轻松快速搭建出来 docker 容器集群,几乎完全兼容 docker API 的特性。目前该项目在github上Star数量为5.3k。
    • Mesosphere Marathon:Apache Mesos 的调度框架目标是成为数据中心的操作系统,完全接管数据中心的管理工作。Mesos理念是数据中心操作系统(DCOS),为了解决IaaS层的网络、计算和存储问题,所以Mesos的核心是解决物理资源层的问题。Marathon是为Mesosphere DC/OS和Apache Mesos设计的容器编排平台。目前该项目在github上Star数量为3.7k。

    注:国内外有很多公司在从事基于上面三个基础技术平台的创新创业,为企业提供增值服务,其中做得不错的如Rancher,其产品可以同时兼容 kubernetes、mesos 和 swarm 集群系统,此外还有很多商用解决方案,如OpenShift。

    中国市场的表现
    在中国市场,2017 年 6 月 Kubernetes 中国社区 K8SMeetup 曾组织了国内首个针对中国容器开发者和企业用户的调研。近 100 个受访用户和企业中给我们带来了关于 Kubernetes 在中国落地状况的一手调查资料显示:

    • 在容器编排工具中,Kubernetes占据了70%市场份额,此外是Mesos约11%,Swarm不足7%;
    • 在中国受访企业用户中,Kubernetes 平台上运行的应用类型非常广泛,几乎包括了除hadoop大数据技术栈以外的各种类型应用;
    • 中国受访企业运行 Kubernetes 的底层环境分布显示,29%的客户使用裸机直接运行容器集群,而在包括OpenStack、VMWare、阿里云和腾讯云在内的泛云平台上运行容器集群服务的客户占到了60%;

    关于CNCF基金会

    主要的容器技术厂商(包括 Docker、CoreOS、Google、Mesosphere、RedHat 等)成立了 Cloud Native Computing Foundation (CNCF) 。
    CNCF对云原生的定义是:

    • 云原生技术帮助公司和机构在公有云、私有云和混合云等新型动态环境中,构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。
    • 这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段,云原生技术可以使开发者轻松地对系统进行频繁并可预测的重大变更。
    • 云原生计算基金会(CNCF)致力于培育和维护一个厂商中立的开源生态系统,来推广云原生技术。我们通过将最前沿的模式普惠,让这些创新为大众所用。

    下图是截止2018.11的CNCF部分云原生项目列表:
    在这里插入图片描述

    • 云原生以容器为核心技术,分为运行时(Runtime)和 Orchestration 两层,Runtime 负责容器的计算、存储、网络;Orchestration 负责容器集群的调度、服务发现和资源管理。

    注:上图只截取了原图的核心组件部分,完整图表详见https://landscape.cncf.io/images/landscape.png

    Kubernetes的核心组件

    Kubernetes的核心组件示意图

    在这里插入图片描述

    • etcd是Kubernetes的存储状态的分布式数据库,采用raft协议作为一致性算法(raft协议原理可参见一个动画演示http://thesecretlivesofdata.com/raft/)。
    • API Server组件主要提供认证与授权、运行一组准入控制器以及管理API版本等功能,通过REST API向外提供服务,允许各类组件创建、读取、写入、更新和监视资源(Pod, Deployment, Service等)。
    • Scheduler组件,根据集群资源和状态选择合适的节点用于创建Pod。
    • Controller Manager组件,实现ReplicaSet的行为。
    • Kubelet组件,负责监视绑定到其所在节点的一组Pod,并且能实时返回这些Pod的运行状态。

    创建Pod的整个流程时序图

    在这里插入图片描述

    容器网络

    容器的大规模使用,也对网络提供了更高的要求。网络的不灵活也是很多企业的短板,目前也有很多公司和项目在尝试解决这些问题,希望提出容器时代的网络方案。
    Docker采用插件化的网络模式,默认提供bridge、host、none、overlay、macvlan和Network plugins这几种网络模式,运行容器时可以通过–network参数设置具体使用那一种模式。

    • bridge:这是Docker默认的网络驱动,此模式会为每一个容器分配Network Namespace和设置IP等,并将容器连接到一个虚拟网桥上。如果未指定网络驱动,这默认使用此驱动。
    • host:此网络驱动直接使用宿主机的网络。
    • none:此驱动不构造网络环境。采用了none 网络驱动,那么就只能使用loopback网络设备,容器只能使用127.0.0.1的本机网络。
    • overlay:此网络驱动可以使多个Docker daemons连接在一起,并能够使用swarm服务之间进行通讯。也可以使用overlay网络进行swarm服务和容器之间、容器之间进行通讯,
    • macvlan:此网络允许为容器指定一个MAC地址,允许容器作为网络中的物理设备,这样Docker daemon就可以通过MAC地址进行访问的路由。对于希望直接连接网络网络的遗留应用,这种网络驱动有时可能是最好的选择。
    • Network plugins:可以安装和使用第三方的网络插件。可以在Docker Store或第三方供应商处获取这些插件。

    在默认情况,Docker使用bridge网络模式。

    容器网络模型(CNM)

    CNM在2015年由Docker引入,CNM有IP 地址管理(IPAM)和网络插件功能。IPAM插件可以创建IP地址池并分配,删除和释放容器IP。网络插件API用于创建/删除网络,并从网络中添加/删除容器。

    容器网络接口(CNI)

    CNI诞生于2015年4月,由CoreOS公司推出,CNI是容器中的网络系统插件,它使得类似Kubernetes之类的管理平台更容易的支持IPAM、SDN或者其它网络方案。CNI实现的基本思想为:Contianer runtime在创建容器时,先创建好network namespace,这在实际操作过程中,首先创建出来的容器是Pause容器。之后调用CNI插件为这个netns配置网络,最后在启动容器内的进程。

    CNI Plugin负责为容器配置网络,包括两个基本接口:

    • 配置网络:AddNetwork(net NetworkConfig, rt RuntimeConf) (types.Result, error)
    • 清理网络:DelNetwork(net NetworkConfig, rt RuntimeConf) error

    每个CNI插件只需实现两种基本操作:创建网络的ADD操作,和删除网络的DEL操作(以及一个可选的VERSION查看版本操作)。所以CNI的实现确实非常简单,把复杂的逻辑交给具体的Network Plugin实现。

    Kubernetes CNI 插件

    在这里插入图片描述

    • Flannel:CoreOS 开源的网络方案,为 kubernetes 设计,它的功能是让集群中的不同节点主机创建的Docker容器都具有全集群唯一的虚拟IP地址。Flannel的底层通信协议的可选余地有很多,比如UDP、VXlan、AWS VPC等等,不同协议实现下的网络通信效率相差较多,默认为使用UDP协议,部署和管理简单。目前为止,还不支持k8s的Network Policy。
    • Calico:一个纯三层的网络解决方案,使用 BGP 协议进行路由,可以集成到 openstack 和 docker。Calico节点组网可以直接利用数据中心的网络结构(无论是L2或者L3),不需要额外的NAT,隧道或者Overlay Network,网络通信性能好。Calico基于iptables还提供了丰富而灵活的网络Policy,保证通过各个节点上的ACLs来提供Workload的多租户隔离、安全组以及其他可达性限制等功能。如果企业生产环境可以开启BGP协议,可以考虑calico bgp方案。不过在现实中的网络并不总是支持BGP路由的,因此Calico也设计了一种IPIP模式,使用Overlay的方式来传输数据。
    • Weave Net:weaveworks 给出的网络的方案,使用 vxlan 技术通过Overlay网络实现的, 支持网络的隔离和安全,安装和使用都比较简单。
    • Contiv: 思科开源,兼容CNI模型以及CNM模型,支持 VXLAN 和 VLAN 方案,配置较复杂。支持Tenant,支持租户隔离,支持多种网络模式(L2、L3、overlay、cisco sdn solution)。Contiv带来的方便是用户可以根据容器实例IP直接进行访问。
    • Canal:基于 Flannel 和 Calico 提供 Kubernetes Pod 之间网络防火墙的项目。
    • Cilium:利用 Linux 原生技术提供的网络方案,支持 L7 和 L3、L4 层的访问策略。
    • Romana:Panic Networks 推出的网络开源方案,基于 L3 实现的网络连通,因此没有 Overlay 网络带来的性能损耗,但是只能通过 IP 网段规划来实现租户划分。

    从理论上说,这些CNI工具的网络速度应该可以分为3个速度等级。
    * 最快的是Romana、Gateway模式的Flannel、BGP模式的Calico。
    * 次一级的是IPIP模式的Calico、Swarm的Overlay网络、VxLan模式的Flannel、Fastpath模式的Weave。
    * 最慢的是UDP模式的Flannel、Sleeve模式的Weave。

    Flannel

    • UDP封包使用了Flannel自定义的一种包头协议,数据是在Linux的用户态进行封包和解包的,因此当数据进入主机后,需要经历两次内核态到用户态的转换。网络通信效率低且存在不可靠的因素。
    • VxLAN封包采用的是内置在Linux内核里的标准协议,因此虽然它的封包结构比UDP模式复杂,但由于所有数据装、解包过程均在内核中完成,实际的传输速度要比UDP模式快许多。Vxlan方案在做大规模应用时复杂度会提升,故障定位分析复杂。
    • Flannel的Gateway模式与Calico速度相当,甚至理论上还要快一点。Flannel的Host-Gateway模式,在这种模式下,Flannel通过在各个节点上的Agent进程,将容器网络的路由信息刷到主机的路由表上,这样一来所有的主机就都有整个容器网络的路由数据了。Host-Gateway的方式没有引入像Overlay中的额外装包解包操作,完全是普通的网络路由机制,它的效率与虚拟机直接的通信相差无几。Host-Gateway的模式就只能用于二层直接可达的网络,由于广播风暴的问题,这种网络通常是比较小规模的。路由网络对现有网络设备影响比较大,路由器的路由表有空间限制,一般是两三万条,而容器的大部分应用场景是运行微服务,数量集很大。

    Flannel网络通信原理示意图

    在这里插入图片描述

    各CNI网络插件的功能对比:
    在这里插入图片描述

    容器存储

    因为容器存活时间很短的特点,容器的状态(存储的数据)必须独立于容器的生命周期,也因为此,容器的存储变得非常重要。

    • Ceph:分布式存储系统,同时支持块存储、文件存储和对象存储,发展时间很久,稳定性也得到了验证。之前在 OpenStack 社区被广泛使用,目前在容器社区也是很好的选项。
    • GlusterFS:RedHat 旗下的产品,部署简单,扩展性强。
    • 商业存储:DELL EMC,NetApp等
    • CSI(Container Storage Interface):定义云应用调度平台和各种存储服务接口的项目,核心的目标就是存储 provider 只需要编写一个 driver,就能集成到任何的容器平台上。
    • Rook:基于 Ceph 作为后台存储技术,深度集成到 Kubernetes 容器平台的容器项目,因为选择了 Ceph 和 Kubernetes 这两个都很热门的技术,并且提供自动部署、管理、扩展、升级、迁移、灾备和监控等功能

    Kubernetes支持的存储类型

    • awsElasticBlockStore
    • azureDisk
    • azureFile
    • cephfs
    • configMap
    • csi
    • downwardAPI
    • emptyDir
    • fc (fibre channel)
    • flocker
    • gcePersistentDisk
    • gitRepo (deprecated)
    • glusterfs
    • hostPath
    • iscsi
    • local
    • nfs
    • persistentVolumeClaim
    • projected
    • portworxVolume
    • quobyte
    • rbd
    • scaleIO
    • secret
    • storageos
    • vsphereVolume

    Kubernetes以in-tree plugin的形式来对接不同的存储系统,满足用户可以根据自己业务的需要使用这些插件给容器提供存储服务。同时兼容用户使用FlexVolume和CSI定制化插件。
    在这里插入图片描述

    一般来说,Kubernetes中Pod通过如下三种方式来访问存储资源:

    • 直接访问
    • 静态provision
    • 动态provision(使用StorageClass动态创建PV)

    服务发现

    容器和微服务的结合创造了另外的热潮,也让服务发现成功了热门名词。可以轻松扩展微服务的同时,也要有工具来实现服务之间相互发现的需求。
    DNS 服务器监视着创建新 Service 的 Kubernetes API,从而为每一个 Service 创建一组 DNS 记录。 如果整个集群的 DNS 一直被启用,那么所有的 Pod应该能够自动对 Service 进行名称解析。在技术实现上是通过kubernetes api监视Service资源的变化,并根据Service的信息生成DNS记录写入到etcd中。dns为集群中的Pod提供DNS查询服务,而DNS记录则从etcd中读取。

    • kube-dns:kube-dns是Kubernetes中的一个内置插件,目前作为一个独立的开源项目维护。Kubernetes DNS pod 中包括 3 个容器:kube-dns,sidecar,dnsmasq
    • CoreDNS:CoreDNS是一套灵活且可扩展的权威DNS服务器,作为CNCF中的托管的一个项目,自k8s 1.11 版本起被正式作为集群DNS附加选项,且在用户使用kubeadm时默认生效。提供更好的可靠性、灵活性和安全性,可以选择使用CoreDNS替换Kubernetes插件kube-dns。

    状态数据存储

    目前主要有三种工具,大部分的容器管理系统也都是同时可以支持这三种工具。

    • etcd:CoreOS 开源的分布式 key-value 存储,通过 HTTP/HTTPS 协议提供服务。etcd 只是一个 key-value 存储,默认不支持服务发现,需要三方工具来集成。kubernetes 默认使用 etcd 作为存储。
    • ZooKeeper:Hadoop 的一个子项目,本来是作为 Hadoop 集群管理的数据存储,目前也被应用到容器领域,开发语言是 Java。
    • Consul:HashiCorp 开发的分布式服务发现和配置管理工具

    这些工具的主要作用就是保证这个集群的动态信息能统一保存,并保证一致性,这样每个节点和容器就能正确地获取到集群当前的信息。

    健康检查

    Kubernetes提供两种类型的健康检查,支持进行三种类型的探测:HTTP、Command和TCP。

    • Readiness探针旨在让Kubernetes知道您的应用何时准备好其流量服务。 Kubernetes确保Readiness探针检测通过,然后允许服务将流量发送到Pod。 如果Readiness探针开始失败,Kubernetes将停止向该容器发送流量,直到它通过。
    • Liveness探针让Kubernetes知道你的应用程序是活着还是死了。 如果你的应用程序还活着,那么Kubernetes就不管它了。 如果你的应用程序已经死了,Kubernetes将删除Pod并启动一个新的替换它。

    容器监控

    我们习惯于在两个层次监控:应用以及运行它们的主机。现在由于容器处在中间层,以及 Kubernetes 本身也需要监控,因此有 4 个不同的组件需要监控并且搜集度量信息。
    1)cAdvisor + InfluxDB + Grafana:一个简单的跨多主机的监控系统Cadvisor:将数据,写入InfluxDBInfluxDB :时序数据库,提供数据的存储,存储在指定的目录下Grafana :提供了WEB控制台,自定义查询指标,从InfluxDB查询数据,并展示。
    2)Heapster + InfluxDB + Grafana:Heapster是一个收集者,将每个Node上的cAdvisor的数据进行汇总,然后导到InfluxDB,支持从Cluster、Node、Pod的各个层面提供详细的资源使用情况。Heapster:在Kubernetes集群中获取Metrics和事件数据,写入InfluxDB,Heapster收集的数据比cAdvisor多,而且存储在InfluxDB的也少。InfluxDB:时序数据库,提供数据的存储,存储在指定的目录下。Grafana:提供了WEB控制台,自定义查询指标,从InfluxDB查询数据,并展示。
    3)Prometheus+Grafana:Prometheus是个集DB、Graph、Statistics、Alert 于一体的监控工具。提供多维数据模型(时序列数据由metric名和一组key/value组成)和在多维度上灵活的查询语言(PromQl),提供了很高的写入和查询性能。对内存占用量大,不依赖分布式存储,单主节点工作,所以不具有高可用性,支持pull/push两种时序数据采集方式。

    考虑到Prometheus在扩展性和高可用方面的缺点,在超大规模应用时可以考察下thanos这样的面向解决Prometheus的长时间数据存储与服务高可用解决方案的开源项目:https://github.com/improbable-eng/thanos

    容器集群的四个监控层次

    在这里插入图片描述

    镜像 registry

    镜像 registry 是存储镜像的地方,可以方便地在团队、公司或者世界各地分享容器镜像,也是运行容器最基本的基础设施。

    • Docker Registry:Docker 公司提供的开源镜像服务器,也是目前最流行的自建 registry 的方案
    • Harbor:企业级的镜像 registry,提供了权限控制和图形界面

    每种对应技术几乎都有自己的基础镜像,例如:

    参考资料

    中国开源云联盟容器工作组-容器技术及其应用白皮书v1.0
    从风口浪尖到十字路口,写在 Kubernetes 两周年之际 https://mp.weixin.qq.com/s/hrgXzt7YKVf6ZCFzJ-WTFA
    白话Kubernetes网络 http://dockone.io/article/2616Kubernetes
    主机和容器的监控方案 http://dockone.io/article/2602CNCF
    云原生容器生态系统概要 http://dockone.io/article/3006Kubernetes
    存储系统介绍及机制实现 http://dockone.io/article/3063Kubernetes
    内部组件工作原理介绍 http://dockone.io/article/5108
    Docker、Containerd、RunC…:你应该知道的所有 https://www.infoq.cn/article/2017%2F02%2FDocker-Containerd-RunC
    从 docker 到 runC https://www.cnblogs.com/sparkdev/p/9129334.html

    展开全文
  • 使用 Kubectl 管理 Kubernetes 容器平台

    千次阅读 多人点赞 2020-12-12 20:03:23
    使用 Kubectl 管理 Kubernetes 容器平台 一、Kubectl 概述 二、Kubectl 创建和删除 Pod 相关操作 1.在集群上运行一个镜像 2.Kubectl run 语法 3.Pod 常见的状态 3.使用 Kubectl Delete 删除创建的对象 1)删除 Pod 2...

    准备工作:

    一、Kubectl 概述

    Kubectl 是一个用于操作 Kubernetes 集群的命令行接口,通过利用 Kubectl 的各种命令可以实现各种功能。

    二、Kubectl 创建和删除 Pod 相关操作

    命令说明
    run在集群上运行一个 Pod
    create使用文件或标准输入的方式创建一个 Pod
    delete使用文件或者标准输入以及资源名称或者标签选择器来删除某个 Pod

    1.在集群上运行一个镜像

    docker.io-nginx.tarpod-infrastructure.tar 上传到 node1node2 上并导入镜像:

    [root@node1 ~]# ls
    anaconda-ks.cfg      k8s-package         pod-infrastructure.tar
    docker.io-nginx.tar  k8s-package.tar.gz
    [root@node1 ~]# docker load -i docker.io-nginx.tar 
    [root@node1 ~]# docker load -i pod-infrastructure.tar
    

    在这里插入图片描述

    2.Kubectl run 语法

    Kubectl run 和 Docker run 一样,Kubectl run 能将一个 Pod 运行起来。

    • 格式kubectl run NAME --image=image [--env="key=value"] [--port=port] [--replicas=replicas]

    在 master 上启动 Pod:

    [root@master ~]# kubectl run nginx-1 --image=docker.io/nginx --replicas=1 --port=9000		
    

    在这里插入图片描述
    查看 Deployment:

    [root@master ~]# kubectl get deployment
    

    在这里插入图片描述
    查看生成的 Pod,Kubernetes 将容器运行在 Pod 中以方便实施卷和网络共享等管理:

    [root@master ~]# kubectl get pods
    

    在这里插入图片描述

    3.Pod 常见的状态

    • Running:正常运行的状态。
    • ContainerCreating:容器正在创建。
    • ImagePullBackOff:镜像拉取失败。
    • terminating:终止,删除 Pod 时的状态。

    3.使用 Kubectl Delete 删除创建的对象

    1)删除 Pod

    [root@master ~]# kubectl delete pod nginx-1-2637872784-5kg5l
    [root@master ~]# kubectl get pod
    

    在这里插入图片描述
    过 2 分钟左右,再次确认,发现已经运行
    在这里插入图片描述

    2)删除 Deployment

    直接删除 Pod 触发了 Replicas 的确保机制,所以需要删除 Deployment

    [root@master ~]# kubectl delete deployment nginx-1
    [root@master ~]# kubectl get pod
    

    在这里插入图片描述

    三、YAML 语法规则

    YAML 语言的设计目标,就是方便人类读写。它实质上是一种数据串行化格式。

    1.YAML 语法的基本语法规则

    • 大小写敏感。
    • 使用缩进表示层级关系。
    • 缩进时不允许使用 Tab 键,只允许使用空格。
    • # 表示注释,从这个字符一直到行尾,都会被解析器忽略。
    • 在 YAML 里面,连续的项目(如:数组元素、集合元素)通过减号 - 来表示,Map 结构里面的键值对 key/value 用冒号 : 来分割。

    2.YAML 支持的三种数据结构

    • 对象:键值对的集合,又称为 mapping 映射,hashes 哈希,dictionary 字典。
    • 数组:一组按次序排列的值,又称为 sequence 序列,list 列表。
    • 纯量(scalars):单个的、不可再分的值。

    四、Kubectl Create 创建 Deployment

    • 使用 Kubectl run 在配置很复杂的需求时,需要非常长的一条语句,也很容易出错,也没法保存;
    • 所以更多场景下会使用 yaml 或者json 文件。

    1.生成 Deployment 文件

    上传 docker.io-mysql-mysql-server.tarnode1node2 上:

    [root@node1 ~]# docker load -i docker.io-mysql-mysql-server.tar
    

    编写 Deployment 文件:

    [root@master ~]# vim mysql-deployment.yaml
    kind: Deployment
    apiVersion: extensions/v1beta1
    metadata:
      name: mysql
    spec:
      replicas: 1
      template:
        metadata:
          labels:
            name: mysql
        spec:
          containers:
          - name: mysql
            image: docker.io/mysql/mysql-server
            imagePullPolicy: IfNotPresent
            ports:
            - containerPort: 3306
              protocol: TCP
            env:
              - name: MYSQL_ROOT_PASSWORD
                value: "123123"
    

    在这里插入图片描述

    2.使用 Create 创建 Deployment

    [root@master ~]# kubectl create -f mysql-deployment.yaml 
    

    在这里插入图片描述

    • 注意:当一个目录下,有多个 yaml 文件的时候,使用 kubectl create -f 目录 的方式一下全部创建。

    3.使用 Get 命令查看 Pod 详细信息

    [root@master ~]# kubectl get pod
    [root@master ~]# kubectl get deployment
    

    在这里插入图片描述
    加上 -o wide 参数可以查看更详细的信息,如:看 Pod 在哪个 Node 上运行,Pod 的 IP 地址等信息。

    [root@master ~]# kubectl get pod -o wide
    

    在这里插入图片描述

    • 注意:10.255.5.2 这个 IP 地址是 flannel 中定义的网段中的一个 IP 地址(Pod 通过这个 IP 和 Master 进行通信)

    node2 上查看运行的 Container:

    [root@node2 ~]# docker ps
    

    在这里插入图片描述

    4.使用 Describe 查看 K8s 中的详细信息

    命令作用
    kubectl describe pod Pod-ID查看 Pod 的详细描述信息
    kubectl describe node Node-ID查看 Node 的详细描述信息
    kubectl describe deployment Deployment-ID查看 Deployment 的详细描述信息

    五、Kubectl 其他常用命令和参数说明

    命令说明
    logs查看 Pod 的日志信息
    exec在 Pod 中执行一条命令
    cp从容器拷出或向容器拷入文件
    attach到一个运行中的容器上,实时查看容器消息

    1.Kubectl Logs

    [root@master ~]# kubectl get pod
    [root@master ~]# kubectl logs mysql-2388517676-588kb
    

    在这里插入图片描述

    2.Kubectl Exec

    exec 命令用于到 pod 中执行一条命令。

    [root@master ~]# kubectl get pod
    [root@master ~]# kubectl exec -it mysql-2388517676-588kb -- /bin/bash
    bash-4.2# exit
    

    3.Kubectl Attach

    attach 用于取得 Pod 中容器的实时信息,可以持续不断实时的取出消息。

    [root@master ~]# kubectl attach mysql-2388517676-588kb
    

    在这里插入图片描述

    • 到现在,所创建 Nginx 和 MySQL 都只是 Deployment,并没有对应 Service 服务;
    • 所以现在还不能直接在外网进行访问 Nginx 和 MySQL 服务。

    六、使用 Kubectl 管理集群中 Deployment 资源和 Service 服务

    1.生成 Deployment 和 Service 服务的配置文件

    使用 Deployment 方式启动 Nginx 的 Pod 和 Service:

    [root@master ~]# vim nginx-deployment.yaml
    kind: Deployment
    apiVersion: extensions/v1beta1
    metadata:
      name: nginx
    spec:
      replicas: 1
      template:
        metadata:
          labels:
            name: nginx
        spec:
          containers:
          - name: nginx
            image:  docker.io/nginx:latest
            imagePullPolicy: IfNotPresent
            ports:
            - containerPort: 80
              protocol: TCP
    

    创建 Service:

    [root@master ~]# vim nginx-svc.yaml							# 创建 Service
    kind: Service
    apiVersion: v1
    metadata:
      name: nginx
      labels:
        name: nginx
    spec:
      type: NodePort
      ports:
      - protocol: TCP
        nodePort: 31001
        targetPort: 80
        port: 80
      selector:
        name: nginx
    

    在这里插入图片描述

    2.创建 Deployment 和 Serveice

    [root@master ~]# kubectl create -f nginx-deployment.yaml 
    [root@master ~]# kubectl create -f nginx-svc.yaml
    

    在这里插入图片描述
    查看:

    [root@master ~]# kubectl get service
    或者
    [root@master ~]# kubectl get svc
    

    在这里插入图片描述
    查看详细信息:

    [root@master ~]# kubectl get pod -o wide
    

    在这里插入图片描述

    • 现在 Nginx Pod 的 80 端口已经映射到 Node 节点的 31001 端口上。

    使用浏览器访问验证:
    在这里插入图片描述
    尽管 Nginx Pod 是在 node1 运行的,但我们去访问任意 node,都可以正常访问 Nginx 的;因为已经做了负载均衡,所以在 node2 上也可以成功访问 Web 服务。
    在这里插入图片描述
    修改一下默认主页:

    [root@master ~]# kubectl get pod
    [root@master ~]# kubectl exec -it nginx-1011335894-shsfx bash
    root@nginx-1011335894-shsfx:/# echo Nginx > /usr/share/nginx/html/index.html     
    root@nginx-1011335894-shsfx:/# exit
    

    在这里插入图片描述
    使用浏览器访问测试:
    在这里插入图片描述

    展开全文
  • Kubernetes是一个以容器为中心的基础架构,可以实现在物理集群或虚拟机集群上调度和运行容器,提供容器自动部署、扩展和管理的开源平台。满足了应用程序在生产环境中的一些通用需求:应用实例副本、水平自动扩展、...
  • 如何使用容器应用平台部署应用 容器应用平台主要场景 容器应用平台概述 应用性能管理
  • 分析了 Kubernetes 访问控制和资源隔离实现方案基础上,提出了一种基于多租户访问控制模型的容器平台多租户方案,涵盖多租户管理模型、多租户访问控制、计算资源隔离和网络资源隔离等,可切实提升基于Kubernetes的...
  • 基于微服务和Docker容器技术的PaaS云平台架构设计
  • 项目6 容器服务管理平台Rancher任务6.1 Rancher安装Rancher是是开源的Docker全栈容器服务管理平台,通过提供“应用商店”可以部署各种应用,提供CaaS容器服务。默认支持通过整合Cattle、Swarm、Hubernetes、MesOS...

    项目6 容器服务管理平台Rancher

    任务6.1 Rancher安装

    Rancher是是开源的Docker全栈容器服务管理平台,通过提供“应用商店”可以部署各种应用,提供CaaS容器服务。默认支持通过整合Cattle、Swarm、Hubernetes、MesOS容器等编排集群服务实现。

    Rancher提供大量的docker hub官方镜像,用户只要通过管理界面就可部署应用,构建集群环境。界面非常应用。

    6.1.1 系统要求

    安装运行环境系统要求为Centos7, 内核版本不低于3.10,Docker版本不低于1.10。

    6.1.2 设备说明

    结构设计为4个节点,也可以单节点构建,网络架构如下:


    图6.1网络架构图

    1)网络说明

    设备名:

    (1).   Server节点:主要作为系统的运行指令的发送节点,server:10.0.6.80

    (2).   Client节点:主要为服务运行的节点,可以使用一个或者多个均可:

    client1:10.0.6.81,

    client2:10.0.6.82。

    (3).   Registry节点:主要作为系统所有的运行的镜像仓库节点,registry:10.0.3.223

    2)基础环境配置

    在配置完网络接口之后,重启网络服务使更改生效:

    (1).     配置yum源

    所有节点yum源地址为IaaS平台地址

    (2).   删除iptables防火墙规则

    # iptables –F

    # iptables –X

    # iptables –Z

    # /usr/sbin/iptables-save

    (3).   修改系统内核

    打开内核转发功能,编辑配置文件/etc/sysctl.conf,将一下内容添加:

    net.ipv4.ip_forward = 1

    net.ipv4.conf.default.rp_filter= 0

    net.ipv4.conf.all.rp_filter= 0

    修改完成后使用命令生效:

    # sysctl –p

    6.1.3 服务安装

    1)基础配置

    所有节点安装docker环境:

    # yum -y install docker-io

    2)配置docker

    所有节点配置/etc/sysconfig/docker文件修改如下配置:

    ADD_REGISTRY='--add-registry10.0.6.83:5000'

    INSECURE_REGISTRY='--insecure-registry10.0.6.83:5000'

    3)启动服务

    # systemctl startdocker.service

    # systemctl enabledocker.service

    4)配置镜像仓库

    将提供的软件包拷贝到镜像注册节点,而后进行如下操作:

    (1)镜像仓库导入镜像:

    # docker load <registry_latest.tar

    (2)创建镜像仓库:

    #docker run -d -p5000:5000 --restart=always --name registry docker.io/registry:latest(只需要registry节点执行)

    (3)查询本地镜像

    # docker image(查询上传的image id)

    (4)给镜像添加标签

    # docker tagc9bd19d022f6(此处为上一步查看的上传镜像的ID值)10.0.6.83:5000/registry:latest

    (5)上传镜像到私有仓库

    # docker push10.0.6.83:5000/registry:latest

    以此类推上传其他的镜像到私有仓库内。

    5)下载镜像

    server节点:

    # docker pullrancher/server:v1.1.4-xd

    client节点:

    # docker pullrancher/agent-instance:v0.8.3

    # docker pullrancher/agent:v1.0.2

    6)启动服务

    在server节点启动:

    # docker run -d--restart=always -p 80:8080 rancher/server:v1.1.4-xd

    运行完毕后可以通过docker ps –a 命令查看运行的情况:

    [root@server ~]# dockerps -a

    CONTAINER ID        IMAGE                      COMMAND                  CREATED             STATUS              PORTS                            NAMES

    1257e69def4b        rancher/server:v1.1.4-xd   "/usr/bin/s6-svscan /"   21 hours ago        Up 5 minutes        3306/tcp, 0.0.0.0:80->8080/tcp   pensive_tesla

    任务6.2 使用

    6.2.1 应用模板部署

    这里的应用部署主要通过“应用商店”部署

    图6.2 Rancher应用商店

    6.2.2部署案例

    部署博客系统,这里选用wordpress应用来示例如何部署应用。

    1)部署wordpress

    (1)通过主页选择应用

    图6.3 Rancher应用商店

    (2)启动服务

    部署之前修改访问的端口,否则会产生端口冲突问题。


    图6.4 WordPress部署页面

    完成后点击启动,完成服务的部署,服务部署完成后,如下所示,点击端口链接访问。


    图6.5 WordPress部署成功


    图6.6 WordPress安装

    展开全文
  • 容器平台搭建

    2021-03-07 13:16:30
    传统开发测试运维流程 基于云平台大大提高开发...容器平台全局架构 1、SCM是代码库版本管理2、cAdvisor收集容器情况汇报给heapster3、heapster再把监控数据放到时序数据库influxDB4、日志采集使用阿里开源组件log-
  • 概要简述 时至今日,企业IT领域中最主要的问题在于如何解决不同功能部门之间的固有摩擦。一方面,业务线的主要诉求是在市场上实现差异性竞争...在多数组织成员看来,容器技术能够切实解决双方之间所存在的各类矛盾
  • docker compose容器管理

    千次阅读 2022-02-25 16:34:59
    0.安装环境 CentOS7-64 镜像 nginx mysql/mysql-server:5.7 ...Docker-Compose项目是Docker官方的开源项目,负责实现对Docker容器集群的快速编排 ...docker-compose将所管理容器分为3层结构: project...
  • Admiral:trade_mark:是一个高度可扩展且非常轻巧的容器管理平台,用于部署和管理基于容器的应用程序。 它被设计为占用空间小,并且启动速度非常快。 Admiral:trade_mark:旨在提供容器的自动化部署和生命周期管理。 ...
  • 1 容器平台概述01 2 容器平台风险及挑战举例01 2.1 软件漏洞风险01 2.2 API安全风险02 2.3 镜像安全风险02 2.4 网络安全风险03 3 容器平台安全设计03 3.1 基础安全设计04 3.2 管理安全设计08 3.3 应用安全16 4...
  • PAGE 20 58同城Docker容器平台演进 58 私有云平台是 58 同城架构线基于容器技术为内部服务开发的一套业务实例管理平台 它支持业务实例按需扩展秒级伸缩平台提供友好的用户交互过程规范化的测试上线流程旨在将开发...
  • 容器集群管理平台的比较

    千次阅读 2016-12-05 17:21:53
    摘要: 本文简单介绍了主流的容器管理平台包括Swarm,Kubernetes,Mesos,AWS ECS,并对它们做了基本的比较。 容器化和微服务是当前最热话题,不久之前,笔者(据说因为现在都不用笔了,“笔者”的称谓已经不...
  • 容器平台的安全性设计 目录 容器平台概述 01 容器平台风险及挑战举例 01 软件漏洞风险. 01 API安全风险. 02 镜像安全风险. 02 网络安全风险. 03 容器平台安全设计 03 基础安全设计. 04 管理安全设计. 08 ...
  • DevOps 国际峰会 2 0 1 8 北 京 站 目录 1 GaiaStack简介 2 GaiaStack应用全生命周期管理 3 GaiaStack关键技术 DevOps 国际峰会 2 0 1 8 北 京 站 GaiaStack简介 GaiaStack企业级容器平台 GaiaStack是腾讯基于...
  • 在云计算领域有一个新的技术,称为容器。 传统的云计算是基于虚拟机技术的...罗永浩在采访中说过,他要做最大的计算平台,当前是手机,其实大家买手机也是关心CPU,内存有多少,有多大的存储空间,3G还是4G网络的问...
  • 浅谈K8S的容器管理

    千次阅读 2022-03-11 22:25:17
    但由于近期工作接触PaaS平台的内容越来越多,在容器化的基础上引入了更为丰富的容器管理机制,所以自然也就绕不开当前的主流选择Kubernetes(下文简称K8S)。PaaS平台上,开发者仅需要关注上层运行的数据,以主流的...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 214,667
精华内容 85,866
关键字:

容器平台管理