一起使用Kubernetes和Docker的优点

February

修改于 2018-11-23 14:17:29

5.6K0

修改于 2018-11-23 14:17:29

文章被收录于专栏：技术翻译技术翻译

您可能会听到很多关于Kubernetes和Docker的信息 -您可能想知道哪一个更好。

嗯，没有“更好”，因为这些不是等同的东西。Docker就像一架飞机，Kubernetes就像一个机场。你不会问“我应该用什么来旅行 - 机场和飞机？” 所以它就像Docker和Kubernetes一起使用。你需要两者。

在这篇文章中，我们将介绍一个部署场景，容器和协调器如何提供帮助，以及开发人员如何每天使用它们。你将离开这篇文章，了解拼图的所有部分是如何组合在一起的。

一切都始于您的本地环境

因此，让我从一个在每次部署中挣扎的人的生活中开始。然后我将解释这两种技术如何提供帮助。出于实际目的，我们将讨论虚构的开发人员John Smith。John是一名为创业公司工作的开发人员，他负责将他的代码部署到实时环境中。

John有两个应用程序：一个在.NET Core中，另一个在Node.js. 每当新版本的语言，框架或库出现并且他必须进行升级时，他就会挣扎。问题是当事情与他安装的东西不兼容时。当某些东西不起作用时，他只需安装，卸载，更新或删除，直到最后事情重新启动并运行。当他将所有这些改变到另一个环境后必须推动一个新的变化时，斗争变得更大。当我们匆忙时，很难记住所有步骤。

一个解决方案可能是他使用虚拟机（VM）。这样，他可以隔离所有依赖项，并避免影响任何现有的应用程序及其依赖项

虽然这可行，但它不会扩展。为什么？因为每次有变化，他都必须拍摄新的快照。然后他必须以某种方式组织这些VM快照的所有不同版本。他仍然需要将代码和任何依赖项的更改部署到其他环境。现在，他也可以在其他环境中搞砸了，然后修复它，这没关系。但是，当我们谈论生产时，事情就会变得有风险。他必须使用类似生产的环境来简化部署并降低风险。这很难做到。

即使实现了自动化，部署也可能过于复杂或痛苦。也许约翰甚至不得不花费整个周末进行部署并修复各种破碎的东西。

我们都希望部署可能像按下按钮一样无聊。好消息是，这就是Docker和Kubernetes发挥作用的地方。

使用Docker打包并发送您的应用程序

那么，Docker到底是什么？

Docker是一家提供容器平台的公司。容器是一种将一块软件打包并与其运行所需的一切隔离的方法。我的意思是“隔离”，因为容器可以从运行它的主机分配不同的资源。您可能认为这听起来与VM非常相似，但区别在于容器更轻量级：它们不需要另外的操作系统来运行软件。容器可以让您更灵活，构建安全便携的应用程序，这样您就可以在完成基础架构时节省一些基础架构成本。

我知道这听起来像是教科书的定义，所以让我们看看约翰生活中的这一天如何有益。

让我们说约翰决定开始他的集装箱之旅。他了解到Docker容器使用基本映像作为运行应用程序的基础。基本映像及其所有依赖项在名为“Dockerfile”的文件中描述。在Dockerfile中，您可以为想要运行应用程序的任何人定义类似于通常在文档中（或在您的脑海中）的配方。他从.NET Core应用程序开始，Dockerfile看起来像这样。看一看：

FROM microsoft/aspnetcore-build:2.0 AS build-env
WORKDIR /app
# Copy csproj and restore as distinct layers
COPY *.csproj ./
RUN dotnet restore
# Copy everything else and build
COPY . ./
RUN dotnet publish -c Release -o out
# Build runtime image
FROM microsoft/aspnetcore:2.0
WORKDIR /app
COPY --from=build-env /app/out .
ENTRYPOINT ["dotnet", "hello.dll"]

正如您所看到的，就像您在编程一样。唯一的区别是您只是定义所有依赖项并声明如何构建和运行应用程序。

John需要将该文件放在源代码的根目录中并运行以下命令：

docker build -t dotnetapp .

此命令将创建一个包含已编译代码及其所有依赖项的映像。他只会做一次“构建”，因为我的想法是让应用程序可移植到任何地方运行。因此，当他想运行应用程序时，只需要安装Docker。他只需要运行以下命令：

