标签: Kubernetes

PaaS的研究过程中有哪些关键技术点和难点,一般市场是如何选择的?

PaaS作为一个综合性的平台,在以」容器+编排引擎」的基础上有诸多关键技术点和难点,本次主要以开源框架和一些市场产品为依托,主要讲述关键点的实现

1.容器技术的选择:容器技术是整个平台的基石,犹如开发web需要选择开发语言一样,目前有docker和garden两种主流技术,自研技术选择时尽量选择技术相对成熟、企业应用案例相对较多、技术生态圈发展更多的技术,一般建议选择docker,如果华为的PaaS产品初期选择garden,目前也已转向了docker,docker已经成为一种事实上的标准。

2.编排引擎的选择:编排引擎的选择一般会依赖容器技术路线的选择,比如docker容器可以选择kubernetes、swarm等框架,garden可以选择cloudfoundry,并且仅此选择。在BAT、华为、京东等互联网公司中,选择docker系的产品更多的选择了kubernetes,或许源于此框架出自google大家之手

3.元数据存储的框架选择:由于整个PaaS的元数据需要一个高可用的存储结构,以便用作服务发现或共享元数据配置的相关元数据信息。基于zookeeper的性能和复杂性等问题考虑,更多的选择etcd框架进行使用,openshift、阿里等产品均采用了此框架

4.PaaS容器网络的选择:容器的网络隔离是PaaS资源隔离的一个重要组成部分,每个容器的网络多采用内部SDN网络,SDN网络的实现技术各不相同,一般主要考虑因素是网络的性能和网络变化的灵活性等因素。开源kubernetes采用flannel框架,openshift的产品中考虑到网络性能等采用了openvswitch,京东在经过各种研究后采用了基于BGP路由方式的Calico

5.日志框架的选择:在集群环境中如何管理不同节点的日志是一个重要的问题,并且目前有一套成熟的解决方案。ElasticSearch+Logstash+Kinana(ELK)已成为一种通用解决方案

6.负载均衡的选择:负载均衡需要在容器集群的容器成员发生变化时能够自动感知和自动修改路由策略,硬件F5和软负载HAProxy、Nginx均可做负载均衡,鉴于HAProxy的灵活性,更多的产品或者企业落地均选择了HAProxy

7.域名的使用:容器集群中的某个应用可以视作一个对外提供的服务,如果采用IP,一方面不方便记忆,一方面IP有可能改变,因此PaaS产品多采用泛域名的形式,将对外提供服务的IP地址和域名关联对应,然后再提供一个route记录对外提供服务的IP地址(frontend)和内部集群IP地址(backend),这样就可以实现从外部域名到内部集群IP地址的访问。

PaaS平台的建设是一个长期的过程,需要不断持续的进行迭代优化,并且随着在PaaS之上运行应用系统的增多和使用经验的不断丰富,对PaaS平台会有更多深入的认知和体会。因此我们也希望论坛上从事这块研究和实践的朋友能够更多的进行技术交流,从而加深技术了解,让PaaS在企业内部更好的发挥其价值和优势。

Kubernetes 之上的架构应用

