《Docker 实战：打造可靠的生产环境容器化应用》第十章：规模化容器化应用程序

数据智能老司机
120 阅读10分钟

容器的一个主要优势是它们能够抽象出底层的硬件和操作系统，使得您的应用程序不受限于任何特定的主机或环境。这有助于横向扩展无状态应用程序，不仅可以在数据中心内部水平扩展，还可以在云提供商之间跨越，而且不会遇到许多传统的障碍。忠于集装箱的隐喻，一个云上的容器看起来与另一个云上的容器相同。

许多组织认为在云上提供的 Linux 容器的即插即用部署很有吸引力，因为他们可以在不完全自建的情况下获得可扩展的基于容器的平台的许多即时好处。尽管如此，构建自己的云平台的门槛实际上相当低，无论是在云上还是在您自己的数据中心中，我们将很快为您介绍一些选项。

主要的公共云提供商都努力在其产品中本地支持 Linux 容器。一些主要的云上支持 Linux 容器的努力包括以下内容：

  • 亚马逊弹性容器服务
  • 谷歌 Cloud Run
  • Azure 容器应用

许多相同的公司还提供了强大的托管 Kubernetes 服务，比如：

  • 亚马逊弹性 Kubernetes 服务
  • 谷歌 Kubernetes 引擎
  • Azure Kubernetes 服务

在公共云中的一个 Linux 实例上安装 Docker 是非常简单的。但在服务器上安装 Docker 通常只是创建完整生产环境的第一步。您可以完全自行完成这个过程，也可以使用主要云提供商、Docker 公司以及更广泛的容器社区提供的许多工具。大部分工具在公共云或您自己的数据中心中同样适用。

在调度程序和更复杂的工具系统领域，我们有许多选择，这些系统可以复制公共云提供商提供的大部分功能。即使在公共云中运行，您可能会选择自己运行 Linux 容器环境，而不是使用现成的提供。

在本章中，我们将介绍一些在大规模运行 Linux 容器的选项，首先简要介绍 Docker Swarm 模式，然后深入探讨一些更高级的工具，如 Kubernetes 以及一些较大的云提供。所有这些示例都应该让您了解如何利用 Docker 为您的应用工作负载提供极其灵活的平台。

Docker 集群模式

在构建了 Docker 引擎这种容器运行时之后，Docker 的工程师们开始着手解决编排一系列独立 Docker 主机和高效地将这些主机充满容器的问题。从这项工作中演化出来的第一个工具被称为 Docker Swarm。正如我们在前面解释过的，有两种被称为“Swarm”的东西，都是由 Docker 公司推出的。

最初的独立 Docker Swarm 现在通常被称为 Docker Swarm（经典版），但是还有第二个名为“Swarm”的实现，更具体地称为 Swarm 模式。这不再是一个独立的产品，而是集成到 Docker 客户端中的。内置的 Swarm 模式比原始的 Docker Swarm 更加强大，并且意在完全取代它。Swarm 模式的主要优势在于无需单独安装任何内容。任何运行 Docker 的系统上都已经具备了这种集群功能！这是我们在这里要重点介绍的 Docker Swarm 实现。希望现在您知道有两个不同的 Docker Swarm 实现后，不会被网络上的相互矛盾的信息搞混。

Docker Swarm 模式的理念是向 Docker 客户端工具呈现一个单一的接口，但该接口由整个集群支持，而不是单个 Docker 守护程序。Swarm 主要用于通过 Docker 工具来管理集群计算资源。它自从首次发布以来已经发展了很多，现在包含了几个调度器插件，使用不同的策略将容器分配给主机，并内置了一些基本的服务发现功能。但它仍然只是一个更复杂解决方案的一个构建块。

Swarm 集群可以包含一个或多个管理节点，这些节点充当 Docker 集群的中央管理中心。最好设置一个奇数个管理节点。一次只有一个管理节点会充当集群领导者。当您向 Swarm 添加更多节点时，您正在将它们合并成一个单一的、有机的集群，可以轻松地使用 Docker 工具进行控制。

