Kubernetes 101

CNCF

发布于 2019-12-19 14:59:03

1K0

发布于 2019-12-19 14:59:03

文章被收录于专栏：CNCF

来自Sensu的Jef Spaleta的客座文章，最初发表在Sensu博客上

https://blog.sensu.io/kubernetes-101

在容器中运行工作负载的吸引力是直观的，这样做有很多原因。将流程及其依赖项发送到能够直接运行的包中，可以减少组织通信和操作的摩擦。与虚拟机相比，容器的大小、简单性和减少的开销是一个令人信服的理由。

在Docker已经成为科技界家喻户晓的名字的世界中，使用容器服务于生产是一个明显的需求，但是现实世界的系统需要许多容器一起工作。管理生产工作负载所需的大量容器会变得非常困难。

这就是Kubernetes存在的原因。

Kubernetes是一个用于在容器中运行工作负载的生产级平台。它的工作方式，从高层次上来说，是比较直接的。

你决定你的应用程序需要做什么。然后将软件打包到容器镜像中。然后，记录容器如何协同工作，包括网络、冗余、容错和健康探测。最终，Kubernetes将你所期望的状态变为现实。

但是你需要更多的细节才能使用它。在这篇文章中，我将用Kubernetes的一些基础知识来帮助奠定基础。

为什么使用Kubernetes？

构建系统是困难的。在构建一些重要的东西时，必须考虑许多相互竞争的优先级和移动的部分。此外，自动化和可重复性是当今文化的先决条件，这些文化要求快速周转、低缺陷率和对问题的即时响应。

我们需要所有能得到的帮助。

容器使部署可重复，并创建解决“在我的机器上能正常工作”问题的包。“然而，虽然在容器中有一个包含所有需要运行的流程是有帮助的，但是团队需要从他们的平台获得更多。他们需要能够从多个镜像创建多个容器来组成整个运行的系统。

“平台即服务”的公有云产品提供了部署应用程序的选项，而不必担心它们所运行的机器，以及减轻负担的弹性伸缩选项。Kubernetes为容器化的工作负载提供了类似的选项。团队详细说明了规模、冗余、可靠性、持久性、网络和其他需求，以及Kubernetes用于使系统恢复活力的manifest文件中的依赖性。

这意味着技术人员可以选择提供容器的可重复性、可替换性和可靠性，并结合平台即服务的便捷性、自动化和高性价比的解决方案。

Kubernetes是什么？

当人们描述Kubernetes时，他们通常将其称为容器编排服务。这是一种既好又不完整的方式来描述它是什么，它做了什么。

Kubernetes编排容器，这意味着它运行多个容器。此外，它还管理它们在哪里运作，以及如何展示它们的功能 - 但这只是开始。它还会主动监控正在运行的容器，以确保它们仍然是健康的。当它发现容器不处于良好的操作状态时，就用新的容器替换它们。Kubernetes还监视新的容器，以确保它们不仅在运行，而且准备好开始处理工作。

Kubernetes是一个全面的、生产级的应用程序执行和监控平台。它诞生于谷歌，后来开源。除了可以在数据中心中运行外，现在许多云提供商还将其作为服务提供。

你如何使用它？

设置Kubernetes集群可能非常复杂，也可能非常简单，这取决于你如何决定。最容易的是公有云提供商，包括亚马逊的AWS、微软的Azure和谷歌的谷歌云平台。他们的产品可以让你快速上手。

集群可以工作后，你可以考虑如何处理它。首先，你需要熟悉Kubernetes介绍的词汇。有很多术语是你想要熟悉的。这篇文章只包含你需要知道的Kubernetes词汇的一个子集；你可以在我们的“Kubernetes是如何工作”的文章中找到更完整的定义。

https://blog.sensu.io/how-kubernetes-works

最重要的概念是pods（豆荚）、deployments（部署）和services（服务）。我将在下面使用来自Sensu Go的监控示例来定义它们（有关使用senu监控Kubernetes的更多信息，请查看CTO Sean Porter的这篇文章，以及来自sensu-kube-demo仓库的示例）。

https://blog.sensu.io/monitoring-kubernetes-part-4-the-sensu-native-approach

