Kubernetes 概述:Pods、Nodes、Containers 和 Clusters
技术
作者:Docker
译者:郑云龙
2018-01-23 03:39

 Kubernetes 已经迅速成为在云中部署和管理软件的新的标准。尽管 Kubernetes 实力强劲,Kubernetes 的学习曲线却相对而言更陡峭。对于一个初学者,想要从官方文档 [1] 中深入了解  Kubernetes 会非常困难。Kubernetes 由很多不同的部分组成,因此很难说清楚哪些是和你的需求有关。这篇博客将会尝试提供一个 Kubernetes 的简化视图,并且尝试对重要的组件进行 High-level 的描述,以及它们是如何在一起工作的。

首先,我们先来看看硬件层面。

硬件 Hardware


节点 Node




Node 是 Kubernetes 中硬件的最小单元。它代表集群当中的一个单台主机。在大部分的生产系统中,Node 既可以是你数据中心中的一个物理主机也可以是托管在云平台(如 Google Cloud Platform )中的虚拟主机。当然你也不必限制于这些当中,从理论上讲,你可以将任何东西作为 Node,比如一个智能手表,或者树莓派。

把主机抽象成一个 Node 可以允许我们定义一个抽象层。从而可以不用担心单个主机的独立特性,我们可以简单的将每一个主机视为一组可以利用的 CPU 和 RAM 资源。这样 Kubernetes 集群中的任何一个主机都是可以替换的。

集群 Cluster




虽然在单个节点上处理任务也是可行的,但这并不是 Kubernetes 的风格。一般来说,你应该考虑整个集群的状态,而不是其中的某一个节点。


在 Kubernetes 中,将所有 Node 的资源集中在一起,从而形成了一台更加强大的“服务器”。 当你将你的应用部署到集群当中时,它可以自动的为你选择工作 Node 。如果有新的 Node 加入或者被移除,集群会自动将应用转移。对于应用程序或者程序员而言,代码到底运行在哪一个节点上显得并不重要。


这种类似于 hivemind 的系统可能让你联想到星际迷航中的 Brog[2] ,当然并不是只有你一个人会这么想,“Borg”也正是一个 Google 内部项目的名字,而 Kubernetes 正是在此项目基础上构建的。


持久卷 Presistent Volumes


由于在 Kubernetes 当中并不保证应用程序运行在集群中的特定节点上,因此数据不能直接保存到主机的文件系统上。如果应用程序把数据保存到文件系统中,而应用又被调度到其它节点上,那应用就无法找到想要的数据文件。因此对于传统的在每个节点上的本地存储应该被视为应用程序的临时缓存,而不应该在本地存储任何需要持久化的数据。




为了保存数据,Kubernetes 使用持久卷( Persistent Volumes )。尽管集群中所有节点的 CPU 和 RAM 都是有集群进行集中管理的,但是持久化文件存储并不是。相反,可以将本地或者云存储链接到集群当中。可以理解为将一个外部的硬盘插入到了集群这个“服务器”中。持久卷提供了一个文件系统,这个文件系统可以挂在到集群当中,而不需要关联任何特定的节点。


软件 Software

容器 Containers




运行在 Kubernetes 中的应用程序需要使用 Linux containers 进行打包。容器是一个广泛接受的标准,这里也已经有很多的已构建的镜像可以直接部署到 Kubernetes 当中。


容器化允许你创建一个包含 Linux 执行环境的独立空间。任何应用程序以及其依赖都可以被打包到一个文件中,并且在互联网上共享。任何人都可以下载容器并且通过极少的配置就可以将其部署到基础设施上。创建容器的过程也可以通过编程来实现,从而可以形成一个强大的 CI/CD 流水线。


虽然我们可以将多个应用程序打包到一个容器当中,但是对于你而言,最好还是尽可能保持一个容器中只包含一个单独的进程。相比于在一个容器包含多个进程而言,将这些进程拆分到不同的容器当中,可以让每个容器更加内聚,并且更易于更新和部署。同时在出问题时也更容易定位。