让我们开始设置一个 Swarm 集群。首先，您需要三个或更多可以在网络上相互通信的 Linux 服务器。这些服务器中的每一个都应该运行来自官方 Docker 软件仓库的最新版本 Docker 社区版。

在这个示例中，我们将使用三台运行 docker-ce 的 Ubuntu 服务器。您需要做的第一件事情是通过 SSH 连接到您想要用作 Swarm 管理节点的服务器，然后使用您的 Swarm 管理节点的 IP 地址运行 swarm init 命令：

$ ssh 172.17.4.1
…

ubuntu@172.17.4.1:$ sudo docker swarm init --advertise-addr 172.17.4.1

Swarm initialized: current node (hypysglii5syybd2zew6ovuwq) is now a manager.

To add a worker to this swarm, run the following command:

    docker swarm join --token SWMTKN-1-14……a4o55z01zq 172.17.4.1:2377

To add a manager to this swarm, run 'docker swarm join-token manager'
and follow the instructions.

这一步将初始化 Swarm 管理节点并为想要加入集群的节点提供所需的令牌。请将此令牌保存在安全的地方，比如密码管理器中。如果不小心丢失了此令牌，也不必过于担心；您可以在管理节点上运行以下命令获取它：

sudo docker swarm join-token --quiet worker

您可以通过在本地运行的 docker 客户端指向新的管理节点 IP 地址来检查您目前的进展情况：

$ docker -H 172.17.4.1 system info
…
Swarm: active
  NodeID: l9gfcj7xwii5deveu3raf4782
  Is Manager: true
  ClusterID: mvdaf2xsqwjwrb94kgtn2mzsm
  Managers: 1
  Nodes: 1
  Default Address Pool: 10.0.0.0/8
  SubnetSize: 24
  Data Path Port: 4789
  Orchestration:
   Task History Retention Limit: 5
  Raft:
   Snapshot Interval: 10000
   Number of Old Snapshots to Retain: 0
   Heartbeat Tick: 1
   Election Tick: 10
  Dispatcher:
   Heartbeat Period: 5 seconds
  CA Configuration:
   Expiry Duration: 3 months
   Force Rotate: 0
  Autolock Managers: false
  Root Rotation In Progress: false
  Node Address: 172.17.4.1
  Manager Addresses:
   172.17.4.1:2377
…

您还可以使用以下命令列出当前在集群中的所有节点：

$ docker -H 172.17.4.1 node ls

ID      HOSTNAME      STATUS AVAILABILITY MANAGER STATUS ENGINE VERSION
l9…82 * ip-172-17-4-1 Ready  Active       Leader         20.10.7

此时，您可以将另外两台服务器作为工作节点添加到 Swarm 集群中。这是在生产环境中进行扩展的步骤，而 Swarm 可以很轻松地实现这一点：

$ ssh 172.17.4.2 \
    "sudo docker swarm join --token SWMTKN-1-14……a4o55z01zq 172.17.4.1:2377"

This node joined a swarm as a worker.

$ ssh 172.17.4.3 \
    "sudo docker swarm join --token SWMTKN-1-14……a4o55z01zq 172.17.4.1:2377"

This node joined a swarm as a worker.

如果重新运行 docker node ls，您现在应该会看到您的集群中总共有三个节点，其中只有一个被标记为 Leader：

$ docker -H 172.17.4.1 node ls

ID      HOSTNAME      STATUS AVAILABILITY MANAGER STATUS ENGINE VERSION
l9…82 * ip-172-17-4-1 Ready  Active       Leader         20.10.7
3d…7b   ip-172-17-4-2 Ready  Active                      20.10.7
ip…qe   ip-172-17-4-3 Ready  Active                      20.10.7

这就是在 Swarm 模式下启动和运行一个 Swarm 集群所需的全部步骤（见图 10-1）！

image.png

