Kubernetes简介

概述

Kubernetes 是一个可移植、可扩大的开源平台，用于治理容器化的工作负载和服务，可促成申明式配置和自动化。 Kubernetes 领有一个宏大且快速增长的生态，其服务、反对和工具的应用范畴相当宽泛。

Kubernetes，又称为 k8s（首字母为 k、首字母与尾字母之间有 8 个字符、尾字母为 s，所以简称 k8s）或者简称为 "kube" ，是一种可主动施行 Linux 容器操作的开源平台。它能够帮忙用户省去利用容器化过程的许多手动部署和扩大操作。也就是说，您能够将运行 Linux 容器的多组主机汇集在一起，由 Kubernetes 帮忙您轻松高效地治理这些集群。而且，这些集群可跨公共云、公有云或混合云部署主机。因而，对于要求疾速扩大的云原生利用而言（例如借助 Apache Kafka 进行的实时数据流解决），Kubernetes 是现实的托管平台。

起源

随着以 docker 代表的 linux 容器技术的利用场景越来越广，如何在大型的应用服务治理成千盈百个容器成为了一个令人头痛的问题，docker 官网给出了docker compose + swarm 的计划来解决大规模容器部署的挑战。

Kubernetes 这个名字源于希腊语，意为“舵手”或“飞行员”。k8s 这个缩写是因为 k 和 s 之间有八个字符的关系。 Google 在 2014 年开源了 Kubernetes 我的项目。 Kubernetes 建设在 Google 大规模运行生产工作负载十几年教训的根底上， 联合了社区中最优良的想法和实际。

容器编排

容器编排是指自动化容器的部署、治理、扩大和联网。容器编排能够帮忙您在不同环境中部署雷同的利用，而无需从新设计。利用编排来治理容器的生命周期也为将编排集成到 CI/CD 工作流中的 DevOps 团队提供了反对。与利用编程接口（API）和 DevOps 团队一样，容器化微服务也是云原生利用的重要根底。

为什么须要 Kubernetes？

真正的生产型利用会波及多个容器。这些容器必须跨多个服务器主机进行部署。容器安全性须要多层部署，因而可能会比较复杂。但 Kubernetes 有助于解决这一问题。Kubernetes 能够提供所需的编排和治理性能，以便您针对这些工作负载大规模部署容器。借助 Kubernetes 编排性能，您能够构建跨多个容器的应用服务、跨集群调度、扩大这些容器，并长期继续治理这些容器的健康状况。有了 Kubernetes，您便可切实采取一些措施来进步 IT 安全性。

Kubernetes 为你提供：

服务发现和负载平衡

Kubernetes 能够应用 DNS 名称或本人的 IP 地址来曝露容器。 如果进入容器的流量很大， Kubernetes 能够负载平衡并调配网络流量，从而使部署稳固。

存储编排

Kubernetes 容许你主动挂载你抉择的存储系统，例如本地存储、公共云提供商等。

主动部署和回滚

你能够应用 Kubernetes 形容已部署容器的所需状态， 它能够以受控的速率将理论状态更改为冀望状态。 例如，你能够自动化 Kubernetes 来为你的部署创立新容器， 删除现有容器并将它们的所有资源用于新容器。

主动实现装箱计算

你为 Kubernetes 提供许多节点组成的集群，在这个集群上运行容器化的工作。 你通知 Kubernetes 每个容器须要多少 CPU 和内存 (RAM)。 Kubernetes 能够将这些容器按理论状况调度到你的节点上，以最佳形式利用你的资源。

自我修复

Kubernetes 将重新启动失败的容器、替换容器、杀死不响应用户定义的运行状况查看的容器， 并且在筹备好服务之前不将其通告给客户端。

密钥与配置管理

Kubernetes 容许你存储和治理敏感信息，例如明码、OAuth 令牌和 ssh 密钥。 你能够在不重建容器镜像的状况下部署和更新密钥和应用程序配置，也无需在堆栈配置中裸露密钥。

Kubernetes 不是什么？

