【三小时学会Kubernetes！（二） 】Kubernetes 简介及Pod实践

Kubernetes 简介

我向你保证我没有夸大其词，读完本文你会问“为什么我们不称它为 Supernetes？”

Kubernetes 是什么？

从容器启动微服务后，我们有一个问题，让我们通过如下问答的形式具体描述这个问题：

问：我们怎么扩大或缩小容器？

答：我们启动另外一个容器。

问：我们如何在容器间分摊负荷？如果当前服务器的负荷达到最大，那我们是否需要另外一个服务器？我们如何最大化硬件使用率？

答：唔......呃......（让我搜一下）

问：如果在打更新补丁的时候，不影响到所有的服务？如果服务出了问题，如何才能返回之前能正常工作的版本？

Kubernetes 可以解决以上所有问题（以及更多问题！）。我可以用一句话总结 Kubernetes：“Kubernetes 是容器控制平台，可以抽象所有的底层基础设施（容器运行用到的基础设施）。”

我们对容器控制平台有个模糊的概念。在本文后续部分，我们将看看它的实际应用，但是这是第一次我们提到“底层基础设施的抽象”，所以我们来详细看看这个概念。

底层基础设施的抽象

Kubernetes 通过一个简单的 API 提供底层基础设施的抽象，我们可以向该 API 发送请求。这些请求可以让 Kubernetes
尽最大能力应对。例如，可以简单地要求“Kubernetes 添加映像 x 的 4 个容器。”然后 Kubernetes
会找出使用中的节点，并在内添加新的容器（如图 12 所示）。

这对开发人员来说意味着什么？意味着开发人员不需要在意节点的数目，也不需要在意从哪里运行容器以及如何与它们交流。开发人员不需要管理硬件优化，或担心节点关闭（它们将遵循墨菲法则），因为新的节点会添加到
Kubernetes 集群。同时 Kubernetes 会在其他运行的节点中添加容器。Kubernetes 会发挥最大的作用。

在图 2 中我们看到了一些新东西：

• API服务器：与集群交互的唯一方式。负责启动或停止另外一个容器，或检查当前状态，日志等；
• Kubelet：监视节点内的容器，并与主节点交流；
• Pod：初始阶段我们可以把 pod 当成容器。

就介绍这么多，跟深入的介绍会导致我们分心，我们可以等到后面一点再介绍，有一些有用的资源，比如官方文档，或者阅读 Marko Lukša
的著作《Kubernetes in Action》，以及 Sébastien Goasguen & Michael Hausenblas
的《Kubernetes Cookbook》。

标准化的云服务提供商

Kubernetes 另外一个深入人心的点是：它标准化了云服务提供商。这是一个很大胆的宣言，我们通过如下例子来具体看一看：

比如，有一个 Azure、Google 云平台或其他云服务提供商的专家，他担任了一个搭建在全新的云服务提供商的项目。这可能引起很多后果，比如说：他可能无法在截止期限内完成；公司可能需要招聘更多相关的人员，等等。

相对的，Kubernetes 就没有这个问题。因为不论是哪家云服务提供商，你都可以在上面运行相同的命令。你可以以既定的方式向 API 服务器发送请求。Kubernetes 会负责抽象，并实装这家云服务商。

停一秒钟仔细想一下，这是极其强有力的功能。对公司来说，这意味着他们不需要绑定到一家云服务商。他们可以计算别家云服务商的开销，然后转移到别家。他们依旧可以保留原来的专家，保留原来的人员，他们还可以花更少的钱。

说了这么多，在下一节中让我们来实际使用 Kubernetes。

Kubernetes 实践——Pod

我们建立了微服务在容器上运行，虽然颇为坎坷，但还是可以工作的。我们还提到这种解决方案不具有伸缩性和弹性，而 Kubernetes 可以解决这些问题。在本文的后续章节，我们会将各个服务转移到由 Kubernetes 管理的容器中，如图 13 所示。

在本文中，我们将使用 Minikube 进行本地调试，尽管所有东西都是运行在 Azure 和 Google 云平台中的。

安装和启动 Minikube

请参阅安装 Minikube 的官方文档：

• https://kubernetes.io/docs/tasks/tools/install-minikube/
  在安装 Minikube 的同时，你可以捎带着安装 Kubectl。Kubectl 是向 Kubernetes API 服务器发送请求的客户端。

可以通过运行 minikube start 命令启动 Minikube，在启动后，运行 kubectl get nodes 命令可以得到如下结果：

kubectl get nodes
NAME       STATUS    ROLES     AGE       VERSION
minikube   Ready     <none>    11m       v1.9.0

Minikube 提供给我们的 Kubernetes 集群只有一个节点，但是记住我们并不在乎有多少个节点，Kubernetes 会负责抽象，对我们来说深入掌握 Kubernetes 并不重要。

在下一节中，我们将介绍 Kubernetes 的第一个资源：Pod。

Pod