接下来，您应该创建一个供您的服务使用的网络。Swarm 中有一个名为 "ingress" 的默认网络，但是创建额外的网络以实现更好的隔离非常容易：

$ docker -H 172.17.4.1 network create --driver=overlay default-net

ckwh5ph4ksthvx6843ytrl5ik

$ docker -H 172.17.4.1 network ls

NETWORK ID     NAME              DRIVER    SCOPE
494e1a1bf8f3   bridge            bridge    local
xqgshg0nurzu   default-net       overlay   swarm
2e7d2d7aaf0f   docker_gwbridge   bridge    local
df0376841891   host              host      local
n8kjd6oa44fr   ingress           overlay   swarm
b4720ea133d6   none              null      local

到目前为止，我们只是在运行底层组件，迄今为止还没有部署任何实际的业务逻辑。所以让我们将您的第一个服务部署到集群中。您可以使用类似这样的命令来执行：

$ docker -H 172.17.4.1 service create --detach=true --name quantum \
    --replicas 2 --publish published=80,target=8080 --network default-net \
    spkane/quantum-game:latest

tiwtsbf270mh83032kuhwv07c

我们正在启动的服务会启动托管“Quantum”游戏的容器。这是一个基于浏览器的解谜游戏，使用了真正的量子力学。我们希望这个例子比另一个“Hello World！”更有趣。

通过运行docker service ps命令，并提供你创建的服务名称，我们可以查看这些容器最终运行在哪里：

$ docker -H 172.17.4.1 service ps quantum

ID    NAME      IMAGE       NODE          DESIRED… CURRENT… ERROR PORTS
rk…13 quantum.1 spkane/qua… ip-172-17-4-1 Running  Running…
lz…t3 quantum.2 spkane/qua… ip-172-17-4-2 Running  Running…

Swarm模式在节点之间使用路由网格自动路由流量到能够提供请求的容器。当你在docker service create命令中指定了一个发布端口时，网格使得你可以在你的三个节点中的任何一个上访问该端口，并将你路由到Web应用程序。请注意，尽管你只有两个实例在运行，但我们说任意三个节点中的任何一个。传统上，你还需要设置一个单独的反向代理层来实现这一点，但在Swarm模式中，它已经包含在内。

为了证明这一点，你可以尝试通过将Web浏览器指向任何一个节点的IP地址来测试该服务：

http://172.17.4.1/

如果一切正常，你应该能够看到Quantum游戏的第一个拼图板：

To get a list of all the services, we can use +service ls+:
$ docker -H 172.17.4.1 service ls

ID    NAME    MODE       REPLICAS IMAGE                      PORTS
iu…9f quantum replicated 2/2      spkane/quantum-game:latest *:80->8080/tcp

这提供了我们需要的最常用信息的摘要视图，但有时这还不够。Docker维护着许多关于服务的其他元数据，就像它为容器所做的一样。我们可以使用docker service inspect获取有关服务的详细信息：

$ docker -H 172.17.4.1 service inspect --pretty quantum
ID:    iuoh6oxrec9fk67ybwuikutqa
Name:    quantum
Service Mode:  Replicated
 Replicas:  2
Placement:
UpdateConfig:
 Parallelism:  1
 On failure:  pause
 Monitoring Period: 5s
 Max failure ratio: 0
 Update order:      stop-first
RollbackConfig:
 Parallelism:  1
 On failure:  pause
 Monitoring Period: 5s
 Max failure ratio: 0
 Rollback order:    stop-first
ContainerSpec:
 Image:    spkane/quantum-game:latest@sha256:1f57…4a8c
 Init:    false
Resources:
Networks: default-net
Endpoint Mode:  vip
Ports:
  PublishedPort = 80
  Protocol = tcp
  TargetPort = 8080
  PublishMode = ingress