Kubernetes 不是传统的、无所不包的 PaaS（平台即服务）零碎。 因为 Kubernetes 是在容器级别运行，而非在硬件级别，它提供了 PaaS 产品共有的一些广泛实用的性能， 例如部署、扩大、负载平衡，容许用户集成他们的日志记录、监控和警报计划。 然而，Kubernetes 不是单体式（monolithic）零碎，那些默认解决方案都是可选、可插拔的。 Kubernetes 为构建开发人员平台提供了根底，然而在重要的中央保留了用户选择权，能有更高的灵活性。

Kubernetes：

  1. 不限度反对的应用程序类型。 Kubernetes 旨在反对极其多种多样的工作负载，包含无状态、有状态和数据处理工作负载。 如果应用程序能够在容器中运行，那么它应该能够在 Kubernetes 上很好地运行。
    不部署源代码，也不构建你的应用程序。 继续集成（CI）、交付和部署（CI/CD）工作流取决于组织的文化和偏好以及技术要求。
    不提供应用程序级别的服务作为内置服务，例如中间件（例如消息中间件）、 数据处理框架（例如 Spark）、数据库（例如 MySQL）、缓存、集群存储系统 （例如 Ceph）。这样的组件能够在 Kubernetes 上运行，并且/或者能够由运行在 Kubernetes 上的应用程序通过可移植机制 （例如凋谢服务代理）来拜访。
  2. 不是日志记录、监督或警报的解决方案。 它集成了一些性能作为概念证实，并提供了收集和导出指标的机制。
  3. 不提供也不要求配置用的语言、零碎（例如 jsonnet），它提供了申明性 API， 该申明性 API 能够由任意模式的申明性标准所形成。
  4. 不提供也不采纳任何全面的机器配置、保护、治理或自我修复零碎。

Kubernetes 架构

管制立体组件（Control Plane Components）

管制立体组件会为集群做出全局决策，比方资源的调度。以及检测和响应集群事件，例如当不满足部署的 replicas 字段时， 要启动新的 pod）。

管制立体组件能够在集群中的任何节点上运行。 然而，为了简略起见，设置脚本通常会在同一个计算机上启动所有管制立体组件， 并且不会在此计算机上运行用户容器。 请参阅应用 kubeadm 构建高可用性集群 中对于跨多机器管制立体设置的示例。

管制立体包含组件: kube-apiserver, etcd, kube-scheduler, kube-controller-manager, kubelet。

工作立体组件（Work Plane Components）

工作立体组件运行在工作节点中, 提供 Kubernetes 中的 Pod 所需的运行环境。

工作立体组包含组件: kubelet, kube-proxy, 容器运行时。

Kubernetes 组件

kube-apiserver

API 服务器是 Kubernetes 管制立体的组件， 该组件负责公开了 Kubernetes API，负责解决承受申请的工作。 API 服务器是 Kubernetes 管制立体的前端。

Kubernetes API 服务器的次要实现是 kube-apiserver。 kube-apiserver 设计上思考了程度扩缩，也就是说，它可通过部署多个实例来进行扩缩。 你能够运行 kube-apiserver 的多个实例，并在这些实例之间均衡流量。

etcd

统一且高度可用的键值存储，用作 Kubernetes 的所有集群数据的后盾数据库。

如果你的 Kubernetes 集群应用 etcd 作为其后盾数据库， 请确保你针对这些数据有一份 备份打算。

你能够在官网文档中找到无关 etcd 的深刻常识。

kube-scheduler

kube-scheduler 是管制立体的组件， 负责监督新创建的、未指定运行节点（node）的 Pods， 并抉择节点来让 Pod 在下面运行。

调度决策思考的因素包含单个 Pod 及 Pods 汇合的资源需要、软硬件及策略束缚、 亲和性及反亲和性标准、数据地位、工作负载间的烦扰及最初时限。

kube-controller-manager

kube-controller-manager 是管制立体的组件， 负责运行控制器过程。

从逻辑上讲， 每个控制器都是一个独自的过程， 然而为了升高复杂性，它们都被编译到同一个可执行文件，并在同一个过程中运行。

这些控制器包含：