规划并运转一个兼顾可扩展性、可移植性和健壮性的运用是一件很有应战的事情,尤其是当体系杂乱度在不断增长时。运用或体系 本身的架构*大的影响着其运转办法、对环境的依靠性,以及与相关组件的耦合强弱。当运用在一个高度散布式的环境中运转时, 假如能在规划阶段遵从特定形式,在运维阶段恪守特定实践,就能够协助咱们更好的应对那些*常呈现的问题。 尽管软件规划形式和开发办法论能够协助咱们出产出满足恰当扩展性目标的运用,根底设施与运转环境也在影响着已布置体系的运 维操作。像 Docker、Kubernetes 这些技能能够协助团队打包、分发、布置以及在散布式环境中扩展运用。学习怎么*好的驾御这 些东西,能够协助你在办理运用时拥有更好的机动性、操控性和呼应能力。 在这份攻略里,咱们将探讨一些你或许想采用的准则和形式,它们能够协助你在 Kubernetes 上更好的扩展和办理你的作业集 (workloads)。尽管在 Kubernetes 上能够运转各式各样的作业集,可是你的不同挑选会影响运维难度和布置时的可选项。你怎么 架构和构建运用、怎么将效劳用容器打包、怎么装备生命周期办理以及在 kubernetes 上怎么操作,每一个点都会影响你的体会。 为可扩展性做运用规划 当开发软件时,你所选用的形式与架构会被许多需求所影响。关于 Kubernetes 来说,它*重要的特征之一就是要求运用拥有水平 扩展能力 – 经过调整运用副本数来分管负载以及提高可用性。这与笔直扩展不同,笔直扩展测验运用同样的参数将运用布置到性能 更强或更弱的效劳器上。 比方,微效劳架构是一种合适在集群中运转多个可扩展运用的软件规划形式。开发者们创立一些可组合的简略运用,它们经过杰出 界说的 REST 接口进行网络通讯,而不是像更杂乱的单体式运用那样经进程序内部机制通讯。将单体式运用拆分为多个独立的单一 功用组件后,咱们能够独立的扩展每个功用组件。许多之前一般存在于运用层的组合与杂乱度被搬运到了运维范畴,而它们刚好可 以被像 Kubernetes 这样的渠道搞定。 比特定的软件形式更进一步,云原生(cloud native)运用在规划之初就有一些额定的考量。云原生运用是遵从了微效劳架构形式 的程序,拥有内置的可康复性、可观测性和可办理性,专门用于适应云集群渠道供给的环境。 举例来说,云原生运用在被创造出时都带有健康度目标数据,当某个实例变得不健康时,渠道能够依据目标数据来办理实例的生命 周期。这些目标发生(也能够被导出)稳定的遥控数据来给运维人员告警,让他们能够依据这些数据做决策。运用被规划成能够应 付常规的重启、失败、后端可用性改变以及高负载等各种情况,而不会损坏数据或许变得无法呼应。 遵从 “12 规律运用”运用理论 在创立预备跑在云上的 web 运用时,有一个盛行的办法论能够帮你关注到那些*重要的特征:“12 规律运用理论”( Twelve- Factor App)。它*初被编写出来,是为了协助开发者和运维团队了解一切被规划成在云环境运转的 web 效劳的共有核心特征,而 关于那些将在 Kubernetes 这种集群环境中运转的运用,这个理论也十分适用。尽管单体式运用能够从这些主张中获益,围绕这些 准则规划的微效劳架构运用也会作业的十分好。 “12 规律”的一份简略摘要: 基准代码(Codebase): 将你的一切代码都放在版别操控体系中(比方 Git 或许 Mercurial)。被布置的内容彻底由基准代码决 定。 依靠(Dependencies):运用依靠应该由基准代码全部显式办理起来,无论是用 vendor(指依靠代码和运用代码保存在一同),还 是经过可由包办理软件解析装置的依靠装备文件的办法。 装备(Config):把运用装备参数与运用本身分开来,装备应该在布置环境中界说,而不是被嵌入到运用本身。 后端效劳(Backing Services):本地或长途的依靠效劳都应该被笼统为可经过网络拜访的资源,衔接细节应该在装备中界说。 构建、发布、运转(Build, release, run):运用的构建阶段应该彻底与发布、运维阶段区别开来。构建阶段从运用源码创立出一 个可履行包,发布阶段担任把可履行包和装备组合起来,然后在运转阶段履行这个发布版别。 进程(Processes):运用应该由不依靠任何本地状况存储的进程完结。状况应该被存储在第 4 个规律描绘的后端效劳中。 端口绑定(Port binding):运用应该原生绑定端口和监听衔接。一切的路由和恳求转发作业应该由外部处理。 并发(Concurrency):运用应该依靠于进程模型扩展。只需同时运转多份运用(或许散布在不同效劳器上),就能完结不调整运用 代码扩展的意图。 易处理(Disposability):进程应该能够被快速发动、高雅中止,而不发生任何严峻的副作用。 开发环境与线上环境等价(Dev/prod parity):你的测验、预发布以及线上环境应该尽或许共同而且坚持同步。环境间的差异有可 能会导致兼容性问题和未经测验的装备突然呈现。 日志(Logs):运用应该将日志输出到规范输出(stdout),然后由外部效劳来决定*佳的处理办法。 办理进程(Admin processes):一次性办理进程应该和主进程代码一同发布,依据某个特定的发布版别运转。 依照“12 规律”所供给的攻略,你能够运用彻底适用于 Kubernetes 运转环境的模型来创立和运转运用。“12 规律”鼓舞开发者 们专心于他们运用的首要职责,考虑运维条件以及组件间的接口规划,并运用输入、输出和规范进程办理功用,终究以可被预见的 办法将运用在 Kubernetes 中跑起来。 容器化运用组件 Kubernetes 运用容器在集群节点上运转阻隔的打包运用程序。要在 Kubernetes 上运转,你的运用有必要被封装在一个或许多个容器 镜像中,并运用 Docker 这样的容器运转时履行。尽管容器化你的组件是 Kubernetes 的要求之一,但其实这个进程也协助强化了 刚刚谈到的“12规律运用”里的许多准则,然后让咱们能够简略的扩展和办理运用。 举例来说,容器供给了运用环境与外部宿主机环境之间的阻隔,供给了一个依据网络、面向效劳的运用间通讯办法,而且一般都是 从环境变量读取装备、将日志写到规范输出与规范错误输出中。容器本身鼓舞依据进程的并发策略,而且能够经过坚持独立扩展性 和绑缚运转时环境来协助坚持开发/线上环境共同性(#10 Dev/prod parity)。这些特性让你能够顺畅打包运用,然后顺畅的在 Kubernetes 上运转起来。 容器优化准则 由于容器技能的灵活性,咱们有许多不同种封装运用的办法。可是在 Kubernetes 环境中,其间一些办法比其他办法作业的更好。 镜像构建(image building),是指你界说运用将怎么在容器里被设置与运转的进程,*大多数关于“怎么容器化运用”的*佳实 践都与镜像构建进程有关。一般来说,坚持镜像尺度小以及可组合会带来许多优点。在镜像晋级时,经过坚持构建步骤可办理以及 复用现有镜像层,被优化过尺度的的镜像能够减少在集群中发动一个新容器所需求的时刻与资源。 当构建容器镜像时,尽*大努力将构建步骤与终究在出产环境运转的镜像区别开来是一个好的开端。构建软件一般需求额定的工 具、花费更多时刻,而且会出产出在不同容器里体现不同、或是在终究运转时环境里根本不需求的内容。将构建进程与运转时环境 清晰分开的办法之一是运用 Docker 的“多阶段构建(multi-stage builds)” 特性。多阶段构建装备答应你为构建阶段和运转阶 段设置不同的根底镜像。也就是说,你能够运用一个装置了一切构建东西的镜像来构建软件,然后将结果可履行软件包复制到一个 精简过的、之后每次都会用到的镜像中。 有了这类功用后,依据*小化的父镜像来构建出产环境镜像一般会是个好主意。假如你想彻底防止由 ubuntu:16.04(该镜像包含了 一个完好的 Ubuntu 16.04 环境)这类 “Linux 发行版” 风格父镜像带来的臃肿,你能够测验用 scratch – Docker 的*简根底 镜像 – 来构建你的镜像。不过 scratch 根底镜像缺了一些核心东西,所以部分软件或许会由于环境问题而无法运转。别的一个方 案是运用 Alpine Linux 的 alpine 镜像,该镜像供给了一个轻量可是拥有完好特性的 Linux 发行版。它作为一个稳定的*小根底 环境获得了广泛的运用。 关于像 Python 或 Ruby 这种解说型编程言语来说,上面的例子会稍有改变。由于它们不存在“编译”阶段,而且在出产环境运转 代码时一定需求有解说器。不过由于咱们依然寻求精简的镜像,所以 Docker Hub 上仍是有许多依据 Alpine Linux 构建的各言语 优化版镜像。关于解说型言语来说,运用更小镜像带来的优点和编译型言语差不多:在开端正式作业前,Kubernetes 能够在新节点 上快速拉取到一切有必要的容器镜像。 在 Pod 和“容器”之间做挑选 尽管你的运用有必要被“容器”化后才能在 Kubernetes 上跑起来,但 pods(译注:由于 pod、service、ingress 这类资源名称不 合适翻译为中文,此处及后面均运用英文原文) 才是 Kubernetes 能直接办理的*小笼统单位。pod 是由一个或更多严密相关的容 器组合在一同的 Kubernetes 目标。同一个 pod 里的一切容器共享同一生命周期且作为一个独立单位被办理。比方,这些容器总是 被调度到同一个节点上、一同被发动或中止,同时共享 IP 和文件体系这类资源。 一开端,找到将运用拆分为 pods 和容器的*佳办法会比较困难。所以,了解 Kubernetes 是怎么处理这些目标,以及每个笼统层 为你的体系带来了什么变得十分重要。下面这些事项能够协助你在运用这些笼统概念封装运用时,找到一些自然的鸿沟点。 寻觅自然开发鸿沟是为你的容器决定有效范围的手段之一。假如你的体系采用了微效劳架构,一切容器都经过杰出规划、被频频构 建,各自担任不同的独立功用,而且能够被经常用到不同场景中。这个程度的笼统能够让你的团队经过容器镜像来发布改变,然后 将这个新功用发布到一切运用了这个镜像的环境中去。运用能够经过组合许多容器来构建,这些容器里的每一个都完结了特定的功 能,可是又不能独立成事。 与上面相反,当考虑的是体系中的哪些部分能够从独立办理中获益*多时,咱们常常会用 pods。Kubernetes 运用 pods 作为它面 向用户的*小笼统,因而它们是 Kubernetes API 和东西能够直接交互与操控的*原生单位。你能够发动、中止或许重启 pods,或 者运用依据 pods 建立的更高级别笼统来引进副本集和生命周期办理这些特性。Kubernetes 不答应你独自办理一个 Pod 里的不同 容器,所以假如某些容器能够从独立办理中获得优点,那么你就不应该把它们分到到一个组里。 由于 Kubernetes 的许多特性和笼统概念都直接和 pods 打交道,所以把那些应该被一同扩缩容的东西绑缚到一个 pod 里、应该被 分开扩缩容的分到不同 pod 中是很有道理的。举例来说,将前端 web 效劳器和运用效劳放到不同 pods 里让你能够依据需求独自 对每一层进行扩缩容。不过,有时候把 web 效劳器和数据库适配层放在同一个 pod 里也说得过去,假如那个适配器为 web 效劳器 供给了它正常运转所需的基本功用的话。 经过和支撑性容器绑缚到一同来增强 Pod 功用 了解了上面这点后,究竟什么类型的容器应该被绑缚到同一个 pod 里呢?一般来说,pod 里的主容器担任供给 pod 的核心功用, 可是咱们能够界说附加容器来修正或许扩展那个主容器,或许协助它适配到某个特定的布置环境中。 比方,在一个 web 效劳器 pod 中,或许会存在一个 Nginx 容器来监听恳求和托管静态内容,而这些静态内容则是由别的一个容器 来监听项目变动并更新的。尽管把这两个组件打包到同一个容器里的主意听上去不错,可是把它们作为独立的容器来完结是有许多 优点的。nginx 容器和内容拉取容器都能够独立的在不同情形中运用。它们能够由不同的团队保护并别离开发,到达将行为通用化 来与不同的容器协同作业的意图。 Brendan Burns 和 David Oppenheimer 在他们关于“依据容器的散布式体系规划形式”的论文中界说了三种打包支撑性容器的首要 形式。它们代表了一些*常见的将容器打包到 pod 里的用例: Sidecar(边车形式):在这个形式中,次要容器扩展和增强了主容器的核心功用。这个形式触及在一个独立容器里履行非规范或工 具功用。举例来说,某个转发日志或许监听装备值改动的容器能够扩展某个 pod 的功用,而不会改动它的首要关注点。 Ambassador(大使形式):Ambassador 形式运用一个援助性容器来为主容器完结长途资源的笼统。主容器直接衔接到 Ambassador 容器,而 Ambassador 容器反过来衔接到或许很杂乱的外部资源池 – 比方说一个散布式 Redis 集群 – 并完结资源笼统。主容器可 以完结衔接外部效劳,而不必知道或许关心它们实际的布置环境。 Adaptor(适配器形式):Adaptor 形式被用来翻译主容器的数据、协议或是所运用的接口,来与外部用户的希望规范对齐。 Adaptor 容器也能够统一化中心效劳的拜访入口,即便它们效劳的用户本来只支撑互不兼容的接口规范。 运用 Configmaps 和 Secrets 来保存装备 尽管运用装备能够被一同打包进容器镜像里,可是让你的组件在运转时坚持可被装备能更好支撑多环境布置以及供给更多办理灵活 性。为了办理运转时的装备参数,Kubernetes 供给了两个目标:ConfigMaps 与 Secrets。 ConfigMaps 是一种用于保存可在运转时暴露给 pods 和其他目标的数据的机制。保存在 ConfigMaps 里的数据能够经过环境变量使 用,或是作为文件挂载到 pod 中。经过将运用规划成从这些位置读取装备后,你能够在运用运转时运用 ConfigMaps 注入装备,并 以此来修正组件行为而不必重新构建整个容器镜像。 Secrets 是一品种似的 Kubernetes 目标类型,它首要被用来安全的保存敏感数据,并依据需求挑选性的的答应 pods 或是其他组 件拜访。Secrets 是一种便利的往运用传递敏感内容的办法,它不必像一般装备相同将这些内容用纯文本存储在能够被轻易拜访到 的当地。从功用性上讲,它们的作业办法和 ConfigMaps 简直彻底共同,所以运用能够用彻底相同的办法从二者中获取数据。 ConfigMaps 和 Secrets 能够帮你防止将装备内容直接放在 Kubernetes 目标界说中。你能够只映射装备的键名而不是值,这样可 以答应你经过修正 CongfigMap 或 Secret 来动态更新装备。这使你能够修正线上 pod 和其他 kubernetes 目标的运转时行为,而 不必修正这些资源本身的界说。 完结“安排妥当检测(Readiness)”与“存活检测(Liveness)”探针 Kubernetes 包含了十分多用来办理组件生命周期的开箱即用功用,它们能够保证你的运用始终坚持健康和可用状况。不过,为了利 用好这些特性,Kubernetes 有必要要理解它应该怎么监控和解说你的运用健康情况。为此,Kubernetes 答应你界说“安排妥当检测探针 (Readiness Probe)”与“存活检测探针(Liveness Probe)”。 “存活检测探针”答应 Kubernetes 来断定某个容器里的运用是否处于存活与运转状况。Kubernetes 能够在容器内周期性的履行一 些指令来检查基本的运用行为,或许能够往特定地址发送 HTTP / TCP 网络恳求来判断进程是否可用、呼应是否符合预期。假如某 个“存活探测指针”失败了,Kubernetes 将会重启容器来测验康复整个 pod 的功用。 “安排妥当检测探针”是一个类似的东西,它首要用来判断某个 Pod 是否现已预备好承受恳求流量了。在容器运用彻底安排妥当,能够承受 客户端恳求前,它们或许需求履行一些初始化进程,或许当接到新装备时需求重新加载进程。当一个“安排妥当检测探针”失败后, Kubernetes 会暂停往这个 Pod 发送恳求,而不是重启它。这使得 Pod 能够完结本身的初始化或许保护使命,而不会影响到整个组 的整体健康状况。 经过结合运用“存活检测探针”与“安排妥当检测探针”,你能够操控 Kubernetes 自动重启 pods 或是将它们从后端效劳组里剔除。 经过装备根底设施来使用好这些特性,你能够让 Kubernetes 来办理运用的可用性和健康状况,而无需履行额定的运维作业。 运用 Deployments 来办理扩展性与可用性 在早些时候讨论 Pod 规划根底时,咱们说到其他 Kubernetes 目标会建立在 Pod 的根底上来供给更高级的功用。而 deployment 这个复合目标,或许是被界说和操作的*多次的 Kubernetes 目标。 Deployments 是一种复合目标,它经过建立在其他 Kubernetes 根底目标之上来供给额定功用。它们为一类名为 replicasets 的中 间目标添加了生命周期办理功用,比方能够施行“翻滚晋级(Rolling updates)”、回滚到旧版别、以及在不同状况间转化的能 力。这些 replicasets 答应你界说 pod 模板并依据它快速拉起和办理多份依据这个模板的副本。这能够协助你便利的扩展根底设 施、办理可用性要求,并在毛病发生时自动重启 Pods。 这些额定特性为相对简略的 pod 笼统供给了一个办理框架和自我修复能力。尽管你界说的作业集终究仍是由 pods 单元来承载,但 是它们却不是你一般应该*多装备和办理的单位。相反,当 pods 由 deployments 这种更高级目标装备时,应该把它们当做能够稳 定运转运用的根底构建块来考虑。 创立 Services 与 Ingress 规矩来办理到运用层的拜访 Deployment 答应你装备和办理可交换的 Pod 集合,以扩展运用以及满足用户需求。可是,怎么将恳求流量路由到这些 pods 则是 破例一码事了。鉴于 pods 会在翻滚晋级的进程中被换出、重启,或许由于机器毛病发生搬运,之前被分配给这个运转组的网络地 址也会发生改变。Kubernetes services 经过保护动态 pods 资源池以及办理各根底设施层的拜访权限,来协助你办理这部分杂乱 性。 在 Kuberntes 里,services 是操控流量怎么被路由到多批 pods 的机制。无论是为外部客户转发流量,仍是办理多个内部组件之 间的衔接,services 答应你来操控流量该怎么活动。然后,Kubernetes 将更新和保护将衔接转发到相关 pods 的一切必需信息, 即使环境或网络条件发生改变也相同。 从内部拜访 Services 为了有效的运用 services,你首要应该断定每组 pods 效劳的目标用户是谁。假如你的 service 只会被布置在同一个 Kubernetes 集群的其他运用所运用,那么 ClusterIP 类型答应你运用一个仅在集群内部可路由的固定 IP 地址来拜访一组 pods。一切布置在 集群上的目标都能够经过直接往这个 service IP 地址发送恳求来与这组 pod 副本通讯。这是*简略的 service 类型,很合适在 内部运用层运用。 Kubernetes 供给了可选的 DNS 插件来为 services 供给姓名解析效劳。这答应 pods 和其他目标能够运用域名来代替 IP 地址进 行通讯。这套机制不会显著改动 service 的用法,但依据域名的标识符能够使衔接组件和界说效劳间交互变得更简略,而不需求提 前知道 service IP 地址。 将 Services 向公网开放 假如你的运用需求被公网拜访,奇迹狐网站那么 “负载均衡器(load balancer)”类型的 service 一般会是你的*佳挑选。它会运用运用所 在的特定云供给商 API 来装备一个负载均衡器,由这个负载均衡器经过一个公网 IP 来效劳一切到 service pods 的流量。这种方 式供给了一个到集群内部网络的可控网络通道,然后将外部流量引进到你的 service pods 中。 由于“负载均衡器”类型会为每一个 service 都创立一个负载均衡器,因而用这种办法来暴露 Kubernetes 效劳或许会有些昂贵。 为了协助缓解这个问题,咱们能够运用 Kubernetes ingress 目标来描绘怎么依据预定规矩集来将不同类型的恳求路由到不同 services。例如,发往 “example.com” 的恳求或许会被指向到 service A,而往 “sammytheshark.com” 的恳求或许会被路由 到 service B。Ingress 目标供给了一种描绘怎么依据预界说形式将混合恳求流别离路由到它们的目标 services 的办法。 Ingress 规矩有必要由一个 ingress controller 来解析,它一般是某种负载均衡器(比方 Nginx),以 pod 的办法布置在集群中, 它完结了 ingress 规矩并依据规矩将流量分发到 Kubernetes serices 上。目前,ingress 资源目标界说依然处于 beta 阶段,但 是市面上现已有好几个能作业的具体完结了,它们能够协助集群一切者*小化需求运转的外部负载均衡器数量。

Kubernetes 之上的架构应用 运用声明式语法来办理 Kubernetes 状况 Kubernetes 在界说和办理布置到集群的资源方面供给了很大灵活性。运用 kubectl 这样的东西,你能够指令式的界说一次性资源 并将其快速布置到集群中。尽管在学习 Kubernetes 阶段,这个办法关于快速布置资源或许很有用,但这种办法也存在许多缺陷, 不合适长周期的出产环境办理。 指令式办理办法的*大问题之一就是它不保存你往集群布置过的改变记录。这使得毛病时康复和跟踪体系内运维改变操作变得十分 困难,乃至不或许。 走运的是,Kubernetes 供给了别的一种声明式的语法,它答应你运用文本文件来完好界说资源,并随后运用 kubectl 指令运用这 些装备或更改。将这些装备文件保存在版别操控体系里,是监控改变以及与你的公司内其他部分的审理进程集成的一种简略办法。 依据文件的办理办法也让将已有形式适配专卖网站到新资源时变得简略,只需求复制然后修正现有资源界说即可。将 Kubernetes 目标界说 保存在版别化目录里答应你保护集群在每个时刻节点的希望集群状况快照。当你需求进行毛病康复、搬迁,或是追踪体系里某些意 料之外的改变时,这些内容的价值是不可估量的。 总结 办理运转运用的根底设施,并学习怎么*好的使用这些现代化编排体系供给的特性,这些事情或许会令人望而生畏。可是,只有当 你的开发与运维进程与这些东西的构建概念共同时,Kubernetes 体系、容器技能供给的优势才能更好的体现出来。遵从 Kubernetes *擅长的那些形式来架构你的体系,以及了解特定功用怎么能缓解由高度杂乱的布置带来的应战,能够协助改进你运转 渠道时的体会。

基于Kubernetes的混合云的优缺点

混合云平台越来越分为两大类:基于Kubernetes的平台和不基于Kubernetes的平台。因此,在构建一个将内部或托管基础设施与公共云集成的架构时,这是必须做出的首要基本决策之一。

Kubernetes和混合云

当然,开源容器编排器Kubernetes不仅仅是一个混合云平台。它是一种将应用程序(尤其是,但不一定是在容器中运行的应用程序)部署到任何内部或公共云基础设施或其组合上的方法。支持混合云架构甚至不是Kubernetes项目的主要重点。

尽管如此,Kubernetes为混合部署提供了一个关键好处。它提供了一种统一的方法来部署和管理应用程序,而不管它们在哪个基础设施上运行。它通过从应用程序环境中抽象底层基础设施来实现这一点。当你在Kubernetes上部署应用程序时,无论是在公共云、托管数据中心,甚至是用于测试的备用笔记本电脑中进行部署,过程基本相同。

而且,由于Kubernetes可以同时管理跨多种类型基础设施的应用程序环境,它提供了一致的部署和管理体验,即使你的一些服务器和应用程序运行在公共云中,而其他服务器和应用程序运行在内部或托管设施中。

基于Kubernetes的混合平台

意识到这一点,过去几年中一些供应商已经采用了Kubernetes优先的混合云方法。*突出的例子可能是,Google Anthos使用Google Kubernetes Engine管理运行在任何公共云或私有数据中心的集群。VMware的Tanzu平台是另一个例子。

AWS的EKS Anywhere可以通过Amazon的Elastic Kubernetes服务管理内部集群(也可能是运行在其他公共云中的集群),可以算是某种混合云平台。它并不是亚马逊主要的混合解决方案(AWS Outposts提供了更广泛的混合服务集),但就EKS Anywhere支持跨多个托管环境的容器化应用程序的部署而言,它符合混合云的要求。

基于Kubernetes的混合平台列表到此为止。其他主要的混合解决方案,包括AWS Outposts、Azure Stack和Azure Arc,使用其他技术作为混合云管理的基础。它们通过混合架构支持Kubernetes部署,但是它们不使用Kubernetes作为底层混合环境的管理层。

为什么或为什么不选择混合云上的Kubernetes

混合云的一种实现方法比另一种更好吗?这取决于几个因素。

*重要的是,相比通过公共云的标准工具来管理工作负载,你是否更喜欢通过Kubernetes来管理它们。Anthos和Tanzu等平台使用Kubernetes来编排一切,而Outposts和Azure Stack等解决方案则使用原生管理工具(CloudWatch、CloudTrail、CloudFormation等)进行应用程序部署和管理。如果你更喜欢使用Kubernetes方法来部署和管理应用程序,那么基于Kubernetes的混合云平台可能正适合你。

第二个要考虑的因素是应用程序的容器化程度。Kubernetes可以管理虚拟机和容器,事实上,VM编排在Tanzu和Anthos中都是重要功能。但归根结底,在Kubernetes中管理虚拟机可能会让人感到奇怪,Kubernetes的设计首先是编排容器。虚拟机的启动和停止速度通常不如容器快,而且你很少像容器那样启动多个虚拟机实例。如果你的工作负载主要由虚拟机组成,那么*好使用不围着Kubernetes转的混合云平台。

同样值得考虑的是,你是否看好Kubernetes。这个平台如今非常流行(这也是谷歌和VMware选择它作为混合战略基础的部分原因),但它只有7年的历史。有理由认为Kubernetes更像是一种时尚,而不是一种长期的技术主流。

毕竟,五六年前,当Kubernetes只是一个没有人能说出名字的新贵项目时,Docker似乎要永远统治世界,那时候把你的工具与Docker结合似乎是一个稳妥的选择。但现在完全不是如此。

那么,致力于一个基于Kubernetes的混合平台,就有可能像是在2015年左右全力以赴押注Docker:只要炒作持续下去,它就会起作用,但当时尚消退时,你可能不得不重建一切。

灵活性是另一个需要考虑的因素。一般来说,基于Kubernetes的混合云比那些依赖云供应商专有工具的混合云更灵活。例如,如果你使用Azure Stack,那么很难迁移到AWS Outposts,因为这基本上相当于从Azure迁移到AWS。但是从Anthos迁移到Tanzu会更容易(虽然不是无缝的),因为这两个平台都是建立在Kubernetes之上的。

结论

有充分的理由选择Kubernetes作为混合云战略的基础。而选择一个不需要Kubernetes工具并且支持Kubernetes无法管理的工作负载类型的平台也有一些很好的理由。请想好。

前端程序员关于 Docker 和 Kubernetes 的一点疑惑

1 naoh1000 · 125 天前 via iPhone · 3897 次点击
这是一个创建于 125 天前的主题,其中的信息可能已经有所发展或是发生改变。
前端想要转后端的垃圾程序员,*近写了一些自己的项目,打算用 Docker 和 Kubernetes 部署,遇到了一些疑惑,查了很多资料后没有解决,希望大佬能够帮忙解答。

单节点服务有必要使用 k8s 吗? 官网写的 k8s 功能和优势大多数都表现在多服务器,项目初期只有一台服务器有必要使用 k8s 吗?
有必要自建 Docker Registry ? 如果项目都是在自己的服务器部署,有必要通过自建 Docker Registry 来绕开 Docker Hub 不充钱只能创建 1 个私有项目的限制吗?我看到一些个人开发者是在服务器上 git pull & docker build -t xxxx
多个项目应该使用多个数据库容器还是共用一个? 经常在搜索引擎上看到“数据库应该装在 Docker 里吗”这样的问题,不同人持不同看法。想知道如果我把数据库安装在 Docker 里,多个项目应该使用多个数据库容器还是共用一个?如果使用 Docker Compose 部署,大多数情况下每个项目都会自带一个数据库,是否会拖慢速度?这样的话如何方便的管理数据库里的数据?
如何方便的管理运行在一台服务器上的多个项目? 相互没有联系的容器。之前使用过 Docker Compose 管理,发现一个项目的容器启动后想关掉就只能关掉 docker-compose.yml 里的全部容器了,很不方便,现在自己写了一个 py 脚本管理,大佬们有没有更好的方法?
Docker 容器 数据库 k8s19 条回复 • 2020-12-05 22:55:13 +08:00
holulu 1
holulu 125 天前
直接去有 k8s 服务的云服务商上开集群就行了,数据库服务、Docker Registry 服务、部署管理服务啥都有,没必要自己折腾这么底层的。上面几点现在都是运维考虑的,开发者基本不考虑这些。
snowfuck 2
snowfuck 125 天前 ❤️ 1
1.没有,你的理解是对的; k8s 是应对大规模容器化部署运维的,没这个需要没有上的必要
2.没有,怎么方便怎么来
3.数据库用同一个会好一点,跑多个就要占用多份资源;可以看下别人的 compose 文件改下
4.docker-compose -f docker-compose.yaml stop xxx ; 这里的 xxx 是 compose 里定义的一个服务,是可以用 docker compose 管理单个服务的,有依赖另当别论

我不是大佬,一点浅见仅供参考。
cnbattle 3
cnbattle 125 天前 via Android
1 没必要
2 不用 可以用阿里云或腾讯云 等的免费的服务
3 只有一台服务器的话 ,没多版本需要,就用一个,否则多个
4 自己使用问题 可以指定停止

个人拙见
lizheming 4
lizheming 125 天前 via iPhone
1. 单机都是直接 docker-compose 超级方便
2. Github Registry 了解一下,可以私有项目传镜像哦
3. 数据库建议一个,这样备份也好备份呀~直接设置 net 在同一个网络下应该就行了
4. 楼上说的+1
lizheming 5
lizheming 125 天前 via iPhone
@cnbattle 阿里云镜像仓库好像是收费的?腾讯云的目前公测免费倒是。
yzbythesea 6
yzbythesea 125 天前
小项目不上云就用 docker compose
eudore 7
eudore 125 天前
1 、私人小项目就 rancher 或 docker compose
2 、Registry 除了 hub 还有各种云都有免费的使用。
3 、数据可以放 docker 里面,然后-v 把数据卷挂载进去就好了
4 、建议使用 rancher 就是一个 web 版 dockercompose,compose 我用的少,启动是可以指定配置文件去 up 的。
cnbattle 8
cnbattle 125 天前 ❤️ 1
@lizheming 有个人开发者免费的方案
lizheming 9
lizheming 125 天前 via iPhone
@cnbattle 原来如此!
ztechstack 10
ztechstack 125 天前
1. 单节点纯 docker 即可,3 节点以上可以使用 swarm 管理,一般上没有 20 台机器不推荐用 k8s 。
2. 单节点可以不折腾镜像仓库,如果服务器本地构建镜像可以不折腾,如果远程构建搭一个也很简单。
3. 公用一个数据库服务器(容器),我现在都是使用 docker 管理(包括一些生产环境),现在好一点的镜像都是使用外部数据库服务的。
4. 开源项目 portainer 了解一下,可视化管理。

echowuhao 11
echowuhao 125 天前
99%的项目不需要 k8s
yuzhiquan 12
yuzhiquan 125 天前
前端对应的概念不是 serverless 吗?
hantsy 13
hantsy 125 天前
Docker Compose 现在也支持云部署啦。
在 Docker Cloud 和 Docker Swarm 市场反响不好的情况,Docker 另辟途径,让 Docker Compose 规范去兼容 K8S,这个项目开发很长时间了,目前好像 AWS 可以用了。

https://aws.amazon.com/blogs/containers/deploy-applications-on-amazon-ecs-using-docker-compose/
hantsy 14
hantsy 125 天前
前端一样要用 Docker 啊。

可以在 CI 把项目编译把包,用 Docker Image 发布。
monkeyWie 15
monkeyWie 125 天前 via Android
单机可以试试 k3s
mauve 16
mauve 125 天前 via iPhone
gitlab 免费版全都有
hardy4y 17
hardy4y 125 天前
直接上阿里云的 serverless 不香吗?屏蔽了 node 的概念,不用关注又多少个节点,阿里云的 docker registry 也不收费啊.
单节点想用 k8s 的特性可以用 k3s.
mywaiting 18
mywaiting 124 天前
1 、单服务节点没有必要用 k8s,如果自己实在想用这类编排实现,建议可以试试 hashicorp nomad 比 k8s 心智负担少很多
2 、没有必要自建,Github 有
3 、项目有相关性的可以一个容器,无相关的多个容器。自己的项目还单节点服务器,一个容器简单方便
4 、见 2 楼现成的命令
chenqh 19
chenqh 124 天前
借楼问一下,docker-compose 怎么实现滚动重启 app?

如何将云原生工作负载映射到 Kubernetes 中的控制器

Kubernetes 不仅仅是一个容器管理工具。它是一个平台,旨在处理包装在任意数量的容器和组合中的各种工作负载。Kubernetes内置了多个控制器,可映射到云原生架构的各个层。

DevOps工程师可以将Kubernetes控制器视为指示团队运行的各种工作负载的基础架构需求的手段。他们可以通过声明方法定义所需的配置状态。例如,容器/pod作为ReplicationController的一部分部署保证始终可用。打包为DaemonSet的容器保证在集群的每个节点上运行。声明式的方法使DevOps团队能够利用代码控制基础架构。下面讨论的一些部署模式遵循不可变基础结构的原则,其中每个新的部署都会导致原子部署。

DevOps工程师可以通过声明方法定义所需的配置状态——每个工作负载映射到控制器。

了解云原生用例

Kubernetes的控制平面不断跟踪部署,以确保它们符合DevOps定义的所需配置状态。

Kubernetes的基本部署单位是一个pod。它是Kubernetes的基本构建块,是Kubernetes对象模型中*小和*简单的单元。pod表示集群上正在运行的进程。无论服务是有状态的还是无状态的,它总是打包并部署为pod。

控制器可以在集群中创建和管理多个pod,处理在集群范围内提供自我修复功能的副本。例如,如果节点发生故障,控制器可能会通过在不同节点上安排相同的pod用来自动替换该故障pod。

Kubernetes配有多个控制器,可以处理所需的pod状态。如ReplicationController、Deployment、DaemonSet和StatefulSet控制器。Kubernetes控制器使用提供的pod模板,来创建其负责pod的所需状态。与其他Kubernetes对象一样,Pod在YAML文件中定义并提交给控制平面。

在Kubernetes中运行云原生应用程序时,运维人员需要了解控制器解决的用例,以充分利用平台的特性。这有助于他们定义和维护应用程序的所需配置状态。

上一节中介绍的每种模式都映射到特定的Kubernetes控制器,这些控制器允许对Kubernetes的工作负载进行更精确,细粒度的控制,但是采用自动化方式。

Kubernetes的声明式配置鼓励不可变的基础架构。控制平面跟踪和管理部署,以确保在整个应用程序生命周期中维护所需的配置状态。与基于虚拟机的传统部署相比,DevOps工程师将花费更少的时间来维护工作负载。利用Kubernetes原语和部署模式的有效CI/CD策略使运营商无需执行繁琐的任务。

可扩展层:无状态工作负载

无状态工作负载在Kubernetes中打包并部署为ReplicaSet。ReplicationController构成ReplicaSet的基础,可确保在任何给定时间始终运行指定数量的pod副本。换句话说,ReplicationController确保一个pod或一组同类pod总是可用。

如果有太多pod,ReplicationController可能会终止额外的pod。如果太少,ReplicationController将继续启动其他pod。与手动创建的pod不同,ReplicationController维护的pod在失败,删除或终止时会自动替换。在诸如内核升级之类的破坏性维护之后,在节点上重新创建pod。因此,即使应用程序只需要一个pod,也建议使用ReplicationController。

一个简单的用例是创建一个ReplicationController对象,以无限期地可靠地运行pod的一个实例。更复杂的用例是运行横向扩展服务的几个相同副本,例如Web服务器。在Kubernetes中部署时,DevOps团队和运营商将无状态工作负载打包为ReplicationControllers。

在*近的Kubernetes版本中,ReplicaSets取代了ReplicationControllers。它们都针对相同的场景,但ReplicaSet使用基于 集合的标签选择器 ,这使得可以使用基于注释的复杂查询。此外,Kubernetes中的部署依赖于ReplicaSet。

Deployment是ReplicaSet的抽象。在Deployment对象中声明所需状态时,Deployment控制器会以受控速率将实际状态更改为所需状态。

强烈建议部署管理云原生应用程序的无状态服务。虽然服务可以部署为pod和ReplicaSet,但部署可以更轻松地升级和修补应用程序。DevOps团队可以使用部署来升级pod,而无法使用ReplicaSet完成。这样就可以在*短的停机时间内推出新版本的应用程序。部署为应用程序管理带来了类似于服务(PaaS)的功能。

持久层:有状态的工作量

状态工作负载可以分为两类:需要持久存储的服务(单实例)和需要以高可靠性和可用模式运行的服务(复制的多实例)。需要访问持久存储后端的pod与为关系数据库运行集群的一组pod非常不同。虽然前者需要长期持久的持久性,但后者需要高可用性的工作量。Kubernetes解决了这两种情况。

可以通过将底层存储暴露给服务的卷来支持单个pod。可以将卷映射到调度pod的任意节点。如果在集群的不同节点上调度多个pod并需要共享后端,则在部署应用程序之前手动配置分布式文件系统(如网络文件系统(NFS)或Gluster)。云原生态系统中提供的现代存储驱动程序提供容器本机存储,其中文件系统本身通过容器公开。当pod只需要持久性和持久性时,请使用此配置。

对于预计具有高可用性的场景,Kubernetes提供StatefulSets – 一组专门的pod,可确保pod的排序和唯一性。这在运行主要/辅助(以前称为主/从)数据库集群配置时尤其有用。

与部署类似,StatefulSet管理基于相同容器规范的pod。与Deployment不同,StatefulSet为其每个pod保留唯一标识。这些pod是根据相同的规范创建的,但不可互换:每个pod都有一个持久标识符,它可以在任何重新安排时保留。

StatefulSet对需要以下一项或多项的工作负载非常有用:

  • 稳定,独特的网络标识符。
  • 稳定,持久的存储。
  • 有序,优雅的部署和扩展。
  • 有序,优雅的删除和终止。
  • 有序的自动滚动更新。

Kubernetes对StatefulSets的处理方式与其他控制器不同。当正在使用N个副本调度StatefulSet的pod时,将按顺序创建它们,顺序从0到N-1。当删除StatefulSet的pod时,它们以相反的顺序终止,从N-1到0。在将一个扩展操作应用于pod之前,它的所有前驱必须正在运行并准备就绪。Kubernetes确保在终止pod之前,其所有后继者都完全关闭。

当服务需要运行Cassandra、MongoDB、MySQL、PostgreSQL集群或任何具有高可用性要求的数据库工作负载时,建议使用StatefulSet。

并非每个持久性工作负载都必须是StatefulSet。某些容器依赖于持久存储后端来存储数据。为了向这些类型的应用程序添加持久性,pod可能依赖于由基于主机的存储或容器本机存储后端支持的卷。

可并行化层:批处理

Kubernetes具有用于批处理的内置原语,这对于执行运行到完成作业或预定作业很有用。

运行到完成作业通常用于运行需要执行操作和退出的进程。在处理数据之前运行的大数据工作负载就是这种工作的一个例子。另一个示例是一个处理队列中每条消息的作业,直到队列变空。

作业是一个控制器,可以创建一个或多个pod并确保指定数量的pod成功终止。当pod成功完成后,Job会跟踪成功的完成情况。达到指定数量的成功完成后,作业本身就完成了。删除作业将清理它创建的pod。

Job还可以用于并行运行多个pod,这使其成为机器学习培训工作的理想选择。Job还支持并行处理一组独立但相关的工作项。

当Kubernetes在具有GPU的硬件上运行时,机器学习培训可以利用Job。诸如Kubeflow之类的新兴项目 – 一个致力于在Kubernetes上部署机器学习的简单,可移植和可扩展的项目 – 将把原始资料作为job包装到机器学习培训中。

除了运行并行化作业外,可能还需要运行预定作业。Kubernetes公开了CronJobs,它可以在指定的时间点运行一次,也可以在指定的时间点定期运行。Kubernetes中的CronJob对象类似于Unix中crontab(cron表)文件的一行。它以给定的时间表定期运行,以cron格式编写。

Cron作业对于安排定期作业(如数据库备份或发送电子邮件)特别有用。

事件驱动层:无服务器(Serverless)

无服务器计算(Serverless)是指构建和运行不需要服务器管理的应用程序的概念。它描述了一种更细粒度的部署模型,其中捆绑为一个或多个功能的应用程序上传到平台,然后执行,缩容和计费以响应当前所需的确切需求。

函数即服务(FaaS)在无服务器计算的环境中运行,以提供事件驱动的计算。开发人员使用由事件或HTTP请求触发的功能来运行和管理应用程序代码。开发人员将小型代码单元部署到FaaS,这些代码根据实际需要作为独立组件执行,无需管理服务器或任何其他底层基础架构即可进行扩展。

虽然Kubernetes没有集成的事件驱动原语来响应其他服务引发的警报和事件,但仍有努力引入事件驱动的功能。该云原生计算基金会 ,Kubernetes的托管者,一直专注于这些致力于无服务器的工作组。Apache OpenWhisk 、Fission 、Kubeless 、OpenFaaS 和 Oracle的Fn 等开源项目可以在Kubernetes集群中作为事件驱动的无服务器层运行。

在无服务器环境中部署的代码与打包为pod的代码根本不同。它由自治函数组成,可以连接到可能触发代码的一个或多个事件。

当事件驱动计算——无服务器计算成为Kubernetes不可或缺的一部分时,开发人员将能够部署响应Kubernetes控制平面生成的内部事件以及应用程序服务引发的自定义事件的函数。

遗留层:Headless Service

即使您的组织经常使用微服务架构构建和部署应用程序到云上的容器中,也可能有一些应用程序继续存在于Kubernetes之外。云原生应用程序和服务必须与那些传统的单一应用程序进行交互。

遗留层的存在是为了实现互操作性,以暴露一组指向单体应用程序的Headless Service。Headless Service允许开发人员通自由地以自己的方式进行服务发现来减少与Kubernetes系统的耦合。Kubernetes中的Headless Services与ClusterIP、NodePort和LoadBalancer类型的服务不同。它们没有分配给它们的Internet协议(IP)地址,但具有指向外部端点(如API Server、Web服务器和数据库)的域名系统(DNS)条目。遗留层是一个逻辑互操作性层,它将DNS记录维护到众所周知的外部端点。

微服务应用程序的每一层都可以映射到Kubernetes的一个控制器。根据希望部署的模式,DevOps团队可以进行相应的选择。在下一篇文章中,我们将讨论将云原生应用程序部署到Kubernetes的一些*佳实践。

关于作者

Janakiram MSV是Janakiram&Associates的首席分析师,也是国际信息技术学院的兼职教员。他还是Google认证云开发人员,亚马逊认证解决方案架构师,亚马逊认证开发人员,亚马逊认证SysOps管理员和Microsoft认证Azure专业人员。Janakiram是云原生计算基金会的大使,也是*早的认证Kubernetes管理员和认证Kubernetes应用程序开发人员之一。他之前的经历包括Microsoft、AWS、Gigaom Research和Alcatel-Lucent。

友情链接: SITEMAP | 旋风加速器官网 | 旋风软件中心 | textarea | 黑洞加速器 | jiaohess | 老王加速器 | 烧饼哥加速器 | 小蓝鸟 | tiktok加速器 | 旋风加速度器 | 旋风加速 | quickq加速器 | 飞驰加速器 | 飞鸟加速器 | 狗急加速器 | hammer加速器 | trafficace | 原子加速器 | 葫芦加速器 | 麦旋风 | 油管加速器 | anycastly | INS加速器 | INS加速器免费版 | 免费vqn加速外网 | 旋风加速器 | 快橙加速器 | 啊哈加速器 | 迷雾通 | 优途加速器 | 海外播 | 坚果加速器 | 海外vqn加速 | 蘑菇加速器 | 毛豆加速器 | 接码平台 | 接码S | 西柚加速器 | 快柠檬加速器 | 黑洞加速 | falemon | 快橙加速器 | anycast加速器 | ibaidu | moneytreeblog | 坚果加速器 | 派币加速器 | 飞鸟加速器 | 毛豆APP | PIKPAK | 安卓vqn免费 | 一元机场加速器 | 一元机场 | 老王加速器 | 黑洞加速器 | 白石山 | 小牛加速器 | 黑洞加速 | 迷雾通官网 | 迷雾通 | 迷雾通加速器 | 十大免费加速神器 | 猎豹加速器 | 蚂蚁加速器 | 坚果加速器 | 黑洞加速 | 银河加速器 | 猎豹加速器 | 海鸥加速器 | 芒果加速器 | 小牛加速器 | 极光加速器 | 黑洞加速 | movabletype中文网 | 猎豹加速器官网 | 烧饼哥加速器官网 | 旋风加速器度器 | 哔咔漫画 | PicACG | 雷霆加速