这里有很多信息，所以让我们指出一些较重要的内容。首先，我们可以看到这是一个具有两个副本的复制服务，就像我们在docker service ls命令中看到的一样。我们还可以看到Docker正在以5秒的间隔对服务进行健康检查。运行服务的更新将使用“stop-first”方法，这意味着它首先会将我们的服务降为N-1个，然后启动一个新实例将我们恢复到N个。在生产中，您可能希望始终以N+1模式运行，以便在更新期间从不关掉节点。您可以使用--update-order=start-first选项更改docker service update命令的行为。在回滚情况下，它将表现出相同的行为，同样可以使用--rollback-order=start-first进行更改。

在真实的情况下，我们不仅需要能够启动服务，还需要能够按比例调整。如果我们不得不重新部署来实现这一点，那将是遗憾的，更不用说可能会引入许多额外的问题。幸运的是，Swarm模式使得使用单个命令来调整服务规模变得非常容易。要将实例数从两个增加到四个，您只需运行以下命令：

$ docker -H 172.17.4.1 service scale --detach=false quantum=4

quantum scaled to 4
overall progress: 4 out of 4 tasks
1/4: running   [==================================================>]
2/4: running   [==================================================>]
3/4: running   [==================================================>]
4/4: running   [==================================================>]
verify: Service converged

现在我们可以使用docker service ps来显示Swarm执行了我们的请求。这与我们之前运行的命令相同，但现在我们应该有更多的副本在运行！但是等等，我们不是要求比我们拥有的节点数更多的副本吗？

$ docker -H 172.17.4.1 service ps quantum

ID    NAME      IMAGE        NODE          DESIRED… CURRENT… ERROR PORTS
rk…13 quantum.1 spkane/quan… ip-172-17-4-1 Running  Running…
lz…t3 quantum.2 spkane/quan… ip-172-17-4-2 Running  Running…
mh…g8 quantum.3 spkane/quan… ip-172-17-4-3 Running  Running…
cn…xb quantum.4 spkane/quan… ip-172-17-4-1 Running  Running…

你会注意到同一台主机上有两个服务在运行。你是否期望过这种情况？这可能不利于主机的弹性，但默认情况下，Swarm会优先确保你拥有所请求的实例数，而不是在可能的情况下在主机之间分散单个容器。如果节点不够，你将在每个节点上得到多个副本。在实际场景中，你需要仔细考虑部署和扩展。当你失去整个节点时，在同一主机上运行多个副本可能不是最理想的。在这种情况下，你的应用程序是否仍然能够以降低的规模为用户提供服务？

当你需要部署软件的新版本时，你会想要使用docker service update命令。这个命令有很多选项，这里是一个例子：

$ docker -H 172.17.4.1 service update --update-delay 10s \
    --update-failure-action rollback --update-monitor 5s \
    --update-order start-first --update-parallelism 1 \
    --detach=false \
    --image spkane/quantum-game:latest-plus quantum

quantum
overall progress: 4 out of 4 tasks
1/4: running   [==================================================>]
2/4: running   [==================================================>]
3/4: running   [==================================================>]
4/4: running   [==================================================>]
verify: Service converged

运行此命令将导致Swarm逐个更新你的服务，每次更新之间都会暂停。完成后，你应该能够在新的私有或无痕浏览会话中打开服务的URL（以避免浏览器的本地缓存），并看到游戏的背景现在是绿色而不是蓝色。

太好了，你现在已经成功地应用了一个更新，但如果出现问题怎么办？我们可能需要部署一个之前的版本来恢复正常运行。现在，你可以通过使用service rollback命令回滚到先前的版本，正确的蓝色背景，我们稍早时已经简要讨论过：

$ docker -H 172.17.4.1 service rollback quantum

quantum
rollback: manually requested rollback
overall progress: rolling back update: 4 out of 4 tasks
1/4: running   [>                                                  ]
2/4: running   [>                                                  ]
3/4: running   [>                                                  ]
4/4: running   [>                                                  ]
verify: Service converged

