在 k8s 上部署应用

1.1 为什么需要容器

Kubernetes 是一个用于部署容器的平台。所有部署到 Kubernetes 的代码，比如你的应用程序，首先需要被打包成一个容器。那么，什么是容器，为什么我们要使用它们呢？

容器是现代打包和运行应用程序的方式。除非你在每个主机上只运行一个应用程序（这相当低效），你通常需要一种方式在一台机器上部署多个应用程序，或者在一组机器上部署。那么，我们有哪些选择呢？

在虚拟机（VMs）出现之前，常见的做法是在共享主机的不同目录中安装每个应用程序，然后在不同的端口上分别提供服务。

这带来了一些问题，因为不同的应用程序在共享依赖和机器资源（如 CPU、内存和可用端口）时，需要在一定程度上相互配合。此外，扩展也很困难：如果你有一个应用程序突然流量大增，你如何只扩展那个应用程序，而保持其他应用程序不变呢？

随着虚拟机的出现，解决方案是将每个应用程序打包进它自己的虚拟机中。这样，每个应用程序都有自己的操作系统环境，因此依赖可以被隔离，资源可以被划分和分配。然而，由于每个虚拟机都具有单独主机的复杂性，你现在需要维护每个应用程序的操作系统和所有软件包，这有很高的开销，维护起来也很复杂。

这就引出了容器。容器是一种只打包你的应用程序及其所需的依赖，然后在一个隔离的环境中运行的方式，就像虚拟机一样，但不需要安装和管理操作系统。

选择容器的一些主要原因包括语言灵活性（能够在容器平台上运行任何语言或环境）、轻量级隔离（在不使用虚拟机的情况下保护你的工作负载不受彼此干扰）、开发者效率（使生产环境更接近开发环境，并允许轻松设置）以及可复制性（在容器构建文件中记录创建环境的步骤）。

语言灵活性

容器让你从部署系统的语言或库要求中解放出来。你可以引入任何语言，并更新任何包。你不再被特定的语言和版本所限制，也不再受限于多年前操作系统中附带的关键依赖的过时版本，就像你可能在传统的平台即服务（PaaS）上遇到的那样。

在同一台主机上运行的两个容器之间没有共享库，这意味着一个容器的配置不会干扰另一个。需要两个不同版本的Java，或者一些随机的依赖？没问题。

这种隔离不仅仅局限于容器的库：每个容器可以使用完全不同的基础操作系统和包管理器，例如一个使用Debian和apt-get，而另一个使用CentOS和rpm。

这种灵活性使得将多个服务（一种被称为微服务的模式）串联成一个系统变得更简单，每个服务由不同的团队维护，拥有它们自己的依赖或语言。