Kubernetes 开发者入门篇 · Jayleonc

Kubernetes 开发者入门篇

假设你是一位开发者，通过阅读该文章，你将了解到作为开发者应该掌握的 Kubernetes 的相关知识，辅助你的开发工作。当然，这是我的学习笔记，很开心它能帮助到你，如果可以的话。如果想要系统的学习 Kube，请运用强大的互联网，加油吧！

了解 Kubernetes

Kube 是一个完备的分布式系统支撑平台。

首先，它具有完备的集群管理能力，包括多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和服务发现机制、内建的智能负载均衡器、强大的故障发现和自我修复能力、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制，以及多粒度的资源配额管理能力。

同时，Kube 提供了完善的管理工具，这些工具覆盖了包括 开发、部署测试、运维监控在内的各个环节。因此，Kube 是一个全新的基于容器技术的分布式架构解决方案，并且是一个一站式的完备的分布式系统开发和支撑平台。

分布式计算：将系统想像成一个问题，在分布式计算中，一个问题被分为许多任务，每个任务由一台或多台计算机解决，这些计算机通过消息传递相互通信；因此 分布式计算 指使用 分布式系统 来解决实际问题。

分布式系统：由多个组件组成，其组件位于不同的计算机（服务器）上，这些计算机通过相互传递消息来通信和协商它们的操作。组件交互以实现共同目标（解决需求）。

更多关于分布式计算的内容，可 点击这里 进行学习，不过我更希望你专注于该文章的学习。

Kubernetes Basics 基础知识

Nodes，Pods，Containers，Deployments and Clusters

这里涉及 Kube 基本的运作方式，作为一名开发人员，这是你应该了解的 Kube 的最基本内容。

Node 节点

Node 是 Kube 集群中计算硬件的最小单元，换句话说，它是运行应用程序的单台机器，可以是物理服务器（Pyhsical），也可以是公有云中的虚拟机（Virtual） 。

在 Kube 集群中，我们无需担心单个服务器或虚拟机具有多少 内存 或 CPU，只需要根据规范配置将这些任务交给 Kube；此外，如果单个 Node 出现问题，可以轻松更换，Kube 会负责进行负载分配。

将多个 Node 组成一个节点池（Node Pools），部署服务时，Kube 会检查各个节点，并根据可用的 CPU、内存和其他特征选择一个节点提供服务。如果由于某种原因，该节点出现故障，Kube 会确保你的应用程序重新安排，即重新选择一个可用的节点，继续运行该应用程序，为你提供服务。（节点上，运行的就是你的应用程序，that’s right）

集群中可用有多个节点池（有时也称为 实例组）。在云中，很常见的做法是将节点池分离为 按需节点池（on-demand node pool）和 现成节点池（spot node pool） 。按需节点池：一个节点池中，有十个高 CPU 和低内存的节点来运行 CPU 密集型的任务；而另一个节点池中，则是高内存、低 CPU 。按需节点很好理解；对于现成节点池，Spot 实例就是更小的虚拟机，类似于轻量级服务器；对于客户来说，更小更便宜，成本低，扩展方便；对于提供商来说，他们最大限度地利用硬件，将这些计算服务器划分为更小的虚拟机，更灵活，最多程度利用他们手上未被使用的服务器资源。

不管是 按需节点池 还是 现成节点池，它们的组成，都是我们刚刚讨论的 Node，即 单台机器。

更多关于 Node 的内容，可以 点击这里 进行学习。

Persistent Volumes 持久卷

由于不能保证集群上运行的应用程序在特定节点上运行，即 负载均衡分配 的存在。在 Kube 中，不能使用本地磁盘（Node 机器上的本地磁盘，而不是你正在看该文章的设备本地磁盘）来保存任何数据。因为，如果应用程序在本地文件系统上保存了某数据，然后由于 负载分配，服务调用了另一个节点，那么该数据将不再存在，也就是说，数据不能跨节点，是的，这很好理解。

因此，只能使用本地磁盘作为缓存的临时位置，为了永久储存数据，Kube 使用持久卷 Persistent Volumnes。是的，让我们重新确认一下：虽然所有节点的 CPU 和 内存资源 都由 Kube 集群汇集和管理，但持久的文件存储并不是！相反，本地磁盘或云服务器，可以作为持久卷附加到集群中。换句话说，可以将本地磁盘视为外部硬盘驱动器插入集群，想像一下，将一个移动固态硬盘插入电脑，that’s right。持久卷提供了一个文件系统，可以在不与任何特定节点关联的情况下安装到集群。

更多关于 持久卷 的内容，可以 点击这里 进行学习。

Containers 容器

要在 Kube 集群上运行应用程序，需要将应用程序打包为 Linux Container，到这里 Docker 就要登场了。容器化允许我们创建独立 Linux 执行环境。任何应用程序及其依赖项都可以捆绑到一个 Image 中，然后轻松的分发。通过下载 Image 并将其部署到基础设施上，只需要很简单的设置。创建 Docker 镜像，将你的代码，单元测试等通过 Dockerfile 编译成 Image。在一个容器中，可以添加多个应用程序，如果可能，你应该将自己限制为每个容器设置一个进程，即一个程序，对应一个容器，也就对应一个进程，这很好理解，right？如果这里你读起来有一点费解，你只需要简单学习 Docker 的应用，这就是靠你自己啦。有很多的小容器比一个大容器更好，如果容器的重点很明确，更新就更容易部署，问题也就更容易调试。