对于一个无状态服务来说，这是一个很好的回滚机制了。你不需要跟踪先前的版本，Docker会为你处理。你只需要告诉它进行回滚，它会从内部存储中提取先前的元数据并执行回滚操作。就像在部署过程中一样，Docker可以对你的容器进行健康检查，以确保回滚工作正常。

在 docker service 命令的基础上，还有一个名为 docker stack 的命令，它使你能够部署一个特殊设计的 docker-compose.yaml 文件到 Docker Swarm mode 或 Kubernetes 集群中。如果你回顾一下我们在第8章中使用的 Git 仓库，我们可以将该容器堆栈的修改版本部署到当前的 Swarm mode 集群中：

$ git clone https://github.com/spkane/rocketchat-hubot-demo.git \
    --config core.autocrlf=input

在该代码库中有一个名为 stack 的目录，其中包含了一个修改过的 docker-compose.yaml 文件，这是之前我们使用过的文件：

$ cd rocketchat-hubot-demo/stack

如果你想在 Swarm 模式集群中启动这个设置，你可以运行以下命令：

$ docker -H 172.17.4.1 stack deploy --compose-file docker-compose-stack.yaml \
    rocketchat

Creating network rocketchat_default
Creating service rocketchat_hubot
Creating service rocketchat_mongo
Creating service rocketchat_rocketchat
Creating service rocketchat_zmachine

现在你可以列出集群中的堆栈，查看堆栈添加了哪些服务：

$ docker -H 172.17.4.1 stack ls

NAME         SERVICES   ORCHESTRATOR
rocketchat   4          Swarm

$ docker -H 172.17.4.1 service ls

ID    NAME         …  …  IMAGE                              PORTS
iu…9f quantum      … 2/2 spkane/quantum-game:latest         *:80->8080/tcp
nh…jd …_hubot      … 1/1 rocketchat/hubot-rocketchat:latest *:3001->8080/tcp
gw…qv …_mongo      … 1/1 spkane/mongo:4.4
m3…vd …_rocketchat … 1/1 rocketchat/rocket.chat:5.0.4       *:3000->3000/tcp
lb…91 …_zmachine   … 1/1 spkane/zmachine-api:latest

此时，您可以将您的网络浏览器指向 Swarm 集群的一个节点的 3000 端口（例如，在这些示例中，http://172.17.4.1:3000/），您应该会看到 Rocket.Chat 的初始设置页面。 您可以使用 docker stack ps 查看由堆栈管理的所有容器：

$ docker -H 172.17.4.1 stack ps -f "desired-state=running" rocketchat

ID    NAME           IMAGE                    NODE … CURRENT STATE           …
b5…1h …_hubot.1      rocketchat/hubot-rocket… …-1  … Running 14 seconds ago
eq…88 …_mongo.1      spkane/mongo:4.4         …-2  … Running 11 minutes ago
5x…8u …_rocketchat.1 rocketchat/rocket.chat:… …-3  … Running 11 minutes ago
r5…x4 …_zmachine.1   spkane/zmachine-api:lat… …-4  … Running 12 minutes ago

当您完成后，可以执行以下操作来撤销堆栈：

$ docker -H 172.17.4.1 stack rm rocketchat

Removing service rocketchat_hubot
Removing service rocketchat_mongo
Removing service rocketchat_rocketchat
Removing service rocketchat_zmachine
Removing network rocketchat_default

那么，如果您的其中一个服务器遇到问题并且您需要将其下线，该怎么办？在这种情况下，您可以使用 docker node update 命令的 --availability 选项轻松地将所有服务从单个节点中移除。 让我们再次查看一下您在集群中拥有的节点：

docker -H 172.17.4.1 node ls

ID      HOSTNAME      STATUS AVAILABILITY MANAGER STATUS ENGINE VERSION
l9…82 * ip-172-17-4-1 Ready  Active       Leader         20.10.7
3d…7b   ip-172-17-4-2 Ready  Active                      20.10.7
ip…qe   ip-172-17-4-3 Ready  Active                      20.10.7

