Kubernetes Clusters Nodes Pods Containers

Kubernetes is an open-source system for automating deployment, scaling, and management of containerzied applications.
– from kubernetes.io

https://medium.com/google-cloud/kubernetes-101-pods-nodes-containers-and-clusters-c1509e409e16

Kubernetes 目前快速成为云上部署、管理程序的新标准。然而学习 Kubernetes 提供的所有功能的学习曲线是非常陡峭的。作为新一个 Kubernetes 初学者,试图通过官方文档学习是非常难的。在使用过程中有很多困难,很难说清是由什么引起的错误。这篇博文将以提供 Kubernetes 简单试图,将重要组件一起表示出来。

首先,让我们看一下硬件表示方式

Hardware

Node

nodes

在 Kubernetes 中一个节点是一个非常小的电脑硬件单元。它在你的的集群中代表着单个设备。在大多生产环境系统中,一个节点要么是在一个数据中心中的物理机器,或者像 Google Cloud Platform 这样提供一个虚拟机器。但是不要让约定限制住你,从理论上讲,你几乎可以创造一个节点。

我们将机器上插入一层抽象成为节点。现在,我们可以将每台机器视为一组可用的 CPU 和 RAM 资源,而不用担心每一台设备的特性。在这种方式下,任何机器可以代替 Kubernetes 集群中其他任何机器。

Cluster

cluster

虽然单个节点是有用的,但是这不是 Kubernetes 的方式。通常,你可以考虑将集群作为一个整体,而不是担心节点的状态。

在 Kubernetes 中,节点池的资源一起提供一个强有力的设备。当你发布程序到集群时,它将只能为你分发到各个节点。如果节点需要添加或者移除,集群将根据需要移动节点。对于程序或者程序员来说并不关心哪些机器实际上是运行代码的设备。

If this kind of hivemind-like system reminds you of the Borg from Star Trek, you’re not alone; “Borg” 是谷歌基于 Kubernetes 的内部项目代号。

Persistent Volumes

persistent

由于无法保证在集群上运行的程序在特定节点上运行,因此无法将数据保存到文件系统中任何位置。如果程序试图将数据保存供日后使用,但随着重新定位到新的节点,文件将不再是程序期望的那样。因此,传统的本地存储对于每个节点是为了为应用程序提供临时高速缓存,但是不能将本地保存作为数据持久化。

为了永久存储数据,Kubernetes 使用 Persistent Volumes。虽然所有节点的 CPU 和 RAM 资源都由集群汇集管理,但是文件存储却不是。相关,本地或云可以作为 Persistent Volume 附加到
集群上。这种方式可以看作为一个集群上的外部插件。 Persistent Volumes 提供了一个文件系统可以挂在到集群上,而不依赖任何特定节点。

Software

container

程序是作为包在 Linux 容器上运行的。容器是一种被广泛接受的标准,因此已经有许多预构建的镜像可以再 Kubernetes 上部署。

容器化允许你创建包含 Liux 执行环境的容器。任何程序所需要的依赖都可以捆绑到一个文件上,然后在互联网上共享。任何人只需要很少的设置就可以下载容器并部署到他们自己的基础设施上。可以通过编程方式创建容器,从而与 CI 和 CD 形成互通。

多个程序可以被添加到单个容器,但是你应该尽可能限制你自己一个容器只有一个进程。多个小容器比一个大容器更好一些。如果每个容器只聚焦在一个很小的方面,能更快速更新部署并且非常容易找到问题。

Pods

不像你过去使用的系统,Kubernetes 不能直接运行容器;相反,它将一个或多个容器包装在一个叫做 Pod 更高级别的结构中。任何容器在同一 Pod 中它们将共享相同资源和本地网络。容器可以很容易与同一 Pod 中其它容器通信,就像他们在同一机器上,而与其他容器又相互隔离。

Pod 在 Kubernetes 中是用于复制的单元,如果你的应用非常受欢迎并且单个 Pod 实例不能承载它,Kubernetes 可以在集群上发布几个副本。及时不在很强的负载中,它也可以在生产环境中任何时间标准付复制出多个副本来负载均衡和抵抗故障。

Pods 可以有多个容器,但是你应该可能的限制容器数。由于 pod 是作为一个单元复制和移除的,因此需要副本时, pod 中所有容器是一起作为副本的。这导致资源的浪费和昂贵的账单。为了解决这个问题, pod 应该尽可能小,通常只保持一个主进程和其紧密系相连的其它辅助容器。(其他辅助容器通常称为”side-cars”)

deployments

deloyments

尽管 pods 是 Kubernetes 中最小的基本单元,但是它们不能直接运行在集群上。而是 pods 通常是通过一个或者多个 deployment 抽象层管理。

deployment 主要目的是声明一次运行多少个 pod。将 deployment 添加到群集后,它将自动启动计算的 pod 数量,然后监视它们。如果 pod 销毁,deployment 将自动重新创建它。

使用 deployment ,你不必手动处理 pod。你只需声明所需的系统状态,即可自动为你管理。

Ingress

Ingress

使用上述概念,您可以创建节点集群,并将 pod 的 deployment 启动到集群上。但是,还有一个问题需要解决:允许外部流量到你的应用程序。

默认情况下,Kubernetes 提供 pod 和外部世界之间的隔离。如果要与在 pod 中运行的服务进行通信,则必须打开通信通道。这被称 Ingress。

有多种方法可以向群集添加入口。最常见的方法是添加 Ingress Controller 或 LoadBalancer。这两个选项之间的确切权衡超出了本文的范围,但您必须意识到在你尝试使用 Kubernetes 之前需要处理入口。

架构

Kubernetes 架构