搬运工 运行 - d  - p  80：80  dotnetapp

此命令将开始在主机的端口80上运行应用程序。无论他在哪里运行这个命令都没关系。只要端口80未使用，该应用程序就可以运行。

John现在准备将应用程序发送到任何地方，因为他将它打包在Docker容器中。

那为什么这样更好？好吧，约翰不必担心忘记他在本地计算机或任何其他服务器上安装的内容。当团队成长时，新的开发人员将迅速开始编码。当约翰的公司聘请一名业务人员时，新员工将知道容器中包含的具体内容。如果他们想要对框架或某些依赖项进行升级，他们就会这样做，而不必担心会影响当前的工作。

使用Docker打包并发送您的应用程序，而不必担心应用程序是否会在本地测试后在其他地方工作。如果它适用于您的机器，它将在其他机器上运行。

使用Kubernetes部署和扩展您的应用程序

所以，John现在只需要去他想要发送应用程序并启动容器的每个服务器。让我们说，在生产中，他有十台服务器来支持流量负载。他必须在所有服务器上运行上一个命令。如果由于某种原因容器死了，他必须去那个服务器并运行命令再次启动它。

等待。这听起来不像是一种改进，对吗？它与启动虚拟机没什么不同。当事情发生时，他仍然需要再次手动启动容器。他也可以自动完成这项任务，但他需要考虑健康检查和可用资源等事项。所以这就是Kubernetes发挥作用的地方。

Kubernetes，正如他们的网站所说，“是一个开源系统，用于自动化容器化应用程序的部署，扩展和管理。” 它的类型更多，但Kubernetes是目前最受欢迎的类型。Kubernetes执行容器编排，因此您不必编写这些任务的脚本。这是将应用程序容器化后的下一步，以及如何在生产中大规模运行容器。

Kubernetes将帮助您在任何地方以相同的方式部署。为什么？因为您只需要用声明性语言说明您希望如何运行容器。您将拥有一个负载均衡器，最少量的容器运行，以及仅在需要时可以向上或向下扩展的功能 - 您需要单独创建和配置的东西。你将拥有大规模运行所需的一切，并且你可以在同一个地方拥有它们。但这不仅仅是那个。由于Minikube，您现在还可以让自己的Kubernetes集群在本地运行。或者您可以使用Docker，因为Docker现在正式支持Kubernetes。

所以，回到约翰。他可以定义他希望如何大规模部署名为“dotnetapp”的应用程序。

查看“dotnetapp-deployment.yaml”文件，其中John定义了如何在Kubernetes集群中进行部署，包括在容器级别的所有依赖项。在这种情况下，除了启动dotnetapp之外，它还使用容器启动数据库。这是文件的外观：

apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: dotnetapp
spec:
replicas: 3
strategy:
rollingUpdate:
maxSurge: 1
maxUnavailable: 1
minReadySeconds: 5
template:
metadata:
labels:
app: dotnetapp
spec:
containers:
- name: dotnetapp
image: johndoe/dotnetapp:1.0
ports:
- containerPort: 80
resources:
requests:
cpu: 250m
limits:
cpu: 500m
env:
- name: DB_ENDPOINT
value: "dotnetappdb"
---
apiVersion: v1
kind: Service
metadata:
name: dotnetapp
spec:
type: LoadBalancer
ports:
- port: 80
selector:
app: dotnetapp

John现在只需运行此命令即可在任何Kubernetes集群中本地或在另一个集群中部署应用程序：

kubectl apply -f .\dotnetapp-deployment.yaml

此命令将创建所需的所有内容，或者仅在有更新时才应用更新。

他可以在这台计算机或任何其他环境（包括生产环境）上运行完全相同的命令，并且它将以相同的方式在任何地方运行。但这不仅仅是那个。Kubernetes会根据您使用的yaml定义不断检查部署状态。因此，如果Docker容器出现故障，Kubernetes将自动启动一个新容器。John不再需要去容器无法再次启动的每个服务器; 协调员会为他照顾。并且会有一些监控股份的东西，以确保它是合规的 - 意味着它一直在按预期运行。

这就是你如何轻松地每天进行几次部署，大约需要五分钟。