还让我们检查一下我们的容器当前运行在哪里：

$ docker -H 172.17.4.1 service ps -f "desired-state=running" quantum

ID    NAME        IMAGE       NODE          DESIRED… CURRENT… ERROR   PORTS
sc…1h quantum.1   spkane/qua… ip-172-17-4-1 Running  Running…
ax…om quantum.2   spkane/qua… ip-172-17-4-2 Running  Running…
p4…8h quantum.3   spkane/qua… ip-172-17-4-3 Running  Running…
g8…tw quantum.4   spkane/qua… ip-172-17-4-1 Running  Running…

如果你已经确定了位于 172.17.4.3 的服务器需要停机，你可以通过在 Swarm 中将可用状态修改为“drain”来排空该节点的任务并将它们迁移到另一个主机上：

$ docker -H 172.17.4.1 node update --availability drain ip-172-17-4-3

ip-172-17-4-3

如果你已经确定了位于 172.17.4.3 的服务器需要停机，你可以通过在 Swarm 中将可用状态修改为“drain”来排空该节点的任务并将它们迁移到另一个主机上：

$ docker -H 172.17.4.1 node inspect --pretty ip-172-17-4-3
ID:      ipohyw73hvf70td9licnls9qe
Hostname:                ip-172-17-4-3
Joined at:               2022-09-04 16:59:52.922451346 +0000 utc
Status:
 State:      Ready
 Availability:           Drain
 Address:    172.17.4.3
Platform:
 Operating System:  linux
 Architecture:    x86_64
Resources:
 CPUs:      2
 Memory:    7.795GiB
Plugins:
 Log:    awslogs, fluentd, gcplogs, gelf, journald, json-file, local,
         logentries, splunk, syslog
 Network:    bridge, host, ipvlan, macvlan, null, overlay
 Volume:    local
Engine Version:    20.10.7
TLS Info:
 TrustRoot:
…

 Issuer Subject:  …
 Issuer Public Key:  …

你可能想知道这对服务有什么影响。我们告诉其中一个节点停止运行服务的副本，它们要么必须停止运行，要么迁移到其他地方。它是怎么做的呢？我们可以再次查看我们服务的详细信息，看到在那个主机上运行的所有容器已被迁移到了另一个节点：

$ docker -H 172.17.4.1 service ps -f "desired-state=running" quantum

ID    NAME        IMAGE       NODE          DESIRED… CURRENT… ERROR   PORTS
sc…1h quantum.1   spkane/qua… ip-172-17-4-1 Running  Running…
ax…om quantum.2   spkane/qua… ip-172-17-4-2 Running  Running…
p4…8h quantum.3   spkane/qua… ip-172-17-4-2 Running  Running…
g8…tw quantum.4   spkane/qua… ip-172-17-4-1 Running  Running…

此时，您可以安全地关闭该节点，并进行必要的工作以使其恢复正常。当您准备好将该节点重新添加到 Swarm 集群中时，可以执行以下操作：

$ docker -H 172.17.4.1 node update --availability active ip-172-17-4-3

ip-172-17-4-3

我们暂时省略重新检查节点的步骤，但如果您想查看这是什么样子，随时可以重新运行节点检查命令。

完成后，您可以使用以下命令移除您的服务和网络：

$ docker -H 172.17.4.1 service rm quantum

quantum

$ docker -H 172.17.4.1 network rm default-net

default-net

然后验证它们确实已经完全删除：

$ docker -H 172.17.4.1 service ps quantum

no such service: quantum

$ docker -H 172.17.4.1 network ls

NETWORK ID     NAME              DRIVER    SCOPE
494e1a1bf8f3   bridge            bridge    local
2e7d2d7aaf0f   docker_gwbridge   bridge    local
df0376841891   host              host      local
n8kjd6oa44fr   ingress           overlay   swarm
b4720ea133d6   none              null      local

