关于kubernetes:Kubernetes-实战-01-Kubernetes-介绍

简介 P2

Kubernetes 能主动调度、配置、监管和故障解决，使开发者能够自主部署利用，并且管制部署的频率，齐全脱离运维团队的帮忙。Kubernetes 同时能让运维团队监控整个零碎，并且在硬件故障时从新调度利用。P2

Kubernetes 形象了数据中心的硬件基础设施，使得对外裸露的只是一个微小的资源池。在部署多组件利用时，Kubernetes 会为每个组件都抉择一个适合的服务器，部署之后它可能保障每个组件能够轻易地发现其余组件，并彼此之间实现通信。P2

Kubernetes 零碎的需要 P2

近年来，应用程序的开发部署的变动起因：P2

• 大型单体利用被拆解为更多的小型微服务
• 利用运行所依赖的基础架构的变动

从单体利用到微服务 P2

单体利用由很多个组件组成，这些组件严密地耦合在一起，并且在同一个操作系统过程中运行，所以在开发、部署、治理的时候必须以同一个实体进行。P2

单体利用通常须要一台能为整个利用提供足够资源的高性能服务器，有两种办法能够应答一直增长的零碎负荷：P3

• 垂直扩大：晋升单机性能 —— 减少 CPU、内存或其余系统资源

  • 长处：不须要应用程序做任何变动
  • 毛病：老本很快会越来越高，并且通常会有瓶颈

• 程度扩大：减少服务器数量

  • 长处：能线性裁减零碎性能
  • 毛病：须要在架构层面反对程度扩大，局部组件难于甚至不太可能去做程度扩大（像关系型数据库）

所思

垂直扩大总会达到单机性能的极限，所以终极解决方案是程度扩大，同时也能够通过垂直扩大进行辅助。

认真回忆一下，发现咱们平时也是这样解决的。因为历史起因，咱们我的项目外围性能的大部分代码在同一个利用中，导致启动就会占用大量资源，单机解决能力较差。在经验各种配置下压测后，抉择了适合的配置，而后就间接程度扩大，并且逐步将一些压力大的接口拆成微服务提供接口或者间接解决各种申请。

如果单体利用的任何一个局部不能扩大，整个利用就不能扩大，除非咱们想方法把它拆离开。P3

将利用拆解为多个微服务 P3

服务之间能够通过相似 HTTP 这样的同步协定通信，也能够通过像 AMQP 这样的异步协定通信，并且微服务也能够选用最适宜的开发语言来实现。P3

每个微服务都是独立的，能够独立开发和部署。只有 API 不变或者向前兼容，改变一个微服务，并不会要求对其余微服务进行改变或者重新部署。P3

微服务的扩容 P3

单体零碎必须要对整个零碎扩容，而微服务只需针对单个服务扩容。因而，咱们能够抉择仅扩容那些须要更多资源的服务而放弃其余的服务依然维持在原来的规模。当单体利用因为其中一部分无奈扩容而整体被限度扩容时，能够把利用拆分成多个微服务，将能扩容的服务进行程度扩大，不能进行扩容的组件进行垂直扩大。P4

部署微服务 P4

当组件数量减少时，部署相干的决定就变得越来越艰难。因为不仅组件部署的组合数在减少，而且组件间依赖的组合数也在以更大的因素减少，并且配置工作变得繁杂易错，同时因为跨了多个过程和机器，调试代码和定位异样调用变得艰难。P4

环境需要的差别 P5

因为组件之间依赖的差异性，应用程序须要同一个库的不同版本是不可避免的。当多个利用在同一个主机上运行就有可能会有依赖抵触。P5

为应用程序提供一个统一的环境 P5

开发和运维团队须要解决的一个最大的问题是程序运行环境的差异性：P5

• 开发环境和生产环境之间
• 各个生产机器之间
• 生产机器环境随工夫的推移而变动

为了缩小会在生产环境才裸露的问题，最现实的做法就是让利用在开发和生产阶段能够运行在齐全一样的环境下，它们有齐全一样的操作系统、库、系统配置、网络环境和其余所有条件。这个环境不会随着工夫的推移而变动，并且在一台服务器上部署新的利用时，不会影响机器上已有的利用。P6

迈向继续交付：DevOps 和无运维 P6

在过来，开发团队的工作是创立利用并交付给运维团队，而后运维团队部署利用并使它运行。P6

而当初，让一个团队参加利用的开发、部署、运维的整个生命周期更好。这意味着开发者、QA 和运维团队彼此之间的单干须要贯通整个流程。这种实际被称为 DevOps。P6

带来的长处 P6

• 开发者更多地在生产环境中运行利用，能更好地了解用户的需要和问题、运维团队保护利用所面临的艰难
• 开发者更趋向于尽快公布上线，能进行疾速迭代
• 简化部署流程，开发者本人部署利用上线