更多关于 Containers 的内容，可以 点击这里 进行学习。

Pod

Kube 不直接运行容器，相反，它将一个或多个容器包装到一个称为 Pod 的更高级别的结构中。一个 Pod = 多个 Container。同一 Pod 中的任何容器都将共享相同的资源和本地网络。再说一遍，同一 Pod 中的任何容器都将共享相同的资源和本地网络。

容器可以轻松地与同一 Pod 中的其他容器通信，就好像它们在同一台机器上一样，同时与其他容易保持一定程序的隔离；类似于，电脑里不同的应用程序，你懂的。Pod 在 Kube 中可用作复制单元，如果应用程序需要扩展，你只需要增加 Pod 的数量即可。（通过配置文件配置，这很明显）

Kube 可以配置为根据负载自动扩展和缩小应用程序的规模。如何理解呢？你可以使用 CPU、内存，甚至自定义指标，是的还是通过配置文件。例如，对应用程序的请求数。通常，你会为同一个应用程序运行多个副本，以避免在某个节点出现问题时停机，也就是为了做负载嘛。

总结，作为一个可以有多个进程的容器，一个 Pod 里可以有多个容器，但是由于 Pod 是作为一个单元进行扩展和缩小的，Pod 中的所有容器都必须一起扩展，而不管它们各自的需求如何。这会导致资源浪费和昂贵的费用。所以，Pod 应尽可能小。通常只包含一个 主容器及其紧密耦合的辅助容器 sidecar。

更多关于 Pod 的内容，可以 点击这里 进行学习。

Deployment 部署

Pod 是 Kube 中的基本计算单元，但它们通常不会直接在集群中创建。相反，Kube 提供了另一个抽象级别，部署 Deployment。

Deployment 的主要目的是声明一次应该运行多少个 Pod 副本，当 Deployment 被添加到集群时，它会自动启动请求数量的 Pod（配置写 3 个 Pod，就启动 3 个），然后监控它们。如果 Pod 启动失败，Deployment 将自动重建它。使用 Deployment，你不必手动处理 Pod，通过配置，它会自动为你管理。

更多关于 Deployment 的内容，可以 点击这里 进行学习。

Load Balancer & Ingress 负载平衡器和网络入口

上面我们了解了 Kube 中的一些核心组件，通过 Deployment 部署 在集群中运行应用程序，但是我们如何将服务暴露给互联网？默认情况下，Kube 提供 Pod 与外界隔离，如果要与运行在 Pod 中的应用程序进行通信，则必须打开通信通道。有许多方法可以公开服务，暴露给互联网。

可选方案：Load Balancer 负责均衡器；Ingress 入口；Node Port（节点端口）；Proxy（代理）。

Load Balancer 负载均衡器：如果想直接暴露应用，可以使用 Load Balancer 负载均衡器，为每个负载均衡器映射一个应用程序。此时，你可以使用的协议有：TCP、UDP、gRPC、WebSockets 等。点击这里 学习更多关于 Load Balancer 的知识。

Ingress 入口：另一种主流的方法是 Ingress 入口控制器，Kube 有许多不用的 入口可用。使用 入口控制器时，可以在所有服务之间共享单个负载均衡器，并使用子域或路径（URL）将流量重定向到集群中的特定应用程序。入口控制器只允许使用 HTTP 和 HTTPS 协议。随着时间的推移，它的设置和维护要比简单的负载均衡器复杂得多，你懂的。点击这里 学习更多关于 Ingress 的知识。

更多关于服务暴露的知识，点击这里 进行学习。

Service

最后，我们还需要学习一个 Service 的概念。这可不太好理解了。你的拥有多个 API 的应用程序，就是一个 Service；假设 Nginx 是你的程序，那么 Nginx 就是你的应用程序，也就是你的 Service。OMG，可太抽象了。官网中给出的解释是：Kube 中的 Service 是 将运行在 Pod 上的应用程序，公开为 网络服务的 方法。听听，Service 是一种方法，这是抽象的，同时 Service 是 Kube 的核心。

Service 的服务进程通常基于 Socket 通信方式对外提供服务。这句话，是在某本书上看到的，让我来试着解答：“Service 的服务进程”，这里的服务进程，可以指我们编写的应用程序；“通过 Socket 的方式进行通信”，其实就是通过 TCP 协议进行通信，比如 Redis、MySQL、WebServer（应用程序）。

Service 的目标，让你无需修改现有的应用程序，就能使用不熟悉的服务发现机制。 – 来自官网

Service 有几个特点：

1. 拥有唯一指定的名称
2. 拥有一个虚拟 IP 地址（ClusterIP）和端口号（IP + Port）
3. 能够提供某种远程服务能力（如 Nginx 提供的能力，读到这里，你已经能够理解 Service 是个什么东西了）
4. 能够将客户端对服务的访问请求转发到一组容器应用上。

希望我可以帮助你理解 Kube 中的 Service，更多关于它的内容，你可以通过 点击这里 进行学习。