这就是全部内容了！现在，如果你不再需要它们，可以安全地关闭所有属于你的Swarm集群的服务器。 这可能是一个快速的介绍，但它涵盖了在Docker引擎中使用Swarm模式的基础知识，应该能帮助你开始构建自己的Docker集群，不管你决定在哪里使用它们。

Kubernetes

现在让我们花点时间来了解一下Kubernetes。自从在2014年的DockerCon上向公众发布以来，Kubernetes迅速发展，现在可能是最广泛采用的容器平台之一。尽管它不是最古老或最成熟的产品，这个荣誉应该归功于Mesos，它在2009年首次推出，当时容器还没有被广泛使用。但是Kubernetes是专为容器化工作负载而构建的，具有丰富的功能组合，不断发展，并且拥有一个非常强大的社区，其中包括许多早期的Docker和Linux容器采用者。这种组合在多年来显著增加了它的受欢迎程度。在2017年的DockerCon EU上，Docker，Inc.宣布将在Docker Engine工具中添加对Kubernetes的支持。Docker Desktop能够启动单节点的Kubernetes集群，而客户端可以部署用于开发目的的容器堆栈。这为那些在本地使用Docker但部署到Kubernetes的开发人员提供了一个很好的桥梁。

与Linux本身类似，Kubernetes有几种发行版本，包括免费和商业版本。有各种各样的发行版本可供选择，并在不同程度上得到支持。Kubernetes的广泛采用意味着它现在有一些非常好的本地开发安装工具。

Minikube

Minikube是最早用于管理本地Kubernetes安装的工具之一，也是我们在这里要重点介绍的第一个工具。在使用Minikube时学到的大多数概念都可以应用于任何Kubernetes实现，包括我们在Minikube之后要讨论的选项，因此它是一个很好的起点。

什么是Minikube？

Minikube是一个完整的Kubernetes分发版本，适用于单个实例。它在您的计算机上管理一个容器或虚拟机，提供一个完整的Kubernetes安装，并允许您使用与生产系统中相同的工具。在范围上，它有点类似于Docker Compose：它可以让您在本地快速创建一个完整的堆栈。但与Compose不同，Minikube具备所有生产API。因此，如果您在生产环境中运行Kubernetes，您可以在您的桌面上拥有一个在功能上（尽管规模上不一定）与您在生产环境中运行的环境相当接近的环境。

Minikube在一个独立的二进制文件中控制所有的分发，您只需下载并在本地运行它。它会自动检测您本地使用的容器化或虚拟机管理器，并设置并运行一个包含所有必要的Kubernetes服务的容器或虚拟机。这意味着开始使用它非常简单。 那么，让我们来安装它吧！

安装Minikube

大部分安装步骤在所有平台上都是相同的，因为一旦您安装了这些工具，它们将是连接到运行Kubernetes安装的虚拟机的通道。要开始使用，请直接跳到适用于您操作系统的部分。一旦您将工具安装好并运行起来，您就可以按照共享的文档进行操作。

为了有效使用Minikube，我们需要两个工具：minikube和kubectl。对于我们的简单安装，我们将充分利用这两个命令是没有外部依赖的静态二进制文件的特点，这使得它们很容易安装。

macOS

就像在第三章一样，您需要在您的系统上安装Homebrew。如果没有安装，请返回第三章并确保您已经设置好了。一旦您安装了Homebrew，安装minikube客户端非常简单：

$ brew install minikube

这将导致Homebrew下载并安装Minikube。根据您的配置，它可能会看起来像这样：