让开发者和系统管理员做他们最善于的 P6

Kubernetes 通过对理论硬件做形象，而后将本身裸露成一个平台，用于部署和运行应用程序。它容许开发者本人配置和部署应用程序，而不须要系统管理员的任何帮忙，让系统管理员聚焦于放弃底层基础设施运行失常的同时，不须要关注理论运行在平台上的应用程序。P7

介绍容器技术 P7

Kubernetes 应用 Linux 容器技术来提供利用的隔离，须要先通过相熟容器的基本知识来更深刻地了解 Kubernetes。P7

什么是容器 P7

用 Linux 容器技术隔离组件 P7

容器容许你在同一台机器上运行多个服务，不仅提供不同的环境给每个服务，而且将它们互相隔离。容器相似虚拟机，但开销小很多。P7

一个容器里运行但过程实际上运行在宿主机的操作系统上，但容器里的过程依然是和宿主机的其余过程隔离的。对容器内的过程自身而言，就如同是在机器和操作系统上运行的惟一一个过程。P7

比拟虚拟机和容器 P8

容器更加轻量级，它容许在雷同的硬件上运行更多数量的组件。一个容器仅仅是运行在宿主机上被隔离的单个过程，仅耗费利用容器耗费的资源，不会有其余过程的开销。虚拟机则须要运行本人的一组零碎过程，会产生除了组件过程耗费以外的额定计算资源损耗。P8

因为虚拟机有额定开销，所以没有足够的资源给每个利用开一个专用的虚拟机，最终会将多个应用程序分组塞进每个虚拟机。而容器可能（也应该）让每个利用有一个容器，最终能够让同一台裸机上运行更多的应用程序。P8

运行在虚拟机里的应用程序会执行虚拟机操作系统的零碎调用，而后虚拟机内核会通过管理程序在宿主机上的物理 CPU 来执行 x86 指令。而运行在容器外部的应用程序执行的零碎调用都会由宿主机上的同一个内核执行，此内核是惟一一个在宿主机操作系统上执行 x86 指令的内核，CPU 也不须要做任何虚拟机所做的虚拟化。P8

虚拟机提供齐全隔离的环境，因为每个虚拟机运行在本人的 Linux 内核上，而容器都调用同一个内核，存在安全隐患。P9

每个虚拟机运行它本人的一组零碎服务，而容器则不会，因为它们都运行在同一个操作系统上。因而运行一个容器不必像虚拟机那样要开机，它的过程能够很快被启动。P10

容器实现隔离机制介绍 P10

• Linux 命名空间：使每个过程只看到它本人的零碎视图（文件、过程、网络接口、主机名等）
• Linux 控制组 (cgroups)：限度了过程能应用的资源量（CPU、内存、网络带宽等）

用 Linux 命名空间隔离过程 P10

默认状况下，每个 Linux 零碎最后仅有一个命名空间，所有系统资源（文件系统、用户 ID、网络接口等）属于这一个命名空间。你能创立额定等命名空间，以及在它们之间组织资源。对于一个过程，能够在其中一个命名空间中运行它，过程将只能看到同一个命名空间下的资源。P10

存在多种类型的多个命名空间，所以一个过程不仅只属于某一个命名空间，而属于每个类型的一个命名空间。P10

限度过程的可用资源 P11

cgroups 是一个 Linux 内核性能，它被用来限度一个过程或者一组过程的资源应用。一个过程的资源（CPU、内存、网络带宽等）使用量不能超过被调配的量。P11

Docker 容器平台介绍 P11

Docker 的概念 P11

Docker 是一个打包、散发和运行应用程序的平台，它容许将应用程序和应用程序所依赖的整个环境打包在一起。P11

三个次要概念组成了这种情景：P12

• 镜像：Docker 镜像里蕴含了打包的应用程序及其所依赖的环境
• 镜像仓库：Docker 镜像仓库用于寄存 Docker 镜像，以及促成不同人和不同电脑之间共享这些镜像
• 容器：Docker 容器通常是一个 Linux 容器，基于 Docker 镜像被创立。一个运行中的容器是一个运行在 Docker 主机上的过程，但它和主机，以及所有运行在主机上的其余过程都是隔离的。这个过程也是资源受限的，仅能拜访和应用调配给它的资源（CPU、内存等）

构建、散发和运行 Docker 镜像 P12

开发人员首先构建一个镜像，而后把镜像推到镜像仓库中，任何能够拜访镜像仓库的人都能够应用该镜像。而后，他们能够将镜像拉取到任何运行着 Docker 的机器上并运行镜像。Docker 会基于镜像创立一个独立的容器，并运行镜像中指定的可执行二进制文件。P12

