Kubernetes介绍

Kubernete介绍

Kubernetes使开发者可以自主部署应用, 并且控制部署的频率, 完全脱离运维团队的版主. Kubernetes同时能够让运维团队监控整个系统, 并且在硬件故障时重新调度应用. 系统管理员的工作重心, 从监管应用转移到了监管Kubernetes, 以及剩余的系统资源, 因为Kubernetes会帮助监管所有的应用.

Kubernetes系统的需求

从单体应用到微服务

单体应用由很多个组件构成, 这些组件紧密地耦合在一起, 由于它们在同一操作系统进程中运行, 所以在开发, 部署, 管理的时候必须以同一个实体运行. 对单体应用来说, 即使是某个组件中一个小的修改, 都需要重新部署整个应用. 组件间缺乏严格的边界定义, 相互依赖, 日积月累导致系统复杂度提升, 整体质量也急剧恶化.

将应用拆解为多个微服务

这个问题迫使我们将复杂的大体单体应用, 拆分为小的可独立部署的微服务组件. 每个微服务以独立的进程运行, 并通过简单且定义良好的接口(API)与其他的微服务通信.

因为每个微服务都是独立的进程, 提供相对静态的API, 所以独立开发和部署单个微服务成为了可能. 只要API不变或者向前兼容, 改动一个微服务, 并不会要求其他微服务进行改动或重新部署.

微服务的扩容

面向单体系统, 扩容针对的是整个系统, 而面向微服务架构, 库容却只需要针对单个服务, 这意味着你可以选择扩容那些需要更多资源的服务而保持其他的服务仍然维持在原来的规模.

部署微服务

像大多数情况一样, 微服务也有缺点. 部署微服务, 部署者需要正确地配置所有服务来使其作为一个单一系统能正确工作, 随着微服务的数量不断增加, 配置工作变得冗余且易错.

微服务还带来其他问题, 比如因为垮了多个进程和机器, 使得调试代码和定位异常调用变得困难.

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

不管你同时开发和部署多少个独立组件, 开发和运维团队总是需要解决的一个最大的问题是程序运行环境的差异性. 为了减少会在生产环境才会暴露的问题, 最理想的做法是让应用在开发和生产可以运行在完全一样的环境下.

迈向持续交付: DevOps和无运维

让同一个团队参与应用的开发, 部署, 运维的整个生命周期更好. 这意味着开发, QA和运维团队彼此之间的合作需要贯穿整个流程. 这种实践称为DevOps.

理想情况是, 开发者自己部署程序本身, 不需要知道硬件基础设施的任何情况, 也不需要和运维团队交涉, 这被叫作NoOps. 很明显, 你仍然需要有一些人来关心硬件基础设施, 但这些人不需要再处理应用程序的独特性.

正如你所看到的, Kubernetes能让我们实现所有这些想法. 通过对实际硬件做抽象, 然后将自身暴露成一个平台, 用于部署和运行应用程序. 它允许开发者自己配置和部署应用程序, 而不需要系统管理员的任何帮助, 让系统管理员聚焦于保持底层基础设施运转正常的同时, 不需要关注实际运行在平台上的应用程序.

介绍容器技术

Kubernetes使用Linux容器技术来提供应用隔离.

什么是容器

当一个应用程序仅由较少数量的大组件构成时, 完全可以接受给每个组件分配专用的虚拟机, 以及通过给每个组件提供自己的操作系统实例来隔离它们的环境. 当时当这些组件开始变小且数量开始增长时, 如果你不想浪费硬件资源, 又想持续压低硬件成本, 就不能给每个组件配置一个虚拟机了.

用Linux容器技术隔离组件

开发者不是使用虚拟机来隔离每个微服务环境, 而是正在转向Linux容器技术. 容器允许你在同一台机器上运行多个服务, 不经是提供不同的环境给每个服务, 而且将它们互相隔离. 容器类似虚拟机, 但开销小很多.

一个容器里运行的进程实际上运行在宿主机的操作系统上, 就像所有其他进程一样(不像虚拟机, 进程是运行在不同的操作系统上的). 但在容器里的进程仍然是和其他进程隔离的. 对于容器内进程本身而言, 就好像是在机器和操作系统上运行的唯一一个进程.

比较虚拟机和容器

和虚拟机计较, 容器更加轻量级, 它允许在相同的硬件上运行更多数量的组件. 主要是因为每个虚拟机需要运行自己的一组系统进程, 这就产生了除组件进程消耗以外的额外计算资源损耗. 从另一方面说, 一个容器仅仅是运行在宿主机上被隔离的单个进程, 仅消耗应用容器消耗的资源, 不会有其他进程的开销.