https://github.com/sensu/sensu-kube-demo

豆荚：作为一个起点，你可以把豆荚想象成一个容器。实际上，pods是一个或多个容器一起工作，为系统的一部分提供服务。一个pod可能有多个容器是有原因的，比如在一个单独的容器中有一个支持的用于监视日志或应用程序健康状况的Sensu Go代理进程。pod抽象负责确保这些支持容器与主应用程序容器共享网络和存储资源。尽管存在这些情况，将豆荚看作一个容器的容器并不是有害的。许多豆荚只有一个容器。
部署：将相同类型的部署组豆荚放在一起以实现负载平衡。一个部署有一定数量的相同的豆荚和监视器，以确保许多豆荚保持运行和健康。部署可以很好地管理web应用程序之类的无状态工作负载，在这种情况下，相同应用程序的相同副本可以并行地运行到服务请求，而无需进行协调。
状态集（StatefulSets）：类似于部署，但用于相同应用程序的副本必须相互协调才能维护状态的应用程序。状态集管理豆荚唯一副本的生命周期。对于状态集来说，Sensu Go后台集群是一个不错的选择。每个Sensu Go后端都在卷挂载中保存自己的状态，并且必须通过可靠的网络链接与其他端进行协调。StatefulSet将Sensu Go后端pod的每个请求副本的生命周期管理为惟一的，以确保在需要替换不健康的pod时可以重用网络和存储资源。
服务：服务暴露你的部署。这种暴露可能是针对其他部署和/或外部世界。

你可以通过Kubernetes REST API与集群交互。与其自己构造HTTP请求，不如使用一个名为kubectl的方便的命令行工具。

Kubectl

Kubectl支持对集群发出命令。这些命令的形式如下：

kubectl [command] [TYPE] [NAME] [flags]

Kubernetes站点上有更完整的命令概览。

https://kubernetes.cn/docs/reference/kubectl/overview/

Config

kubectl工具可以很容易地使用macOS上的Homebrew、Windows上的Chocolatey或Linux上的发行版相应的包管理器一起安装。更好的是，在Mac或Windows上的Docker Desktop的最新版本（也很容易与Homebrew或Chocolatey一起安装）包括在工作站上安装本地单节点Kubernetes集群和kubectl。

https://kubernetes.cn/docs/tasks/tools/install-kubectl/

在你的工作站上安装了kubectl之后，你几乎可以开始向集群发出命令了。首先，你需要使用希望与之通信的任何集群进行配置和身份验证。

你可以使用kubectl config命令来设置对集群的访问，并在已配置的上下文之间进行切换。

https://kubernetes.cn/docs/tasks/access-application-cluster/configure-access-multiple-clusters/

Get，describe

访问设置好后，就可以开始发出命令了。你可能会经常使用kubectl get和kubectl describe命令，因为你将使用它们来查看pod、部署、服务和秘密等的状态。

get动词将列出你指定类型的资源：

kubectl get pods

上面将列出在你的集群中运行的pods（更准确地说，是在集群上的命名空间中运行的pods，但是在这增加了更多的复杂性）。

本例获取名为fun-pod的pod（如果存在这样的pod）。

kubectl get pod fun-pod

最后，动词describe给出了更多关于pod的细节。

kubectl describe pod fun-pod

Create，apply

使用以下内容有助于在集群中使用资源：

kubectl create

在学习之外，通常最好创建清单文件并使用kubectl apply将它们投入使用。这是一种从连续部署管道部署应用程序的特别好的方法。

团队用JSON或YAML编写manifests清单。这样的清单可以描述pod、服务、部署等。部署的规范包括定义一种pod类型应该复制多少次，以构成一个健康的、正在运行的部署。

这是一个清单的样例：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: webserver-deployment
  labels:
    app: webserver
spec:
  replicas: 2
  selector:
    matchLabels:
      app: webserver
  template:
    metadata:
      labels:
        app: webserver
    spec:
      containers:
      - name: webserver
        image: nginx:1.17.3
        ports:
        - containerPort: 80

Kubernetes使用以下命令创建或更新文件中的资源：