我大爱容器，相信现在你也很喜欢容器。那为什么 Kubernetes 给我们最小的可部署计算单元 Pod 呢？Pod是干什么的？由一个或一组容器组成的 Pod 可以共享相同的运行环境。

但是我们真的需要在一个 Pod 内运行两个容器吗？呃……一般来说，只会运行一个容器，我们的例子中也是这样的。但是有些情况下，比如两个容器需要共享卷，或它们之间是通过跨进程的交流方式交流的，又或者它们被绑到一起，那么就可以使用 Pod。Pod 的另一个特征是：如果我们希望使用其他 Rke 等技术的话，我们可以做到不依赖 Docker 容器。

图14：Pod 属性

总的来说，Pod 的主要属性包括（如图 14 所示）：

• 每个 Pod 可以在 Kubernetes 集群内拥有唯一的 IP 地址；
• Pod 可以拥有多个容器。这些容器共享同一个端口空间，所以他们可以通过 localhost 交流（可想而知它们无法使用相同的端口），与其他 Pod 内容器的交流可以通过结合 Pod 的 IP 完成；
• 一个 Pod 内的容器共享同一个卷、同一个 IP、端口空间、IPC 命名空间。

注：容器有个自己独立的文件系统，尽管他们可以通过 Kubernetes 的资源卷共享数据。
更多详细内容，请参阅相关的官方文档：

https://kubernetes.io/docs/concepts/workloads/pods/pod/

Pod 的定义

如下是我们的第一个 pod sa-frontend 的清单文件，我们会对文件内容进行逐一解释。

apiVersion: v1
kind: Pod                                            # 1
metadata:
  name: sa-frontend                                  # 2
spec:                                                # 3
  containers:
    - image: rinormaloku/sentiment-analysis-frontend # 4
      name: sa-frontend                              # 5
      ports:
        - containerPort: 80                          # 6

#1 kind：指定我们想创建的 Kubernetes 资源的类型。这里是 Pod。

#2 name：定义该资源的名字。我们在这里命名为 sa-frontend。

#3 spec：该对象定义了资源应有的状态。Pod Spec 中最重要的属性是容器的数组。

#4 image：是指我们希望在本 Pod 中启动的容器的映像。

#5 name：Pod 中容器中唯一的名字。

#6 containerPort：是指容器监听的端口号。这只是为了提供文档信息（即便没有这个端口也不会影响访问）。

创建 SA Frontend 的 Pod

你可以在 resource-manifests/sa-frontend-pod.yaml 中找到上述 Pod 的定义。你可以在终端中进入该文件夹，或在命令行输入完整的路径。然后执行如下命令：

kubectl create -f sa-frontend-pod.yaml
pod "sa-frontend" created

可以通过如下命令确认 Pod：

kubectl get pods
NAME                          READY     STATUS    RESTARTS   AGE
sa-frontend                   1/1       Running   0          7s

如果该 Pod 还处于容器生成中的状态的话，你可以在运行命令的时候加入参数 --watch，当 Pod 进入运行状态的时候，终端会显示信息。

从外部访问应用程序

为了从外部访问应用程序，我们需要创建服务类型的Kubernetes资源，具体内容我们将在后续章节讲解，虽然通过服务类型的资源支持外部访问是更合适的做法，但是此处为了快速调试，我们还有另外一个办法，即转发端口：

kubectl port-forward sa-frontend-pod 88:80
Forwarding from 127.0.0.1:88 -> 80

在浏览器中访问 127.0.0.1:88，即可打开 React 应用程序。

扩大规模的错误方法

我们说过 Kubernetes 的主要特色之一就是伸缩性，为了证明这一点，让我们运行另外一个 Pod。我们通过如下定义创建另外一个 Pod 资源：

apiVersion: v1
kind: Pod
metadata:
  name: sa-frontend2      # The only change
spec:
  containers:
    - image: rinormaloku/sentiment-analysis-frontend
      name: sa-frontend
      ports:
        - containerPort: 80

然后，通过如下命令创建新的 Pod：

kubectl create -f sa-frontend-pod2.yaml
pod "sa-frontend2" created

可以通过如下命令确认第二个 Pod：

kubectl get pods
NAME                          READY     STATUS    RESTARTS   AGE
sa-frontend                   1/1       Running   0          7s
sa-frontend2                  1/1       Running   0          7s

现在我们有两个运行中的 Pod。

请注意：这不是最终的解决方案，还有很多缺陷。我们将在另一个 Kubernetes 资源的部署一节中改善这个方案。

总结 Pod

提供静态文件的 Nginx 网络服务器在另个不同的 Pod 内运行。现在我们有两个问题：

• 怎样对外开放这些服务，让用户通过 URL 来访问它们？
• 怎样平衡 Pod 之间的负荷？
  

Kubernetes 提供了服务类型的资源。在下一节中我们将详细介绍。

来自：CSDN（微信号：CSDNnews），作者：Rinor Maloku，译者：弯月，责编：郭芮