虚拟机需要一个管理程序, 它将物理硬件资源分成较小部分的虚拟硬件资源, 从而被每个虚拟机里的操作系统使用. 运行在那些虚拟机里的应用程序会执行虚拟机操作系统的系统调用, 然后虚拟机内核会通过管理程序在宿主机上的物理CPU执行指令.

多个容器则会完全执行运行在宿主机上的同一个内核的系统调用, 此内核是唯一一个在宿主机操作系统上执行指令的内核. CPU也不需要做任何对虚拟机那样的虚拟化.

虚拟机的主要好处是它们提供完全隔离的环境, 因为每个虚拟机运行在它自己的Linux内核上, 而容器都是调用同一个内核, 这自然会有安全隐患. 如果你的硬件资源有限, 那当你有少量进程需要隔离的时候, 虚拟机就可以成为一个选项. 为了在同一台机器上运行大量被隔离的进程, 容器因它的低消耗而成为一个更好的选择.

容器实现隔离机制介绍

容器如何隔离进程的, 有两个机制可用: 第一个是Linux命名空间, 它使每个进程只能看到它自己的系统视图(文件, 进程, 网络接口, 主机名等); 第二个是Linux控制组(cgroups), 它限制了进程能使用的资源量(CPU, 内存, 网络带宽等).

用Linux命名空间隔离进程

默认情况下, 每个Linux系统最初仅有一个命名空间. 所有系统资源(诸如文件系统, 用户ID, 网络接口等)属于这一个命名空间. 但是你能创建额外的命名空间, 以及在它们之间组织资源. 对于进程, 可以在其中一个命名空间中运行它. 进程将只能看到同一个命名空间下的资源. 当然, 会存在多种类型的多个命名空间, 所以一个进程不单单只属于某一个命名空间, 而属于每个类型的一个命名空间.

存在以下类型的命名空间:

1. Mount(mnt)
2. Process(pid)
3. Network(net)
4. Inter-process communication(ipd)
5. UTS
6. User Id(user)

每种命名空间被用来隔离一组特定的资源.

限制进程的可用资源

另外的隔离性就是限制容器能使用的系统资源. 这通过cgroups来实现. cgroups是一个Linux内核功能, 它被用来限制一个进程或者一组进程的资源使用. 一个进程的资源(CPU, 内存, 网络带宽等)使用量不能超出被分配使用的量. 这种方式下, 进程不能过分使用为其他进程保留的资源, 这和进程运行在不同的机器上是类似的.

Docker容器平台介绍

Docker不仅简化了打包应用的流程, 也简化了打包应用的库和依赖, 甚至整个操作系统地文件都能被打包成一个简单的可移植的包, 这个包可以被用来在任何其他运行Docker的机器上使用.

Docker的概念

Docker是一个打包, 分发和运行应用程序的平台. Docker中三个主要的概念.

1. 镜像: Docker镜像里包含了你打包的应用程序及其所依赖的环境. 它包含应用程序可用的文件系统和其他元数据, 如镜像运行时的可执行文件路径.
2. 镜像仓库: Docker镜像仓库用于存放Docker镜像, 以及促进不同人和不同电脑之间共享这些镜像.
3. 容器: Docker容器通常是一个Linux容器, 它基于Dokcer镜像被创建. 一个运行中的容器是一个运行在Docker主机的进程, 但它和主机, 以及所有运行在主机的其他进程都是隔离的. 这个进程也是资源受限的, 意味着它只能访问和使用分配给它的资源(CPU, 内存等).

镜像层

层不仅使分发更高效, 也助于减少镜像的存储空间. 每一层被存一次, 当基于相同基础层的镜像被创建成两个容器时, 它们就能够读取相同的文件. 但是如果其中一个容器写入某些文件, 另外一个是无法看见文件变更的. 因此, 即使它们共享文件, 仍然彼此隔离. 这是因为容器镜像层是只读的. 容器运行时, 一个新的可写在镜像层之上被创建. 容器中进程写入位于底层的一个文件时, 此文件的一个拷贝在顶层被创建, 进程写的是此拷贝.

容器镜像可移植性的限制

理论上, 一个容器镜像能运行在任何一个运行Docker的机器上. 但是如果一个容器化的应用需要一个特定的内核版本, 那它可能不能在每台机器上都工作. 如果一台机器运行了一个不匹配的Linux内核版本, 或者没有相同内核模块可用, 那么此应用就不能在其上运行.