==> Downloading https://ghcr.io/v2/homebrew/core/kubernetes-cli/…/1.25.0
Already downloaded: …/Homebrew/downloads/…kubernetes-cli…manifest.json
==> Downloading https://ghcr.io/v2/homebrew/core/kubernetes-cli/blobs/sha256…
Already downloaded: …/Homebrew/downloads/…kubernetes-cli--1.25…bottle.tar.gz
==> Downloading https://ghcr.io/v2/homebrew/core/minikube/manifests/1.26.1
Already downloaded: …/Homebrew/downloads/…minikube-1.26.1.…_manifest.json
==> Downloading https://ghcr.io/v2/homebrew/core/minikube/blobs/sha256:…
Already downloaded: …/Homebrew/downloads/…minikube--1.26.1…bottle.tar.gz
==> Installing dependencies for minikube: kubernetes-cli
==> Installing minikube dependency: kubernetes-cli
==> Pouring kubernetes-cli--1.25.0.arm64_monterey.bottle.tar.gz
  /opt/homebrew/Cellar/kubernetes-cli/1.25.0: 228 files, 52.8MB
==> Installing minikube
==> Pouring minikube--1.26.1.arm64_monterey.bottle.tar.gz
==> Caveats
Bash completion has been installed to:
  /opt/homebrew/etc/bash_completion.d
==> Summary
  /opt/homebrew/Cellar/minikube/1.26.1: 9 files, 70.6MB
==> Running `brew cleanup minikube`…
Disable this behavior by setting HOMEBREW_NO_INSTALL_CLEANUP.
Hide these hints with HOMEBREW_NO_ENV_HINTS (see `man brew`).
==> Caveats
==> minikube
Bash completion has been installed to:
  /opt/homebrew/etc/bash_completion.d

就是这样！让我们来测试一下，确保它已经在您的路径中：

$ which minikube
/opt/homebrew/bin/minikube

如果您没有收到响应，您需要确保将 /usr/local/bin 和 /opt/homebrew/bin 添加到 PATH 环境变量中。假设这一步通过了，那么您现在已经安装了 minikube 工具。

kubectl 应该已经自动安装，因为它是 minikube 的依赖项，但您也可以使用 brew 显式地安装它。通常情况下，Homebrew 中的 kubectl 版本会与当前 minikube 的版本相匹配，因此使用 brew install 应该有助于防止版本不匹配：

$ brew install kubernetes-cli

我们将以与测试 minikube 相同的方式测试 kubectl：

$ which kubectl
/opt/homebrew/bin/kubectl

准备就绪！

Windows

与在Windows上安装Docker Desktop一样，您可能希望安装Hyper-V或其他支持的虚拟化平台来运行Kubernetes虚拟机。要安装minikube，您只需从GitHub下载二进制文件并将其放在您的PATH所在的位置，以便您可以在命令行上执行它。您可以从GitHub上下载最新版本的minikube。您需要将下载的Windows可执行文件重命名为minikube.exe；否则，您可能会输入比您想要的更多的命令！

然后，您需要获取最新的Kubernetes CLI工具，即kubectl，以与您的发行版进行交互。不幸的是，没有一个/latest路径用于下载它。因此，为了确保您有最新版本，您需要从网站上获取最新版本，然后将其插入到URL中，例如： storage.googleapis.com/kubernetes-…/bin/windows/amd64/kubectl.exe。 下载完成后，您需要确保它可以从PATH访问，以便更轻松地进行后续的探索。

Linux

在Linux上，您应该已经安装了Docker，并且考虑安装KVM（Linux的基于内核的虚拟机）或VirtualBox，以便minikube可以为您创建和管理一个Kubernetes虚拟机。因为minikube只是一个单独的二进制文件，一旦您安装好它，就不需要安装任何额外的软件包。并且，因为minikube是一个静态链接的二进制文件，所以它几乎可以在任何您想要运行它的发行版上工作。虽然我们可以通过一条命令来完成所有安装步骤，但为了更容易理解和排除故障，我们将分成几个步骤进行。请注意，此时此刻，该二进制文件托管在googleapis上，通常会维护非常稳定的URL。因此，我们开始吧：

# Download the file, save as 'minikube'
$ curl -Lo minikube \
  https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64

# Make it executable
$ chmod +x minikube

# Move it to /usr/local/bin
$ sudo mv minikube /usr/local/bin/
avatar
文章
阅读
粉丝