比照虚拟机和 Docker 容器 P12

能够发现利用 A 和利用 B 无论是运行在虚拟机上还是作为两个拆散容器运行时都能够拜访雷同的二进制和库。P13

利用 A 和利用 B 能拜访雷同的文件是因为它们的容器是基于雷同根底层的镜像被创立的，原理将在镜像层中会介绍。

镜像层 P14

Docker 镜像由多层形成，不同镜像可能蕴含完全相同的层，因为这些 Docker 镜像都是基于另一个镜像之上构建的，不同的镜像都能应用雷同的父镜像作为它们的根底镜像。P14

镜像层不仅使散发高效，也有助于缩小镜像的存储空间。每一层仅被存一次，当基于雷同根底层的镜像被创立成两个容器时，它们就可能读雷同的文件。然而如果其中一个容器写入某些文件，另外一个是无奈看见文件变更的。因而，即便它们共享文件，依然彼此隔离。P14

容器镜像层是只读的。容器运行时，一个新的可写层在镜像层之上被创立。容器中过程写入位于底层的一个文件时，此文件的一个拷贝在顶层被创立，过程写的是此拷贝。P14

容器镜像可移植性的限度 P14

• 如果一个容器化的利用须要一个特定的内核版本，那么它可能不能在每台机器上都工作
• 如果一台机器上运行了一个不匹配的 Linux 内核版本，或者没有雷同内核模块可用，那么此利用就不能在其上运行
• 一个在特定硬件架构之上编译的容器化利用，只能在有雷同硬件架构的机器上运行（例如：不能将一个 x86 架构编译的利用容器化后，又冀望它能运行在 ARM 架构的机器上）

rkt —— 一个 Docker 的代替计划 P14

Docker 自身并不提供过程隔离，实际上容器是在 Linux 内核之上应用诸如 Linux 命名空间和 cgroups 之类的内核个性实现的，Docker 仅简化了这些个性的应用。P14

rkt（发音为 “rock-it”）是另外一个 Linux 容器引擎，强调安全性、可构建性并听从凋谢规范，目前曾经进行保护。P14

这里提到 rkt 的起因是，不应该谬误地认为 Kubernetes 是一个专门为 Docker 容器设计的容器编排零碎。实际上，Kubernetes 的外围远不止编排容器。容器恰好是在不同集群结点上运行利用的最佳形式。P15

Kubernetes 介绍 P15

深入浅出地理解 Kubernetes P15

Kubernetes 是一个软件系统，它容许你在其上很容易地部署和治理容器化的利用。它依赖于 Linux 容器的个性来运行异构利用，而无须晓得这些利用的外部详情，也不须要手动将这些利用部署到每台机器。因为这些利用运行在容器里，它们不会影响运行在同一台服务器上的其余利用。P15

Kubernetes 使你在数以千计的电脑节点上运行软件时就像所有的节点是单个大节点已有。它将底层基础设施形象，这样做同时简化了利用的开发、部署，以及对开发和运维团队对治理。P15

通过 Kubernetes 部署应用程序时，你对集群蕴含多少节点都是一样的。集群规模不会造成什么差异性，额定的集群节点只是代表一些额定的可用来部署利用的资源。P16

Kubernetes 的外围性能 P16

上图展现了一副最简略的 Kubernetes 零碎图。整个零碎由一个主节点和若干个工作节点组成。开发者把一个利用列表提交到主节点，Kubernetes 会将它们部署到集群的工作节点。组件被部署在哪个节点对于开发者和系统管理员来说都不必关怀。P16

开发者能制订一些利用必须一起运行，Kubernetes 将会在一个工作节点上部署它们。其余的将被扩散部署到集群中，然而不论部署在哪儿，它们都能以雷同的形式相互通信。P16

帮忙开发者聚焦外围利用性能 P16

Kubernetes 能够被当作集群的一个操作系统来对待。开发者能够依赖 Kubernetes 提供一些和根底相干的服务，包含服务发现、扩容、负载平衡、自复原，甚至集群的 leader 选举。P16

帮忙运维团队获取更高的资源利用率 P16

Kubernetes 能在任何工夫迁徙利用并通过混合和匹配利用来取得比手动调度高很多的资源利用率。P16

Kubernetes 集群架构 P17

在硬件级别，一个 Kubernetes 集群由很多节点组成，这些节点被分成以下两种类型：P17

• 主节点：承载着 Kubernetes 管制和治理整个集群零碎的控制面板
• 工作节点：运行用户理论部署的利用

控制面板 P17

控制面板用于管制集群并使它工作，控制面板的组件持有并管制集群状态。它蕴含多个组件，组件能够运行在单个主节点上或者通过正本别离部署在多个主节点以确保高可用性。P17