Kubernetes介绍

深入浅出地了解Kubernetes

Kubernets是一个软件系统, 它允许你在其上很容易地部署和管理容器化的应用. Kubernetes使你在数以千计的电脑节点上运行软件时就像所有节点是单个大节点一样.

Kubenetes的核心功能

整个系统由一个主节点和若干个工作节点组成. 开发者把一个应用列表提交到主节点, Kubernetes会将它们部署到集群的工作节点.

开发者能指定一些应用必须一起运行, Kubernets将会在一个工作节点上部署它们. 其他的将被分散部署到集群中, 但是不管部署在哪儿, 它们都能以相同的方式相互通信.

Kubernetes集群架构

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

1. 主节点: 它承载着Kubernetes控制和管理整个集群系统地控制面板
2. 工作节点: 它们运行用户实际部署的应用

控制面板

控制面板用于控制集群并使它工作. 它包含多个组件, 组件可以运行在单个主节点或者通过副本分别部署在多个主节点以确保高可用性. 这些组件是:

1. Kubernetes API服务器, 你和其他控制面板组件都要和它通信.
2. Scheduler, 它调度你的应用(为应用的每个部署组件分配一个工作节点).
3. Controller Mananger, 它执行集群基本的工作, 如复制组件, 持续跟踪工作节点, 处理节点失败等.
4. etcd, 一个可靠的分布式数据存储, 它能持久化存储集群配置.

控制面板的组件持有并控制集群状态, 但是它们不运行你的应用程序. 这是由工作节点完成的.

工作节点

工作节点是运行容器化应用的机器. 运行, 监控和管理应用服务的任务是由以下组件完成的:

1. Docker, rtk或其他的容器类型
2. Kubelet, 它与API服务器通信, 并管理它所在节点的容器
3. Kubernetes Service Proxy(kube-proxy), 它负责组件之间的负载均衡网络流量

在Kubernetes中运行应用

描述信息怎样成为一个运行的容器

当API服务器处理应用描述时, 调度器选择可用的工作节点. 选择时基于所需要的计算资源, 以及调度时每个节点未分配的资源. 然后, 那些节点上的Kubelet指示容器运行时拉取所需要的镜像并运行容器.

保持容器运行

一旦应用程序运行起来, Kubernetes就会不断地确认应用程序的部署状态始终与你提供的描述相匹配. 如果实例之一停止了正常工作, 比如进程崩溃或停止响应时, Kubernetes将自动重启它.

同理, 如果整个工作节点死亡或无法访问, Kubernetes将为在故障节点上运行的所有容器选择新节点, 并在新选择地节点上运行它们.

扩展副本数量

当应用程序运行时, 可以决定要增加或减少副本量, 而Kubernetes将分别增加附加的或停止多余的副本. 甚至可以把决定最佳副本数目的工作交给Kubernetes. 它可以根据实时指标(CPU负载, 内存消耗, 每秒查询或应用程序公开的任何其他指标)自动调整副本数.

命中移动目标

Kubernetes可能需要在集群中迁移你的容器. 当它们运行的节点失败时, 或者为了给其他容器腾出地方而从节点移除时, 就会发生这种情况.

为了让客户能够轻松找到提供特定服务的容器, 可以告诉Kubernetes哪些容器提供相同的服务, 而Kubernetes将通过一个静态IP地址暴露所有容器, 并将该地址暴露给集群中运行的所有应用程序. 这是通过环境变量完成的, 但是客户端也可以通过良好的DNS查找服务器IP. 服务的IP地址保持不变, 因此客户端始终可以连接到它的容器, 即使它们在集群中移动.

使用Kubernetes的好处

如果在所有服务器上都部署了Kubernetes, 那么运维团队就不需要在部署应用程序.

简化应用程序部署

由于Kubernetes将其所有工作节点作为一个部署平台, 因此应用程序开发人员可以开始自己开始部署应用程序, 不需要了解组成集群的服务器.

健康检查和自修复

当服务器发生故障时, 拥有一个允许在任何时候跨集群迁移应用程序的系统也很有价值.

Kubernetes监控你的应用程序组件和它们运行的节点, 并在节点出现故障时自动将它们重新调度到其他节点. 这使运维团队不必手动迁移应用程序组件, 并允许团队立即专注与修复节点本身, 并将其修好送回到可用的硬件资源池中.