Pods




不同于你过去使用过的其它系统,Kubernetes 并不直接运行容器,取而代之的是使用了一个  high-level的抽象来包装一个或者多个容器,这个抽象被称为 Pod[3] 。在 Pod 中的任何容器都共享了容器命名空间以及本地网络。因此在 Pod 的容器直接可以非常方便的进行通讯,就好像它们是运行在同一个机器上一样,同时彼此之间又保持隔离。

Pod 同时也是 Kubernetes 中的最小调度单元。 如果你的应用编程非常受欢迎,单个 Pod 无法处理这样的负载。Kubernetes 可以在必要时创建并部署一个新的副本。即使在非高负载的情况下,在生成环境中运行多个 Pod 的副本可以有效的均衡负载并且避免故障的发生。

Pod 中可以包含多个容器,但是你还是应该尽可能的限制一下。因为 Pod 是作为一个最小单元,整体进行伸缩。这可能导致资源的浪费以及更多的费用开销。为了避免这种问题。Pod 应该尽可能的保持“小”,通常指应该包含一个主进程,以及与其紧密合作的辅助容器(这些辅助容器通常被称为Sidecar )。

部署 Deployments




虽然 Pod 是 Kubernetes 中的一个最小单元,但是通常我们并不在集群中直接部署一个 Pod。相反,Pod 通常应该被另外一个抽象 Deployment[4] 进行管理。


一个 Deployment 最主要的目的是用来声明需要有多少 Pod 的副本运行。当 Deployment 部署到集群之后,它会自动运行指定数量的 Pods,并且对这些 Pod 进行监控,如果有 Pod 的副本死掉了,Deployment 会自动创建新的实例。


使用 Deployment 后就不需要手动去管理 Pods,你只需要声明应用期望的状态,Deployment 会自动帮你管理应用。


路由入口 Ingress




使用上面的这些概念,你可以创建一个集群,并且在集群中通过  Deployment 来部署和管理 Pod。 这里还有最后一个问题需要解决:如何允许外部流量进入到你的应用程序。

默认情况下,Kubernetes 将 Pods 和外部网络环境进行了隔离。 如果你想要与运行在 Pod 中的服务进行通讯,那你必须要打开一个用于通讯的通道,这个通道就是 Ingress。

有许多方式可以将 Ingress 添加到你的集群当中。最普遍的方式是使用 Ingress Controller 或者负载均衡器。如果选择这两种方式已经超出了本文的范围,但是你必须意识到,在你尝试使用 Kubernetes 之前,你需要处理 Ingress 入口。


接下来做什么?


上面的部分介绍的是一个简化了的 Kubernetes 版本,但是应该可以给你在开始实验前必要的一些基础知识了。你已经了解了该系统的各个部分,现在你需要的是使用 Kubernetes 来部署一个真正的应用程序。 官方的 Kubernetes 教程 [5] 是一个很好的开始。

为了在本地试验 Kubernetes ,Minikube 可以帮助你在本地创建一个虚拟的集群。而如果你已经开始准备在云服务中尝试 Kubernetes 。 Google Kubenetes Engine 包含了一系列的教程 [6] 可以帮助你快速入门。

如果你是刚开始接触容器或者 Web 基础设施这个领域,我建议你可以先了解应用 12 要素 [7] 。12 要素中描述了当你在设计运行在类似于 Kubernetes 这样的平台上的应用程序时的最佳实践,这些都是需要时刻记住的东西。

相关链接:

  1. https://kubernetes.io/docs/concepts/
  2. http://memory-alpha.wikia.com/wiki/Borg
  3. https://kubernetes.io/docs/concepts/workloads/pods/pod/
  4. https://kubernetes.io/docs/concepts/workloads/controllers/deployment/
  5. https://kubernetes.io/docs/tutorials/kubernetes-basics/
  6. https://cloud.google.com/kubernetes-engine/docs/tutorials/
  7. https://12factor.net/

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

END

320 comCount 0