• Kubernetes API 服务器：你和其余控制面板组件都要和它通信
• Scheduler：调度你的利用（为利用的每个可部署组件调配一个工作节点）
• Controller Manager：执行集群级别的性能，如复制组件、继续跟踪工作节点、解决节点失败等
• etcd：一个牢靠的分布式数据存储，能长久化存储集群配置

工作节点 P17

工作节点是运行容器化利用的机器。运行、监控和治理应用服务的工作是由以下组件实现的：P17

• Docker, rkt 或其余的容器类型
• Kubelet：与 API 服务器通信，并治理它所在节点的容器
• Kubernetes Services Proxy (kube-proxy)：负责组件之间的负载平衡网络流量

在 Kubernetes 中运行利用 P18

在 Kubernetes 中运行利用的步骤：P18

1. 将利用打包进一个或多个容器镜像
2. 将那些镜像推送到镜像仓库
3. 将利用的形容公布到 Kubernetes API 服务器

利用的形容包含但不限于以下几点：P18

• 容器镜像或者蕴含应用程序组件的容器镜像
• 这些组件如何互相关联
• 哪些组件须要同时运行在同一个节点上
• 哪些组件不须要同时运行
• 哪些组件为外部或内部客户提供服务且应该通过单个 IP 地址裸露，并使其余组件能够发现

形容信息怎么成为一个运行的容器 P18

当 API 服务器解决利用的形容时，调度器调度指定的容器组到可用的工作节点上，调度是基于每组所需的计算资源，以及调度时每个节点未调配的资源。而后，那些节点上的 Kubelet 批示容器运行时（例如 Docker）拉取所需的镜像并运行容器。P18

上图能够帮忙更好地了解如何在 Kubernetes 中部署应用程序。利用描述符列出了四个容器，并将它们分为三组（这些汇合被称为 pod）。前两个 pod 只蕴含一个容器，而最初一个蕴含两个容器。这意味着两个容器都须要合作运行，不应该互相隔离。在每个 pod 旁边，还能够看到一个数字，示意须要并行运行的每个 pod 的正本数量。在向 Kubernetes 提交描述符之后，它将把每个 pod 的指定正本数量调度到可用的工作节点上。节点上的 Kubelets 将告知 Docker 从镜像仓库中拉取容器镜像并运行容器。P18

放弃容器运行 P18

一旦利用程序运行起来，Kubernetes 就会一直地确认应用程序的部署状态始终与你提供的形容相匹配。它会主动重启解体或进行响应的过程，并且能主动将故障节点上运行的所有容器迁徙到新节点运行。P18

扩大正本数量 P19

Kubernetes 能够依据批示减少附加的正本或者进行多余的正本，并且能依据实时指标（如 CPU 负载、内存耗费、每秒查问或应用程序公开的任何其余指标）主动调整正本数。P19

命中挪动指标 P19

能够通知 Kubernetes 哪些容器提供雷同的服务，而 Kubernetes 将通过一个动态 IP 地址裸露所有容器，并将该地址裸露给集群中运行的所有应用程序。这是通过环境变量实现的，然而客户端也能够通过良好的 DNS 查找服务 IP。kube-proxy 将确保到服务的连贯可在提供服务的所有容器中实现负载平衡。服务的 IP 地址放弃不变，因而客户端始终能够连贯到它的容器，即便它们在集群中挪动。P19

应用 Kubernetes 的益处 P20

• 简化应用程序部署：开发人员能够本人开始部署应用程序，根本不须要理解组成集群的服务器
• 更好地利用硬件：Kubernetes 依据应用程序的资源需要形容和每个节点上的可用资源抉择最合适的节点来运行应用程序
• 健康检查和自修复：Kubernetes 监控应用程序组件和它们运行的节点，并在节点呈现故障时主动将它们从新调度到其余节点
• 主动扩容：Kubernetes 能够监督每个应用程序应用的资源，并一直调整每个应用程序的运行实例数量

• 简化利用开发

  • 开发环境和生产环境一样有助于疾速发现 bug
  • 开发人员不须要实现他们通常会实现的个性，如：服务发现、扩容、负载平衡、自复原，甚至集群的 leader 选举
  • Kubernetes 能够自动检测一个利用的新版本是否有问题，如果有问题则立刻进行其滚动更新

最初再吐槽一下七牛容器云团队的翻译可能有些局部不太好，第一章经常出现翻译不通顺、有误的状况，最初一部分还把单词 DEVELOPMENT 看错成了 DEPLOYMENT，幸好期间不停对照英文电子版批改书上的谬误。

本文首发于公众号：满赋诸机（点击查看原文）开源在 GitHub：reading-notes/kubernetes-in-action