节点控制器（Node Controller）：负责在节点呈现故障时进行告诉和响应
工作控制器（Job Controller）：监测代表一次性工作的 Job 对象，而后创立 Pods 来运行这些工作直至实现
端点控制器（Endpoints Controller）：填充端点（Endpoints）对象（即退出 Service 与 Pod）
服务帐户和令牌控制器（Service Account & Token Controllers）：为新的命名空间创立默认帐户和 API 拜访令牌
cloud-controller-manager
一个 Kubernetes 管制立体组件， 嵌入了特定于云平台的管制逻辑。 云控制器管理器（Cloud Controller Manager）容许你将你的集群连贯到云提供商的 API 之上， 并将与该云平台交互的组件同与你的集群交互的组件拆散开来。
cloud-controller-manager 仅运行特定于云平台的控制器。 因而如果你在本人的环境中运行 Kubernetes，或者在本地计算机中运行学习环境， 所部署的集群不须要有云控制器管理器。

与 kube-controller-manager 相似，cloud-controller-manager 将若干逻辑上独立的管制回路组合到同一个可执行文件中， 供你以同一过程的形式运行。 你能够对其执行程度扩容（运行不止一个正本）以晋升性能或者加强容错能力。

上面的控制器都蕴含对云平台驱动的依赖：

节点控制器（Node Controller）：用于在节点终止响应后查看云提供商以确定节点是否已被删除
路由控制器（Route Controller）：用于在底层云基础架构中设置路由
服务控制器（Service Controller）：用于创立、更新和删除云提供商负载均衡器

kubelet

kubelet 会在集群中每个节点（node）上运行。 它保障容器（containers）都运行在 Pod 中。

kubelet 接管一组通过各类机制提供给它的 PodSpecs， 确保这些 PodSpecs 中形容的容器处于运行状态且衰弱。 kubelet 不会治理不是由 Kubernetes 创立的容器。

kube-proxy

kube-proxy 是集群中每个节点（node）所上运行的网络代理， 实现 Kubernetes 服务（Service） 概念的一部分。

kube-proxy 保护节点上的一些网络规定， 这些网络规定会容许从集群外部或内部的网络会话与 Pod 进行网络通信。

如果操作系统提供了可用的数据包过滤层，则 kube-proxy 会通过它来实现网络规定。 否则，kube-proxy 仅做流量转发。

容器运行时（Container Runtime）

容器运行环境是负责运行容器的软件。

Kubernetes 反对许多容器运行环境，例如 containerd、 CRI-O 以及 Kubernetes CRI (容器运行环境接口) 的其余任何实现。

Kubernetes 相干术语

和其它技术一样，Kubernetes 也会采纳一些专用的词汇，这可能会对初学者了解和把握这项技术造成肯定的阻碍。为了帮忙您理解 Kubernetes，咱们在上面来解释一些罕用术语。

治理节点（Master）： 用于管制 Kubernetes 节点的计算机。所有任务分配都来自于此。
工作节点（WorkNode）：负责执行申请和所分配任务的计算机。由 Kubernetes 主机负责对节点进行管制。
容器集（Pods）：被部署在单个节点上的，且蕴含一个或多个容器的容器组。同一容器集中的所有容器共享同一个 IP 地址、IPC、主机名称及其它资源。容器集会将网络和存储从底层容器中形象进去。这样，您就能更加轻松地在集群中挪动容器。
复制控制器（Replication controller）：用于管制应在集群某处运行的完全相同的容器集正本数量。
服务（Service）：将工作内容与容器集拆散。Kubernetes 服务代理会主动将服务申请散发到正确的容器集——无论这个容器集会移到集群中的哪个地位，甚至能够被替换掉。
Kubelet：运行在节点上的服务，可读取容器清单（container manifest），确保指定的容器启动并运行。
kubectl： Kubernetes 的命令行配置工具。
kubeadm: 疾速构建 Kubernetes 集群的官网工具。

更多技术分享浏览我的博客：

https://thierryzhou.github.io

参考

  • [1] [kubenretes官网文档] (https://kubernetes.io/zh-cn/d...)

本文由mdnice多平台公布