一、Docker 容器内部
欢迎来到【Azure Kubernetes 服务简介:容器编排实用指南。在进入 Azure Kubernetes 服务之前，了解通向 Kubernetes 和最终 Azure Kubernetes 服务的构件和道路是很重要的。
这一章并没有深入探讨 Docker 和用 Docker 构建应用。Docker 是一个很大的主题，可以写满一整本书。本章的目的是给那些不熟悉 Docker 的人足够的入门知识，也给那些熟悉 Docker 的人一个复习的机会，这是 Kubernetes 必备的知识。
在第一章中，我们将深入 Docker 容器。到本章结束时，你会对 Docker 有更深的了解；映像；容器及其价值；底层 Docker 组件；如何安装 Docker，运行 Docker 命令，构建 Docker 镜像；和 Docker Compose，最后介绍编排平台。
容器的价值
容器化并不新鲜。事实上，自 20 世纪 80 年代以来，容器技术已经出现在 Linux 世界中。然而，部分由于 2013 年 Docker 容器格式的推出，容器才随着巨大的增长而变得广泛流行。
容器是隔离的用户空间实例中应用层的抽象。容器共享运行它们的主机上的操作系统(OS)内核存储和网络。容器可以被认为是作为一个进程运行的应用所需要的核心组件。容器允许打包应用及其在实例中运行的依赖项。容器允许软件工程师开发他们的应用，并以一致的方式跨环境(如开发、试运行和生产)进行复制。容器可以通过持续集成和持续部署流水线，以保持操作系统、依赖性和应用不变的方式移动，从而提供最终的灵活性和敏捷性。
从技术角度来看，容器的价值可以归结为以下几点:在相同硬件上的应用密度比任何其他技术都大，对开发人员的优化提高了开发人员的工作效率和流水线，操作简单，以及与云和基础设施无关，实现了真正的平台独立性和最终的可移植性。
容器对企业的价值在于降低总拥有成本、加快上市速度、提高客户满意度、可预测性和可靠性、增加灵活性以及提高运营速度。
什么是 Docker
有许多可用的容器格式；然而，Docker 已经成为 Windows 和 Linux 容器事实上的标准。Docker 是一种开源的容器格式。Docker 可以用来构建、运行和存储容器映像和容器。根据 Docker，350 多万个应用已被容器化。根据 RightScale 2018 年云状况报告，2018 年 Docker 的采用率从 35%上升到 49%。让我们深入了解 Docker 组件:
-
Docker 引擎是 Docker 解决方案的核心。它是一个客户端-服务器应用，具有以下组件:
-
Docker 客户端是用户与 Docker 交互的方式。Docker 客户端自带命令行界面(CLI)，用户可以在其中执行 Docker 命令。Docker 客户端可以与 Docker 守护程序或客户端计算机运行在同一台计算机上，并远程连接到 Docker 守护程序。
-
Docker 主机运行 Docker 守护进程。Docker 守护进程是管理 Docker 映像、容器、网络和存储卷的后台进程。守护进程监听 REST API 上的命令或通过 CLI 接收命令。它还可以与其他 Docker 守护进程通信，以管理 Docker 服务。
-
Docker registry 是一个存储库服务，您可以在其中托管和下载容器映像。Docker 注册表可以是本地的、公共的或私有的。Docker 有一个名为 Docker Hub 的公共注册服务。大多数云提供商都提供私有 Docker 注册表。
-
-
Docker 对象
-
Docker 映像是用于构建 Docker 容器的只读模板。其中包含创建 Docker 容器的说明。映像包括应用代码、运行时、系统库、系统工具和设置。
-
Docker 容器就是运行时运行的映像。Docker 容器运行在 Docker 引擎上。
-
Docker 服务允许容器跨多个 Docker 守护进程伸缩。这些多个守护进程与多个管理器和工作器一起作为一个群体。
-
Docker 有两个版本:
-
社区版(CE)
- 对于开发人员、小型团队和任何从容器开始的人来说，CE 是一个很好的选择。
-
企业版(EE)
- EE 适合企业团队和生产需求。
要知道 Kubernetes 支持多容器运行时是很重要的；然而，总体 Docker 是当今技术领域最常见的映像和容器格式。花些时间深入学习 Docker 是值得的。
容器与虚拟机
在 IT 领域，当需要建立一台服务器来运行应用时，虚拟机(VM)几乎成了标准。虚拟机需要虚拟机管理程序才能运行。有许多虚拟机管理程序，但最受欢迎的是 VMWare 和 Hyper-V。虚拟机管理程序安装在物理机之上，然后虚拟机部署在虚拟机管理程序之上。这使得 IT 行业可以在物理服务器上打包许多虚拟机，从而提高密度并从物理硬件中获得更多投资回报。虚拟机模拟物理服务器，包括存储、网络和操作系统。它们比物理服务器更便携、更快，但仍然是完整的服务器，需要启动时间和与物理服务器相同的管理级别。
容器将密度和优化提升到了一个新的高度。容器仍然是虚拟化的一种形式，但只是虚拟化了运行应用的核心。有了容器，就不需要管理程序了，因为它们直接在内核上运行。您可以在一台物理服务器上打包更多的容器。容器更加轻量级，启动速度更快，管理也更加简化。
对于容器，一些底层组件在运行于主机上的所有容器之间共享，例如存储和网络。图 1-1 给出了容器和虚拟机之间架构差异的可视化表示。
图 1-1
容器与虚拟机
从图中可以看出，容器是在操作系统级别的过程中被隔离的，而虚拟机是在硬件抽象层被隔离的。容器的增长并不意味着虚拟机将很快消失。由于好处，你有理由使用容器而不是虚拟机。让我们看看使用容器的一些原因:
-
速度 : Docker 容器与虚拟机相比速度极快。启动一个容器可能需要几毫秒到几秒钟的时间，而启动一个虚拟机至少需要几分钟。
-
可移植性:容器可以在多个团队、开发流水线、云和基础设施之间移动和共享，无论容器在哪里运行，应用的行为都是一样的。这减少了人为错误和潜在的环境依赖性错误。
-
微服务:容器是分离和运行应用组件以支持基于微服务的架构的好方法。
-
现在让我们来看看您可能仍然希望使用虚拟机而不是容器的一些原因。
-
有状态的:如果你有需要状态的应用，虚拟机可能是更好的选择，因为容器是为运行无状态应用而设计的。
-
协同定位:如果一个应用组件必须全部安装在同一台服务器上，虚拟机将是一个更好的选择，因为容器的焦点通常是将一个应用的服务分散到多个容器中。
随着容器的增加，虚拟机的占用空间将会减少。然而，虚拟机不会消失，因为仍然有它们的使用案例，并且今天许多工作负载在虚拟机上运行得很好。
映像和容器
在这一章的前面，容器映像和容器之间的区别已经被简要地讨论过了。让我们更深入地了解什么是映像和容器。简而言之，容器就是一个映像的运行实例。
映像是只读的。可以通过更改来修改容器，但是当容器停止时，这些更改会丢失。如果将容器的更改提交给新映像，则可以保留这些更改。映像是代码、运行时、文件系统、库和设置的表示。映像是一个名为 Dockerfile 的文件中的一组命令，它定义了容器内部的环境。清单 1-1 是一个简单的映像 Dockerfile 文件的例子，它运行在 Ubuntu Linux 操作系统上，并执行一个命令来输出 Hello World！。
FROM ubuntu:latest
CMD echo Hello World!
Listing 1-1Dockerfile content
构建 docker 文件后，docker build 命令用于构建实际的映像。默认情况下，构建的 docker 映像存储在本地，可以从本地作为容器运行，也可以推送到 Docker 注册表。默认情况下，Docker 映像会获得一个唯一的 ID，但是可以对其进行命名和标记。这就结束了 Docker 映像和容器的总结。在本章的后面，我们将使用 docker 构建和运行一个容器来更详细地研究 docker 文件。
Docker 组件(网络和存储)
建立关系网
在您的容器之旅中，您将到达需要向外部世界公开它的地方，或者您可能需要将同一主机上或跨其他主机的几个容器连接在一起。Docker 容器有适合所有场景的网络选项。容器技术中有一个网络层，用于容器与其他容器、主机和外部世界进行通信。Docker 支持几种不同类型的网络。让我们看看每种类型的网络，以便更好地理解网络在容器中是如何工作的:
-
网桥是容器的默认网络。当 Docker 启动时，会创建一个桥接网络，除非另外指定，否则容器会连接到这个网络。对于这种网络类型，外部世界访问容器需要端口映射。这种网络类型适用于在同一 Docker 守护进程主机上运行的容器。如果容器需要与运行在其他守护程序主机上的容器通信，则需要在操作系统级别进行路由，或者应该使用覆盖网络类型。
-
主机直接使用主机的网络。将使用主机的 IP 地址访问容器。这种网络类型仅适用于 Linux 主机。Docker 桌面不支持此功能。这种网络类型也用于 swarm。
-
Overlay 也称为 ingress，它将 Docker 守护程序连接在一起，用于多主机网络通信。覆盖类型在物理网络之上运行几层网络抽象。覆盖网络是托管在多个 Docker 主机上的容器中的单个第 2 层广播域。
-
Macvlan 允许您将 MAC 地址直接分配给容器。当使用 Macvlan 时，容器看起来就像在网络上一样。当使用这种方法时，可以为容器分配一个可从外部访问的公共 IP 地址。这种类型的网络将容器连接到主机网络接口。这种类型使用第 2 层分段，不需要网络地址转换(NAT)或端口映射。
仓库
容器可以存储对它们所做的更改。任何容器更改都将保存到可写层。此可写层需要存储驱动程序来存储这些更改。默认情况下，容器有非持久存储。非持久性意味着当容器重启时，存储被销毁。为了在容器重启或关闭时无限期保留数据，需要持久存储。使用 Docker 容器，我们有四个持久存储选项。持久存储选项包括
-
数据卷位于容器外部的主机文件系统上。这些允许您创建持久存储和管理卷，例如列出它们、列出它们关联的容器以及重命名它们。
-
数据卷容器是指一个容器专用于托管其他容器的卷。您可以将该容器中的卷装入其他容器中。例如，您可能有一个承载应用的应用容器和一个承载应用容器的卷的卷容器。
-
目录装载是指将主机的本地目录装载到容器中。
-
存储插件与底层存储设备一起工作，并且可以连接到外部存储解决方案。这可以映射到外部存储解决方案，包括云提供商 Azure、AWS 和 GCP；存储阵列，如 EMC、HPE 3PAR 和 NetApp 和存储设备。
安装 Docker
当您开始使用 Docker 时，您需要在本地机器上安装 Docker Desktop。Docker 桌面通常用于本地开发目的。Docker 桌面包括 Docker 引擎、Docker 客户端、Docker 合成、Docker 机器和 Kitematic。Kitematic 是我们还没有讨论过的东西。Kitematic 是一个用于 Docker 映像和容器的 GUI。Kitematic 还自动完成 Docker 的安装和设置过程。
Docker 是跨平台的，因此它可以安装在 Linux、Mac 或 Windows 上。在这一节中，我们将介绍在 Windows 上安装 Docker 的步骤。让我们直接进入在 Windows 上安装 Docker 的步骤。
要求:
-
集群和节点管理
-
Windows 10，64 位:专业版、企业版或教育版(内部版本 15063 或更高版本)
-
在 BIOS 中启用虚拟化
-
支持 CPU SLAT 的功能
-
微软超级 V
-
至少 4 GB 内存
安装步骤:
-
下载坞站桌面安装程序. exe 来自
https://download.docker.com/win/stable/Docker%20for%20Windows%20Installer.exe。 -
双击 Docker 桌面 Installer.exe运行安装程序。
-
将弹出一个向导。按照向导中的步骤操作，包括接受许可证、授权安装程序并继续安装。
-
单击“完成”以完成 Docker 桌面安装。
-
Docker 不会自动启动。需要启动 Docker。为此，请使用 Windows search 搜索 Docker。单击 Docker 桌面 Windows 版。
注意
如果 Hyper-V 没有启用，Docker 桌面安装程序将自动启用它，并在需要时重新启动计算机。
您可以设置 Docker Desktop 在登录 Windows 时自动启动，如图 1-2 所示。
图 1-2
登录时启动 Docker 桌面设置
安装 Docker 后，您应该在任务栏中看到 Docker 图标，以反映 Docker 已安装并正在运行。让我们在接下来的部分中更深入地利用 Docker。
Docker 命令备忘单
与 Docker 的交互是通过命令行完成的。Docker 是用 Go 写的。Docker 将其配置文件存储在一个名为. docker 的目录中，让我们来分解一下 docker 命令结构。所有 docker 命令都是以docker开头，然后有一个空格然后是命令，另一个空格，然后是管理类别或者选项。docker 管理命令语法如图 1-3 所示。
图 1-3
Docker 管理指挥结构
直接引用容器的 Docker 命令略有不同。命令以docker,开始，然后有一个空格，然后是命令，另一个空格，然后是容器名。参考特定容器的 docker 命令语法可以在图 1-4 中看到。
图 1-4
Docker 命令结构
以下是您在开始使用 Docker 时应该知道的关键 Docker CLI 命令列表:
-
docker 信息:这将显示 Docker 的系统范围信息。
-
docker 版本:这将列出您当前的 Docker 版本。
-
docker [COMMAND] help:这将列出一个命令的帮助信息。
-
docker images:这将列出本地系统上的映像。
-
docker run:这将创建并运行一个基于映像的容器。
-
docker start:这将启动一个现有的容器。
-
停靠站:这将停止一个正在运行的容器。
-
docker build:用于从 docker 文件构建映像。
-
docker 登录:这将使你登录到 Docker 注册表。
-
docker 注销:这将使你从 Docker 注册表中注销。
-
docker pull:这将从容器注册表中提取一个映像。
-
docker ps:这将列出正在运行的容器。
-
docker inspect:这将显示一个容器的所有信息，包括 IP 地址。
-
docker rm:这将删除一个映像。
-
docker 日志:这将打印 docker 日志。
了解 Dockerfile 文件
Dockerfile 由一组用于构建映像的指令组成。Dockerfile 应命名为“Dockerfile ”,不带扩展名。从 docker 文件构建映像时，需要包含在映像中的所有文件都应该与 docker 文件位于同一个文件夹中。以下是 Dockerfile 文件的一个示例:
FROM python:alpine3.7
COPY . /app
WORKDIR /app
RUN pip install -r requirements.txt
EXPOSE 5000
CMD python ./index.py
让我们分解示例 Dockerfile 中的命令，以便更好地理解 Dockerfile 结构
-
FROM :定义用于容器的基本映像。
-
COPY :将文件从源文件复制到容器中。
-
WORKDIR :设置执行 CMD 定义的命令的路径。
-
RUN :这定义了一组在容器首次创建时运行的命令。
-
EXPOSE :这将向外界公开一个端口，以支持对容器的网络访问。
-
CMD :运行时会在容器内执行一个特定的命令。
docker build 命令被用作从 docker 文件自动构建映像的一种方式。在下一节中，我们将进一步了解 docker 构建。
了解 Docker 版本
如前所述，docker build 是运行从 docker 文件创建映像的过程的命令。这应该在包含 Dockerfile 文件的同一个目录中运行。以下是 docker 构建语法的一个示例:
docker build --tag pythonapp:dev
标签和:dev 将使用名称和 dev 来标记映像。这使得识别映像更加容易。标签是记录容器映像的变体和/或版本信息的一种方式。可以把标签想象成给容器映像添加一个别名。在映像构建过程运行之后，您可以运行docker images来列出映像并验证您的名称映像是否已创建。
了解复合坞站
Dockerfile 是单个映像。您可以使用 Dockerfile 创建单个映像来运行单个容器。如果您需要创建一个多容器应用，其中的容器相互连接，那么您可以使用一个名为 Docker Compose 的工具。我们不会深入讨论 Docker Compose，因为这是一个高级主题，不在本章讨论范围之内。然而，我们将给出 Docker 编写的概述。
Docker 编写文件在 YAML。在 Docker 合成文件中，您引用映像；因此，您仍然需要在 Dockerfiles 中构建容器映像。使用 Docker Compose，您可以运行一个命令来一次性启动组成您的应用的所有容器。下面是 docker-compose.yml 文件中的一个基于多容器的 WordPress 应用的例子，它由一个 WordPress 站点和一个后端 MySQL 数据库服务器组成:
version: '1.0'
services:
db:
image: mysql:latest
volumes:
- db_data:/var/lib/mysql
restart: always
environment:
MYSQL_ROOT_PASSWORD: secret3241
MYSQL_DATABASE: wp
MYSQL_USER: wpadmin
MYSQL_PASSWORD: secret3241
wordpress:
depends_on:
- db
image: wordpress:latest
ports:
- "8000:80"
restart: always
environment:
WORDPRESS_DB_HOST: db:3306
WORDPRESS_DB_USER: wpadmin
WORDPRESS_DB_PASSWORD: secret3241
WORDPRESS_DB_NAME: wp
volumes:
db_data: {}
Docker Compose 基本上分以下三个步骤工作:
-
用 Dockerfiles 定义所需的容器映像。
-
在 docker-compose.yml 文件中定义组成多容器应用的服务。
-
在包含 docker-compose.yml 文件的目录中运行 docker-compose up 命令，以启动并运行多容器应用。
运行容器
您已经学习了如何创建容器映像。您学习了 docker 文件，然后学习了如何使用 docker build 创建映像以及如何列出映像。下一步是从映像创建并运行容器。您可以运行以下语法来创建和构建容器:
docker run pythonapp:dev
第一次创建容器后，不能使用 docker stop pythonapp:dev和docker start pythonapp:dev停止和启动容器。
编排平台
通过这一章，到目前为止，你已经学习了所有关于容器、Docker 和容器化的许多方面。在开发软件时，构建容器映像和运行容器是相当简单的。在生产、企业就绪和大规模环境中运行数百甚至数千个容器化的应用，需要一套不同的工具和技能，目前尚未讨论。当您需要在生产中运行容器时，容器编排平台就进入了画面。容器编排就是管理容器的生命周期。生产容器环境是动态的，需要高度自动化。容器业务流程句柄
-
集群和节点管理
-
容器供应和部署
-
容器配置和调度
-
容器可用性和冗余
-
集群节点和容器的自动扩展
-
容器负载均衡、流量路由、外部访问和服务发现
-
容器的资源管理和移动
-
容器和主机运行状况和性能监控
-
容器安全和出入管理
编排系统需要覆盖很多领域来处理容器的生命周期管理。市场上有许多容器编排平台。顶级容器编排平台是 Docker Swarm、Docker Enterprise、Mesosphere、OpenShift 和 Kubernetes。Kubernetes 是 Google 开发的一个开源编排平台。Kubernetes 已经迅速成为容器编排事实上的标准。三大云提供商微软、亚马逊和谷歌都在其云平台上提供托管 Kubernetes 服务。在本书的其余部分，我们将深入探讨 Kubernetes，特别是 Azure Kubernetes 服务。
注意
Docker Compose 通常被称为编排工具；然而，同样重要的是要注意，与运行许多节点的编排平台相比，Docker Compose 是针对专用的单个节点的。
摘要
这使我们结束了第一章。在这一章中，我们进入了 Docker 容器的世界，因为这些信息是进入 Kubernetes 和最终的 Azure Kubernetes 服务的基础。在第一章中，我们特别介绍了容器的价值，容器与虚拟机的比较，所有关于 Docker 本身的内容，包括如何安装它，Docker 所需的核心命令，以及所有关于创建和运行容器映像的内容。最后，在本章中，我们略微谈到了容器编排平台。
二、容器注册表
Kubernetes 用于部署基于容器的应用和服务。在许多方面，基于容器的应用推动了对像 Kubernetes 这样的容器编排技术的需求。如前一章所述，容器是从一个名为映像的只读副本实例化的。映像通常存储在一个称为容器注册表的结构中。
在本章中，我们将讨论映像存储、管理和分发的各种选项。我们将研究不同类型的容器注册中心，特别是 Azure 容器注册中心(ACR)。本章结束时，你将能够对容器注册表执行基本操作，并理解映像标记、安全性和权限等概念。
注意
为了简单起见，我们将把重点放在使用开放容器倡议(OCI)映像规范和容器运行时的映像上。还有其他容器映像格式(ACI)和容器运行时(rkt)，但基本概念保持不变。
容器登记概述
当您将应用部署到 Kubernetes 集群时，该应用将由一个或多个容器组成。Kubernetes 需要能够访问这些映像，以便在 Kubernetes 集群中的每个节点上实例化这些容器。您可以在工作站上创建一个映像，并手动将其复制到每个节点，然后在每次更新映像时重复该过程。但是这将会非常低效，容易出错，并且不可扩展。一个更好的解决方案是共享一个位置，所有节点都可以从该位置访问映像并将其下载到本地映像缓存中。这是容器注册背后的基本原则。
注册表、存储库和映像
在我们深入研究容器注册中心之前，理解注册中心、存储库和映像之间的区别是很有用的。正如我们在第一章“Docker 容器内部”中提到的，容器映像是一个只读的构造，容器就是从这个构造实例化的。每个映像都有一个名称和与之关联的可选标签。让我们看看清单 2-1 中所示的从 Docker Hub 中提取映像的例子。
REPOSITORY TAG IMAGE ID
Nginx latest 53f3fd8007f7
Listing 2-1Image listing of nginx container image
映像来自于nginx存储库。它已经被标记为latest。并且它有一个唯一的映像 ID。nginx 存储库中存储了其他映像，包括一个标记为 alpine 的映像和另一个标记为 perl 的映像。在提取这两个映像之后，docker image ls的更新输出如清单 2-2 所示。
REPOSITORY TAG IMAGE ID
nginx alpine dd025cdfe837
nginx perl 4d95835f5c94
nginx latest 53f3fd8007f7
Listing 2-2Image listing of nginx container images
每个映像都来自同一个存储库，但是它们都有不同的标签和映像 id。它们是独一无二的映像。我们将在本章的后面深入探讨标签以及它与映像的关系。
总之，容器存储库包含一个或多个映像。容器注册中心包含一个或多个存储库。特定存储库中的映像可能彼此相关，也可能不相关。
私有和公共注册和存储库
当选择容器注册中心来存放映像时，第一个问题通常是创建私有还是公共注册中心。一个公共注册中心托管在互联网上，任何人都可以访问。它可能包含注册管理机构内公共和私有存储库的混合。一个私有注册中心托管在一个内部网络上，并且只对内部网络上的系统和用户开放。私有注册中心中的存储库也可以包含公共和私有存储库的混合，但是在这种情况下，公共存储库的范围必然受到更多的限制，因为它只对内部网络上的资源可用。虽然大多数公共注册管理机构是作为托管服务运行的，但私有注册管理机构通常由托管注册管理机构的内部 IT 团队管理。
任何能够访问注册中心网络位置的人都可以访问公共存储库中的映像。这并不意味着任何人都可以从存储库中添加、更新或删除映像，但是他们可以下载映像而无需任何类型的身份验证。私有存储库中的映像要求任何希望访问该存储库的人都要经过身份验证，并被授予下载映像的相关权限。
公共注册和存储库最常用于发布开源项目和软件，这些项目和软件是为了与全世界共享。例如，Docker Hub 上的微软存储库是公开的，用于发布像微软/点网和微软/powershell 这样的应用的基本映像。很明显，微软希望你能下载这些图片，并用它们来建造一些令人惊奇的东西。
一些常见的公共注册表有
-
坞站集线器
-
谷歌容器注册
-
Azure 容器注册表
-
亚马逊弹性容器注册中心
当映像需要保存在公司或组织内部，并且对这些映像的访问应该受到控制时，可以使用私有注册表和私有存储库。此外，私有注册管理机构通常托管在内部网络上，无法通过更广泛的互联网进行访问。您的映像可能安装了被视为重要知识产权的专有软件。例如，假设您的公司正在开发基因组学软件，并使用容器进行部署。这些映像将包含非常有价值的算法，不应该提供给竞争对手。因此，您可以选择将您的映像保存在私有存储库中，也可能保存在私有注册表中。
一些常见的私有注册中心有
-
可信注册表坞站
-
JFrog Artifactory
-
海港
-
GitLab
基本注册表操作
所有容器注册中心都支持相同的基本操作。这些操作包括
-
登录注册表以与映像存储库交互
-
在映像库中搜索特定映像
-
将映像下载到本地文件系统
-
将映像推送到注册中心托管的映像存储库
在下面的例子中，我们将展示针对 Docker Hub 执行的操作。您可以免费创建一个 Docker Hub 帐户，并按照示例进行操作。
注册
使用 Docker CLI 可以登录到容器注册中心。以下命令将启动登录过程。
docker login [SERVER]
SERVER值可以引用您想要登录的任何注册表。该命令还接受提供一个username和password。如果没有指定SERVER值，Docker CLI 将认为您正在登录 Docker Hub。清单 2-3 展示了一个使用账户 iaks 登录 Docker Hub 的例子。
$ docker login
Login with your Docker ID to push and pull images from Docker Hub. If you don’t have a Docker ID, head over to https://hub.docker.com to create one.
Username: iaks
Password: ************
Login Succeeded
Listing 2-3Logging into Docker Hub
搜索
Docker Hub registry 有超过 100，000 个容器映像可供公众使用。显然，私人注册中心的映像要少得多，但是需要能够搜索可用的映像来找到满足您需求的映像。docker search命令提供了这一功能。该命令的语法是
docker search [OPTIONS] TERM
假设我们正在寻找一个 nginx 映像来运行和托管一个 web 服务器。这样做的搜索命令如清单 2-4 所示。
$ docker search nginx
NAME DESCRIPTION STARS OFFICIAL
nginx Official build of Nginx. 11498 [OK]
.
.
[output truncated]
Listing 2-4Searching Docker Hub for nginx images
默认情况下，Docker CLI 将在 Docker Hub 注册表中搜索映像。可以通过在搜索中包含地址来搜索其他注册中心TERM。在执行搜索命令之前，您需要通过您试图搜索的注册表的身份验证。
拉
从容器注册表中提取映像是将托管映像下载到本地文件存储库的行为。Docker 守护程序使用的存储驱动器决定了文件的存储位置。当提取映像时，Docker 首先检查映像中包含的层，以确定是否已经下载了任何层。任何尚未在本地缓存的图层都将从源资料档案库中下载。清单 2-5 显示了一个在本地文件系统中已经存在一个图层的情况下提取高山/地形地貌映像的例子。
$ docker pull alpine/terragrunt
Using default tag: latest
latest: Pulling from alpine/terragrunt
e7c96db7181b: Already exists
622c94c90cb1: Pull complete
[output truncated]
68ced3bc2ce4: Pull complete
Digest: sha256:4363c7ea68ae6b648d803753884afed380f106eb23e902641ae919b7b02fe95a
Status: Downloaded newer image for alpine/terragrunt:latest
docker.io/alpine/terragrunt:latest
Listing 2-5Pulling the alpine/terragrunt image from Docker Hub
在公共注册的情况下，任何人都可以提取映像，无论他们是否经过身份验证。对于私有注册中心，用户必须首先经过身份验证，并且拥有获取给定映像的权限。
可以通过发出 docker pull 命令来提取映像。语法如下:
docker pull [OPTIONS] NAME[:TAG | @DIGEST]
名称是指映像的名称。Docker 将假设源存储库在 Docker Hub 上，除非它已经被另外配置，或者名称包括不同的注册中心。例如，可以通过运行以下命令从微软的公共容器注册表中提取映像
docker pull mcr.microsoft.com/azuredocs/aci-helloworld
如果没有指定TAG，那么 docker 将获取存储库中标记为最新的映像。最新的标签没有什么特别的，这并不意味着提取的映像实际上将是最新的或最新的映像。一般来说，最好指定一个标签和要提取的映像的名称。
推
推送是获取本地映像并将其复制到目标存储库的行为。存储库可以位于公共或私有注册中心。在任何一种情况下，这两种类型的注册中心在允许复制映像之前都需要身份验证和适当的授权。
可以使用docker build命令从 Dockerfile 文件创建一个新的映像，然后将其推送到目标注册表。还可以使用从单独的存储库中提取的现有映像，并将其推送到不同的存储库中。清单 2-6 展示了一个可以用来构建新映像的 Dockerfile 文件示例。
FROM nginx:stable-alpine
COPY IAKS /usr/share/nginx/html
Listing 2-6Dockerfile content
FROM命令将从 nginx 存储库中提取标记为 stable-alpine 的 nginx 映像。COPY命令会将 IAKS 目录的内容复制到路径/usr/share/nginx/html 中。我们可以通过从包含 Dockerfile 的目录中运行以下命令来创建这个新映像:
docker build --tag iaks/nginx:v1.
通过将其命名为iaks/nginx:v1，我们表明该映像的目标存储库将是 iaks Docker Hub 帐户，映像的名称是 nginx。我们将其标记为 v1，目前这是一个任意的标记。通过运行docker image ls，我们可以看到，在清单 2-7 中，我们现在在本地文件系统上有了一个新的镜像。
$ docker image ls
REPOSITORY TAG IMAGE ID
iaks/nginx v1 bbbdb4e15efd
Listing 2-7Listing the image created by docker build
最后，我们可以通过运行docker push命令将映像从本地文件系统推送到 Docker Hub 存储库。该命令的语法是
docker push [OPTIONS] NAME[:TAG]
在这种情况下，我们将运行清单 2-8 中所示的命令来推送映像。
$ docker push iaks/nginx:v1
The push refers to repository [docker.io/iaks/nginx]
7dd2de43c03e: Pushed
2bdf88b2699d: Mounted from library/nginx
f1b5933fe4b5: Mounted from library/nginx
v1: digest: sha256:00caf...f4997cea1 size: 94
Listing 2-8Pushing the image to Docker Hub
通过浏览器查看我们的 Docker Hub 帐户，我们可以在图 2-1 中看到，映像已经被成功地推送到我们的存储库。
图 2-1
成功将映像推送到 Docker Hub
现在可以提取这个映像，并在任何可以访问互联网的容器主机上运行它。这包括 Azure Kubernetes 服务集群中的工作节点。
映像标记
映像标签是与特定映像相关联的附加元数据。正如我们在注册表、存储库和映像一节中看到的，映像有一个存储库、标签和 ID。在清单 2-9 中，已经提取了三个 nginx 映像，它们都有不同的标签和映像 id。
REPOSITORY TAG IMAGE ID
nginx alpine dd025cdfe837
nginx perl 4d95835f5c94
nginx latest 53f3fd8007f7
Listing 2-9Listing of different nginx images
通过使用docker image tag命令，可以将多个标签与单个映像相关联。向映像添加另一个标记不会创建新的映像，也不会占用本地文件系统的更多空间。Docker 只是将这个新的元数据信息分配给现有的映像 ID。docker image tag命令的语法如下:
docker image tag SOURCE_IMAGE[:TAG] TARGET_IMAGE[:TAG]
例如，我们可以获取现有的 nginx:alpine 映像，并用 v1 标记它。
docker image tag nginx:alpine nginx:v1
在查看清单 2-10 中的本地映像清单时，两个映像都存在，并且具有相同的映像 ID。
$ docker image ls
REPOSITORY TAG IMAGE ID
nginx alpine dd025cdfe837
nginx v1 dd025cdfe837
nginx perl 4d95835f5c94
nginx latest 53f3fd8007f7
Listing 2-10Logging into Docker Hub
我们还可以为完全不同的存储库标记映像，然后将映像推送到该存储库。
docker image tag nginx:alpine iaks/custom
清单 2-11 中显示的三个条目将具有相同的映像 ID。
$ docker image ls
REPOSITORY TAG IMAGE ID
nginx alpine dd025cdfe837
nginx v1 dd025cdfe837
iaks/custom latest dd025cdfe837
Listing 2-11Logging into Docker Hub
标签只是与映像相关联的元数据。这包括神秘的最新的标签。如果没有为映像提供标签——就像我们在前面的命令中所做的那样——Docker 会自动给它一个最新的标签。当一个映像被拉取或用于实例化一个容器时，如果没有提供其他标签，Docker 将同样采用最新的标签。 latest 标签并不意味着被拉取的映像是最新的或者甚至是合适的映像。它只是映像被贴上了最新的标签，不管是故意的还是疏忽的。因此，在提取映像或运行容器时，总是建议指定映像的标签。
通用注册表
坞站中心和坞站注册表
用户最常开始使用的注册中心是 Docker Hub，如图 2-2 所示。Docker Hub 托管在 docker.io 上，为新用户提供了一个免费的家，让他们可以开始使用自己的第一个存储库。除非另外配置，否则 Docker CLI 假定 Docker Hub 是正在使用的注册中心。许多软件公司选择在 Docker Hub 上托管他们公开可用的容器，一些开源项目也是如此。Docker Hub 支持公共和私有存储库，尽管私有存储库不是免费的。
图 2-2
坞站中心网站
Docker Hub 基于开源项目 Docker Registry。Docker Registry 还可以用于在数据中心部署私有注册表。微软使用 Docker Registry 项目作为他们部署 Azure 容器注册表的基础，其他几个公共和私有注册表实现也是如此。
Azure 容器注册表
Azure Container Registry (ACR)是微软托管在 Azure 上的软件即服务产品。ACR 是基于 Docker Registry 开源项目的，但是它有额外的功能，我们将在本章的后面探讨。在 ACR 上创建的存储库本质上是私有的，并且总是需要某种类型的身份验证才能访问。ACR 有几个不同的 SKU 可供选择——基本、标准和高级——更高层提供更强大的存储、性能和复制选项。
存储在 ACR 上的映像可以是以下格式:
-
Docker 映像清单 V2，模式 1
-
Docker 映像清单 V2，模式 2
-
开放容器映像格式规范
ACR 服务还可以托管掌 Helm 图表，我们将在第 8 、【Azure Kubernetes 服务的掌 Helm 图表中对此进行更多探讨
为了在 ACR 上创建注册中心，你需要一个 Azure 订阅。可以通过 Azure 门户、Azure PowerShell 或 Azure CLI 创建新的 ACR 注册表。本节剩余部分和下一节中的示例将使用 Azure CLI。
清单 2-12 中的命令将使用 Azure CLI 创建一个新的 ACR 注册表。
### Create an Azure Container Registry ###
# Login to Azure and select subscription
az login
az account set --subscription "AZURE_SUBSCRIPTION_NAME"
# Create a resource group and Container Registry
az group create --name RESOURCE_GROUP_NAME --location "LOCATION_NAME"
az acr create --resource-group RESOURCE_GROUP_NAME --name ACR_NAME --sku Basic
Listing 2-12Creating a new ACR registry
ACR_NAME 必须是全局唯一的。它将被附加到 azurecr.io 中，为您的注册表创建公开寻址的 fqdn。
在下一节中，我们将更深入地探索 Azure 容器注册中心的一些组件，包括它如何与 Azure Kubernetes 服务集成。
Azure 容器注册表已扩展
虽然 Azure Container Registry (ACR)服务是基于 Docker Registry 开源项目的，但它有许多额外的增强功能值得一提。ACR 利用 Azure Active Directory (Azure AD)支持的基于角色的访问控制(RBAC)来控制对服务上托管的存储库的访问。ACR 已经超越了基本的注册中心，支持作为服务的一部分运行简单或多步任务的能力。由于 ACR 运行在 Azure 中，它与包括 Azure Kubernetes 服务在内的其他 Azure 服务进行了一些定制集成。
安全
有三种不同的 ACR 认证方式:
-
Azure AD 个人登录:登录 ACR 的个人使用他们的 Azure Active Directory 帐户对 ACR 进行身份验证。在要求他们再次进行身份验证之前，会向他们发放一个一小时内有效的令牌。
-
Azure AD 服务主体:类似于个人登录，但是，服务主体可以用于无头认证，并且最常用于自动化平台。
-
管理员帐户:管理员帐户是一个没有链接到 Azure Active Directory 的帐户。admin 帐户拥有在 ACR 注册表上执行任何操作的完全权限。默认情况下，admin 帐户是禁用的，它应该只用于测试和紧急情况。
为了登录到我们在上一节中创建的 ACR，我们可以使用以下命令:
az acr login --name ACR_NAME
由于我们已经登录到 Azure，ACR 获取我们现有的凭证并生成一个令牌供 ACR 使用，这个令牌在一个小时内有效。这段时间过后，令牌过期，必须再次运行az acr login命令。服务主体登录在登录时使用用户名和密码，因此没有基于缓存凭据颁发的令牌。在自动化流程中使用 ACR 时，服务主体登录是首选的登录类型。
无论是使用个人登录还是服务主体选项，权限都是通过明确定义的角色来分配的。
许可
与 Microsoft Azure 中的许多服务一样，Azure Container Registry 中的权限是使用基于角色的访问控制(RBAC)来分配的。在撰写本文时，该服务定义了七个角色。表 2-1 概述了角色及其权限。
表 2-1
Azure 容器注册的 RBAC
|权限/角色
|
物主
|
捐助者
|
读者
|
广告
|
空气拉力
|
ArcDelete
|
AcrImageSigner
|
| — | — | — | — | — | — | — | — |
| 访问资源管理器 | -好的 | -好的 | -好的 | | | | |
| 创建/删除注册表 | -好的 | -好的 | | | | | |
| 推送映像 | -好的 | -好的 | | -好的 | | | |
| 拉映像 | -好的 | -好的 | -好的 | -好的 | -好的 | | |
| 删除映像数据 | -好的 | -好的 | | | | -好的 | |
| 改变策略 | -好的 | -好的 | | | | | |
| 标志映像 | | | | | | | -好的 |
这些角色的分配应遵循最小特权原则，即分配给个人或服务执行特定任务所需的最少权限。AcrPush、AcrPull、AcrDelete 和 AcrImageSigner 角色是专为在其生命周期内执行特定任务的服务和自动化流程而设计的。例如，假设我们使用 Azure Kubernetes 服务来部署存储在 ACR 中的容器。作为 AKS 群集使用的服务主体，AcrPull 角色将授予它足够的权限来访问所需的容器映像，而不授予对资源管理器的访问权限，这是 Reader 角色包含的权限。同样，任何构建新容器映像的 CI/CD 流水线都可以被授予 AcrPush 权限，以便将新映像推送到 ACR。
任务和自动化
除了容器映像的存储，Azure 容器注册服务还包括运行简单和多步骤任务的能力，并在某些操作完成时发出 webhooks。任务和 webhooks 提供了利用 ACR 执行与映像管理相关的常见任务的能力，并有助于集成到 CI/CD 流水线中。
ACR 中的任务可以分为简单任务和多步骤任务，简单任务可以使用az acr build或az acr task命令启动，多步骤任务由 YAML 文件定义并通过az acr run命令提交。
简单的任务
简单的任务用于构建容器映像的新版本。可以使用az acr build命令手动触发映像的构建。这样做可以将构建容器的负担从本地工作站转移到 ACR，并将生成的映像放在 ACR 中，而不必从本地文件系统推送。使用以下命令从本地 docker 文件创建新映像:
az acr build --registry iaks --image web:v2.
该命令将在容器注册表 iaks 上的映像库 web 中构建一个标记为 v2 的映像。除了从本地工作站卸载构建过程之外，CI/CD 流水线中的服务主体还可以使用相同的命令来自动构建新的容器映像，而无需使用流水线代理计算机上的资源。
它可以由 git 提交或基本映像的更新来触发，而不是手动运行任务。虽然基于 git 提交进行更新的想法具有直观的意义，但是在更新基础映像时更新映像的概念需要一些解释。
ACR 了解存储在其存储库中的映像的映像依赖性。例如，你闪亮的新 web 容器映像可能基于 Docker Hub 的 alpine:stable 映像。当基础映像更新时，您可能希望您的 web 映像也更新，以包含基础映像中的任何更改。ACR 支持创建一个构建任务，如果它检测到存储库中某个映像的基本映像已经更新，就会触发该任务。在这种情况下，命令看起来会像清单 2-13 中的内容。
az acr task create \
--registry iaks \
--name task-web-service \
--image web:v2 \
--arg REGISTRY_NAME=iaks.azurecr.io \
--context https://dev.azure.com/iaks/_git/iaks.git \
--file Dockerfile-web \
--branch master \
--git-access-token $TOKEN
Listing 2-13Creating an ACR task to update an image based on base image updates
Dockerfile-web 文件的定义中引用了 alpine:stable 的基本映像。ACR 反过来创建一个钩子来监听基础映像的变化，如果检测到变化，就会启动一个构建任务。
多步骤任务
ACR 中的多步骤任务建立在现有的简单任务的基础上，同时增加了更多的功能。多步骤任务中的操作包括
-
Build:构建一个或多个容器映像 -
Push:将映像推送到私有或公共容器注册表 -
Cmd:使用与docker run相似的参数运行容器
作为多步骤任务的一部分而执行的动作在 YAML 格式的文件中定义，该文件使用清单 2-14 中的命令提交给 ACR。
az acr run \
--registry iaks \
-f multi-step-task.yml \
https://dev.azure.com/iaks/iaks.git
Listing 2-14Creating a multi-step task in ACR
该命令指示 ACR 使用在引用的 git 存储库中找到的文件 multi-step-task.yml 在注册表 iaks 上运行任务。
可以在工作流中使用多步骤任务来构建和测试组成基于容器的应用的一组映像，然后在任务中定义的测试通过时更新 Helm 图。虽然这并不能替代全功能 CI/CD 流水线，但它确实提供了一种在代码中定义工作流的方法，并在对 git 存储库进行新的提交时让它们执行。
web 手册
当一个动作在 Azure Container Registry 中完成时，它可以通过 webhook 通知其他服务。这有助于发送简单的通知或启动自动化工作流。触发网络挂钩支持的操作有
-
映像推送
-
映像删除
-
映像隔离
-
Helm 图按钮
-
Helm 图删除
触发 webhook 会向 webhook 配置中定义的服务 URI 发送 POST 请求。POST 请求包括 JavaScript 对象符号(JSON)格式的信息，该信息依赖于触发 webhook 的操作。还可以在 webhook 配置中定义自定义头，随每个 POST 请求一起发送。如果目标服务 URI 需要认证或 POST 有效负载中不包含的一些其他定制数据，则可以利用这些信息。
创建一个 webhook 来联系 Postman echo 服务进行映像推送，如清单 2-15 所示。
az acr webhook create \
--registry iaks \
--name postmanhook \
--actions push \
--uri https://postman-echo.com/post
Listing 2-15Logging into Docker Hub
Postman echo 服务将简单地回复初始 POST 请求的内容，这有助于理解 webhook 发送的信息。
蓝色 Kubernetes 服务集成
Azure Kubernetes 服务(AKS)使用容器映像和 Helm 图将应用部署到 AKS 集群中的节点。方便的是，Azure Container Registry 能够存储这两种资源，并使它们可供 AKS 使用。为了访问存储在 ACR 注册表上的资源，AKS 可以使用 Azure Active Directory 身份验证。
当一个新的 AKS 集群被创建时，它在 Azure Active Directory 中被分配一个服务主体。可以将服务主体的角色分配给 Azure 容器注册中心托管的注册中心，包括 AcrPull 角色。有了这个角色，AKS 集群将能够提取托管在该容器注册表中的容器映像和 Helm 图。
将 ACR 与 AKS 结合使用允许您将映像托管在私有注册表中，并使用本地身份验证服务 Azure AD 为 AKS 集群提供适当的访问级别。您还可以利用 ACR 任务来自动构建、测试和发布基于容器的应用到您的 AKS 集群。
摘要
容器注册中心是在 Kubernetes 上部署应用的关键组件。如果没有映像存储库，就必须将映像手动复制到集群中的每个节点。这不是一个理想的情况。在 Azure Kubernetes Service 中构建和操作应用之前，对容器注册中心及其操作方式有一个适当的了解是很重要的。
在这一章中，你学习了不同类型的容器注册——私有的和公共的。我们讨论了用于与托管在容器注册中心的映像存储库进行交互的命令和工具，包括像推、拉和标记这样的操作。然后，我们研究了 Azure 容器注册服务的特性，以及它如何与 Azure Kubernetes 服务集成。
三、Kubernetes
容器之旅的第一部分是选择容器运行时，了解它的来龙去脉，以及容器化应用。下一个级别是准备在企业级别的生产中运行容器。为了在生产中运行容器，您将需要一个编排平台。
应用的容器化通常包括将应用从整体架构解耦到基于微服务的架构中，组件分散在多个容器中。这导致需要管理数百甚至数千个容器，其中许多共享相同生命周期的容器需要一起管理。
编排平台是管理容器生命周期的解决方案。编排平台控制和自动化动态企业环境中的容器，包括以下功能:
-
供应节点
-
实例化和调度容器
-
容器可用性和冗余
-
跨节点均匀分布容器
-
跨容器的资源分配
-
根据需要扩展集群节点
-
主机和容器运行状况和性能监控
-
根据需要放大或移除容器
-
如果主机上的资源不足，或者主机出现故障，则根据需要在主机之间移动容器
-
跨容器服务发现的负载均衡
-
对容器中运行的服务的外部访问
-
与运行应用的容器相关的应用配置管理
市面上有很多编排平台。进入 Kubernetes，最流行的容器编排平台。Kubernetes 由 Google 创建，旨在在您选择的环境中工作，如裸机服务器、虚拟服务器和公共云上的本地环境。
Kubernetes 已经成为容器编排平台的黄金标准；事实上，三大云提供商 AWS、GCP 和 Azure 也都提供托管的 Kubernetes 服务。Kubernetes 是一个紧密集成的平台，包括托管 Kubernetes 组件、Docker 运行时或莫比运行时，以及提供主机节点和容器的编排。
Kubernetes 的主要特点包括
-
容器的部署和复制
-
缩放容器
-
容器的负载均衡
-
集群中节点的滚动升级
-
故障容器的弹性和自动重新调度
-
容器网络港口对外开放
Kubernetes 的建筑可以看作是复杂的。该架构确实有许多可移动的部分，理解它们很重要。图 3-1 是 Kubernetes 架构的可视化表示。
图 3-1
不可思议的建筑
作为使用 Azure Kubernetes Service (AKS)的先驱，最好对 Kubernetes 有一个扎实的了解。在本章的以下几节中，我们将深入探讨 Kubernetes 的各种组件。
无缝接口
有多种方式与 Kubernetes 交互。Kubernetes 有一个 REST API，您可以使用 REST 调用直接与 API 交互。有一些第三方工具利用这种方法，比如 Rancher 将 Kubernetes 管理引入 Rancher 接口。
第二种最常见的与 Kubernetes 交互的方式是通过 kubectl 命令行接口。在 Kubernetes 中，您几乎可以使用 Kubectl 做任何事情。使用 Kubectl 可以执行的一些任务包括部署 pod、检查和管理集群资源、处理节点、查看日志和升级集群。在第四章“kubectl 概述”中，您将更深入地了解 Kubectl。
除了 Kubectl 命令行界面，Kubernetes 还有一个基于 web 的用户界面，称为 Kubernetes 仪表板。该仪表板可用于 Kubernetes 的基本管理操作。您可以管理诸如 pod、部署、作业、节点、卷、副本集等资源。它还可以用来获取 Kubernetes 资源的状态和健康信息。图 3-2 是 Kubernetes 仪表盘的截图。
图 3-2
Kubernetes 的控制板
Docker 运行时
运行容器需要运行时。Kubernetes 支持 Docker 和 RKT 运行时。正如本书第一章“Docker 容器内部”所述，容器领域中最广泛采用的运行时是 Docker。在 Kubernetes 中，你会发现最常见的运行时是 Docker。使用 Docker，您可以运行基于 Linux 或 Windows 的容器。在 Kubernetes 中运行 Docker 时，也可以运行 Linux 或 Windows 容器。
主节点概述
在 Kubernetes 中，有一个控制和协调集群的主节点。主节点本质上负责管理集群。这个主节点协调集群中发生的任何活动，例如供应节点、节点到节点的通信、充当与 Kubernetes 的接口、调度节点上的容器、维护容器的期望状态以及通过滚动更新工作的应用，等等。以下是构成主节点的组件:
-
Etcd 是一个简单的、分布式的、一致的键值存储。Etcd 存储关于 Kubernetes 集群的数据。它存储数据，如节点、单元、计划作业、服务、API 对象、名称空间和有关集群的其他配置。为了保持安全，只能通过 API 服务器组件访问它。
-
Apiserver 是 Kubernetes 集群所有 REST 请求的中心入口点。REST 请求可用于控制集群，并对组件(如 pod、部署、副本集、服务等)执行操作。Apiserver 还用于与 etcd 通信。
-
Kube-controller-manager 监视 Kubernetes 集群的共享状态，并根据需要进行更改，以确保集群符合所需状态。例如，确保当前正在运行的 pod 数量正确，并且如果 pod 移动，指向 pod 的服务正在运行并跟踪它们。控制器管理器从 Apiserver 获取共享状态。控制器管理器还在后台执行控制器进程的例行任务。
-
除了云控制器管理器处理依赖于底层云提供商的控制器进程之外，云控制器管理器与 Kube 控制器管理器完全一样。例如，如果 Kubernetes 运行在 Azure 上，并且正在利用 Azure 负载均衡器，那么云控制器管理器可以确保所需的负载均衡器正在运行。
-
Kube-scheduler 是处理 Kubernetes 集群中各个节点上的 pod(容器)的所有调度(放置)的组件。调度程序具有关于集群中每个节点的可用资源的信息，因此它可以将 pod 正确地放置在具有可用容量的节点上。
工作节点概述
工作节点是 pod 和应用运行的地方。工作节点是虚拟机。在 Kubernetes 中，您可以拥有 Linux 或 Windows 工作节点。Linux 节点将运行容器和应用，如 Java、Apache Tomcat 和其他基于 Linux 的工作负载。Windows 节点将运行容器和应用，如 IIS、。Net、ASP.net 等等。工作节点包含所有必要的服务，比如运行时、联网、调度、维护容器状态以及与主节点的通信。以下是构成 worker 节点的组件:
-
Docker 是运行容器的运行时引擎。Docker 运行时位于 Kubernetes 集群中的每个节点上。
-
Kubelet 是一种处理与主节点和 etcd 通信的服务。它获取关于新的和现有服务的信息。Kubelet 确保期望的容器是健康和运行的。
-
kube-proxy 充当网络代理和负载均衡器，在 worker 节点上向外界公开服务。它处理 TCP 和 UDP 连接的网络路由。
-
kubectl 是 Kubernetes 命令行接口，与推送到主节点的 Apiserver 交互。
命名空间
名称空间被用来在多个团队之间对 Kubernetes 集群中的资源进行逻辑分段和组织。资源被部署到 Kubernetes 集群的一个名称空间中。这些资源被组合在一起，以便能够作为一个单元进行过滤和控制。
名称空间用于避免冲突。例如，当团队扩展到拥有数千个单元时，部署可能会有相同的名称。在这种情况下，您可以有多个名称空间，其中部署在不同的名称空间中存在重叠的名称，以避免冲突，并简化管理、组织和安全性，如访问策略(RBAC)。有时，名称空间用于生命周期环境，如开发、登台和生产。对于这些环境中的每一个环境，相同的资源可以同时存在于每一个环境中，因为它们在逻辑上是分离的，并且不会相互冲突。
在每个 Kubernetes 集群中，都有一个“默认”名称空间。部署资源时，如果不指定命名空间，它将部署到默认命名空间中。对于 Kubernetes，默认情况下还部署了另外两个名称空间。这些名称空间是 kube-system(用于存储 Kubernetes 组件)和 kube-public(用于存储公共资源，无论是否经过身份验证，所有用户都可以全局读取这些资源)。在 YAML 文件中或者通过使用 Kubectl 命令，很容易创建一个定制的名称空间。下面是执行此操作的语法:
kubectl create namespace namespace1
以下是一个 YAML 文件示例:
kind: Namespace
apiVersion: v1
metadata:
name: namespace1 labels:
name: namespace1
Syntax to apply the YAML file to create the namespace:
kubectl apply -f namespace1.yaml
您可以使用 Kubectl 命令来列出当前的名称空间:
kubectl get namespace
要耗尽命名空间运行:
kubectl delete namespace namespace1
标签和注释
在 Kubernetes 中，当您需要组织、识别和简单地存储关于对象的数据时，标签和注释是帮助您做到这一点的首选功能。如果你曾经使用过像微软 Azure 这样的公共云，你会对这种需求很熟悉，因为你可能使用过标签来帮助组织你的云基础设施。像公共云一样，Kubernetes 在标签和注释方面也有类似的特性。标签和注释将整个标记概念带到了另一个层次。让我们探索标签和注释。
标签是键值对。这些键必须是唯一的。密钥还必须包含 63 个或更少的字符，值必须包含 253 个或更少的字符。标签旨在用于组织、查询和标识一组对象。标签可以在创建时或任何时候贴在对象上:
"metadata": {
"labels": {
"appname" : "webappX",
"environment" : "dev"
}
}
注释也是键值对。与标签相比，注释可以包含更多的字符。注释中的数据是任意的，可以是结构化的或非结构化的，并且能够包括标签中不支持的字符。需要注意的是注释是不能被查询的。注释是在 Kubernetes 中为对象放置元数据的好方法。外部系统和工具可以使用注释数据。下面是一些注释数据的例子:环境，比如 dev、stage、prod、git 分支、pull 请求号、映像信息，比如时间戳或日期、版本信息、应用所有者、部门等等。下面是注释的一个示例:
"metadata": {
"annotations": {
"gitbranch": "brancha",
"department": "marketing"
}
}
综上所述，当您需要查询 Kubernetes 集群中的对象时，请使用标签；当您需要在 Kubernetes 中存储关于对象的一般信息，但不需要查询它，但在外部系统中可能也需要这些信息时，请使用注释。此外，标签应该用于识别对象，当对象上需要非识别数据时，应该使用注释。
Pods
pod 是 Kubernetes 中的一个或多个容器，它们共享资源并耦合在一起。它代表一个部署单元。pod 封装了一个应用，包括容器、存储、网络 IP 以及如何运行容器的配置。把 POD 想象成包裹容器的包装纸。pod 通常部署成两种模式之一:第一种模式是运行单个容器的 pod，第二种模式是运行需要紧密耦合在一起的多个容器的 pod。
单容器 pod 是 Kubernetes 中更常见的用例。多容器 pod 是一种高级场景，用于多个容器组成一个应用，共享相同的生命周期，并需要共享存储和网络等资源。当多个容器属于同一个 pod 时，它们是单个受管实体。调度 pod 时，容器将被放置在同一个节点上，如果 pod 需要移动到另一个节点，所有包含的容器都将被移动。下面是一个 pod 的代码示例:
apiVersion: v1
kind: Pod
metadata:
name: app1-pod
labels:
app: app1
spec:
containers:
- name: app1-container
image: nginx
复制集
副本集定义了一组副本盒。副本集可用于指定需要多少个相同的 pod。例如，如果您想要运行 pod 的四个副本，您可以将其指定为 replicaset 中的副本。Kubernetes 将确保四个 pod 副本一直运行。如果一个 pod 出现故障，将自动部署一个新的 pod，以确保 replicaset 保持运行所需的四个 pod。
注意
本章后面介绍的部署能够管理副本集。副本集通常在部署中定义。建议使用部署集，而不是直接定义副本集。
DaemonSet
DaemonSets 管理复制的 pod 组。它们可用于确保 Kubernetes 集群中的所有节点运行特定 pod 的副本。当您在所有或特定节点上需要一些管理功能时，通常会使用 DaemonSets。何时使用 DaemonSet 的一个例子是，如果您需要使用 fluentd 在所有节点上执行日志收集。另一个例子是当您需要在所有节点上使用一个监控代理时，比如 new relic、AppDynamics、Log Analytics 或 Datadog。
作业
Kubernetes 的工作是监督运行批处理过程的 pod，这些批处理过程在有限的时间内完成。典型的用例或工作是备份、发送电子邮件、代码转换或计算操作。Jobs 支持平行和非平行。
服务
Kubernetes 集群中的服务是定义一组逻辑单元的抽象。服务也是一种机制，用于公开对 pod 或 pod 上运行的应用的外部访问。服务是 pod 顶部的抽象，它提供了一个 IP 地址和 DNS 名称，通过它可以访问 pod。很容易将服务视为指向一个或一组 pod 的指针。当 pod 在 Kubernetes 集群服务中从一个节点移动到另一个节点时，会自动跟踪 pod 所在的位置。有以下三种类型的服务:
-
集群 IP 是部署服务时使用的默认类型。ClusterIP 公开了一个只能在群集内访问的群集内部 IP。
-
节点端口 在节点上的静态端口上公开服务。
-
负载均衡器 配合云提供商使用。负载均衡器使用云提供商负载均衡器对外公开服务。
下面是一个服务代码的示例:
apiVersion: v1
kind: Service
metadata:
name: app1-service
spec:
selector:
app: App1
ports:
- protocol: TCP
port: 80
targetPort: 9523
部署
部署描述了副本集和 pod 的理想状态。部署是清单 yaml 文件。部署控制器通过相应地创建、更新或删除副本集或 pod 来协调 Kubernetes 集群以匹配所需的状态。
配置映射
对于容器化的应用，环境配置应该从应用中抽象出来，并在容器和应用之外处理。这基本上就是容器如何处理配置管理的。将配置与容器和应用分开是使容器可移植的技术之一。配置映射是 Kubernetes 中的一项功能，有助于配置管理。ConfigMaps 保存 pod 中使用的配置数据的键值对。ConfigMaps 在运行时将配置工件绑定到 pod、容器和系统组件。配置工件由命令行参数、配置文件、环境变量和端口号组成。
注意
配置映射应该用于不需要保护的非敏感配置。对于敏感的配置或数据，应该使用 Kubernetes 中的秘密。
ConfigMap 键值数据可以是文字数据，也可以来自文件。配置映射是使用 Kubectl 创建的。以下是创建配置映射的语法:
-
示例 : kubectl 创建配置映射[名称][数据]
-
示例:ku bectl create config map app 1-data-from-file app 1-configs/
kubectl create configmap 用于创建包含键值对的配置映射。和 from-file 指向一个目录。目录中的文件用于填充配置图中的一个键。密钥的名称是文件名。密钥的值来自文件的内容:
- 示例:ku bectl create config map app 1-config-from-literal = app 1-config . app 1 name = myapp 1
创建配置映射后，pod 可以通过 yaml 文件使用它。下面是一个 yamle 文件示例:
apiVersion: v1
kind: Pod
metadata:
name: app1-pod
labels:
app: app1
spec:
containers:
- name: app1-container
image: nginx
env:
- name: app1name
valueFrom:
configMapKeyRef:
name: app1-config
key: app1name
秘密
在 Kubernetes 中，当您需要保护信息时，您可以使用秘密对象。秘密是在 Kubernetes 集群中存储和管理敏感信息的一种方式，比如密码、令牌、SSH 密钥等等。然后，您可以在 pod 或容器映像中引用该秘密，而不是间接地放置密码等秘密。秘密可以从文件或字面上创建。下面是一个使用文字创建秘密的示例:
kubectl create secret generic app1-pass –from- literal=password=PASSWORDHERE
然后在 pod yaml 文件中引用这个秘密。这是一个例子:
env:
– name: APP1_PASSWORD
valueFrom:
secretKeyRef:
name: app1-pass
key: password
建立关系网
与容器联网是复杂的。Kubernetes 的核心是使与容器的联网更容易、更灵活。Kubernetes 在命名、负载均衡、端口分配甚至应用配置方面，将 pods 与网络联系起来，就像它与虚拟机的工作方式一样。Kubernetes 默认使用覆盖网络。Kubernetes 为每个 pod 提供了自己的可路由的唯一 IP 地址和一个 DNS 名称。该 IP 由 pod 中的所有容器共享。
Kubernetes 集群内部的地址空间是扁平的，允许 pods 在没有代理的情况下直接相互通信。pod 也可以跨节点相互通信。Kubernetes 将 iptables 用于 pod 之间的网络连接。可路由的 IP 和 IP 表使您不必像在 Docker 中那样将主机端口映射到容器端口。
当你读到这里的时候，你可能会问自己，“点对点的交流是好的，但是怎样才能把互联网流量从互联网传到点对点呢？”Kubernetes 中的服务将 pod 逻辑地组合在一起，为 pod 上运行的应用提供网络连接。有多种服务类型，可用于将流量路由到 pod。Kubernetes 中存在以下服务类型:
-
节点端口是运行 pod 的节点上的端口映射，允许通过节点 IP 和端口直接访问应用。
-
ClusterIP 是一个内部 IP 地址，在 Kubernetes 集群中用于内部通信。
-
负载均衡器是底层云提供商基于云的负载均衡器，具有外部 IP 地址。负载均衡器后端池已连接到请求的 pod。
-
ExternalName 是访问 pods 上运行的应用的 DNS 条目。
除了前面提到的四种服务类型，还有入口控制器。入口控制器工作在网络 OSI 模型的第 7 层。入口控制器提供可配置的流量路由、TLS 终端和反向代理。入口控制器具有到 Kubernetes 服务的入口规则和路由。入口控制器的一个常见用途是能够从一个公共 IP 地址路由到 Kubernetes 集群中的多个服务。Kubernetes 中最常见的入口控制器是 NGINX 入口控制器。
仓库
容器中的文件是短暂的。当容器重新启动时，文件会丢失。如果需要在容器重启时保留数据，可以使用 Kubernetes 卷。Kubernetes 支持许多类型的卷；但是，最常见的选项是卷或永久卷。对于卷，当容器被销毁时，卷也将不复存在。对于永久卷，当容器被销毁时，数据将继续存在。Kubernetes 中有两种类型的持久卷:第一种是持久卷，第二种是持久卷声明。持久卷是独立于任何 pod 的群集中的资源。为 pod 所在的命名空间中的特定 pod 请求永久卷声明。核心上，卷只是一个包含 pod 中的容器可以访问的数据的目录。以下是 Kubernetes 支持的卷的完整列表:
awsElasticBlockStore
azureDisk
azureFile
cephfs
cinder
configMap
csi
downwardAPI
emptyDir
fc (fibre channel)
flexVolume
flocker
gcePersistentDisk
gitRepo (deprecated)
glusterfs
hostPath
iscsi
local
nfs
persistentVolumeClaim
projected
portworxVolume
quobyte
rbd
scaleIO
secret
storageos
vsphereVolume
在 Kubernetes 中，我们也有一些被称为存储类的东西。存储类与 Kubernetes 中持久存储卷的动态供应一起工作。动态存储配置是指在订购具有预定义类型和配置的存储时，无需了解如何配置物理或云存储设备的详细信息。存储类抽象了特定存储类型的所有细节，然后由开发人员或云提供商使用。存储类别为管理员提供了一种描述他们提供的存储“类别”的方式。类别对应于服务级别和/或备份策略。
摘要
在这一章中，我们向您介绍了 Kubernetes。随着您踏上 Azure Kubernetes 服务之旅，您现在将具备 Kubernetes 及其组件的核心知识。在这一章中，我们探索了 Kubernetes 体系结构，了解了主节点和工作节点以及名称空间、标签、作业、服务和复制集等关键特性。我们还了解了在需要保护信息时使用配置映射和机密进行配置管理。我们了解到 Kubernetes 有一个基于 web 的用户界面，可以用于一些管理任务。最后但同样重要的是，我们探索了 Kubernetes 中网络和存储的工作方式。
四、kubectl概述
kubectl是一个命令行界面，用于对 Kubernetes 集群执行命令。您可以使用 kubectl 来部署应用、检查和管理 Kubernetes 集群资源以及检查日志。
在本章中，我们将讨论用于集群操作的各种kubectl命令。我们将介绍基本命令，并提供如何使用kubectl进行常见操作的示例，如应用管理、调试和集群管理。本章结束时，您将能够使用kubectl在 Kubernetes 集群上执行基本操作。
kubectl 简介
当您在kubectl中执行操作时，它会在$HOME/.kube目录中查找名为 config 的文件。如果您想使用存储在不同目录中的 kubeconfig 文件，您可以通过设置 KUBECONFIG 环境变量或设置--kubeconfig标志来实现。
kubeconfig 文件用于组织关于集群、用户、名称空间和认证机制的信息。kubectl使用 kubeconfig 文件选择集群，并与集群的 API 服务器通信。此外，您还可以定义上下文，以便在集群和名称空间之间快速切换。
在 kubeconfig 文件中，上下文元素用于将访问参数分组到一个方便的名称下。每个上下文有三个参数:集群、名称空间和用户。kubectl默认情况下，使用当前上下文中的参数与集群通信。
注意
kubectl默认安装在 Azure 云壳中。有关使用 kubeconfig 文件组织集群访问的完整指南，请参考位于以下 URL 的 Kubernetes 官方文档: kubernetes。io/docs/concepts/configuration/organize-cluster-access-kube config/。
几乎所有的kubectl命令通常属于表 4-1 中列出的类别之一。
表 4-1
kubectl 命令类别
|命令类型
|
使用
|
描述
|
| — | — | — |
| 声明性资源管理 | 开发和运营 | 用于以声明方式使用资源配置管理 Kubernetes 工作负载。 |
| 必要的资源管理 | 仅开发 | 使用这些命令通过命令行参数和标志来管理 Kubernetes 工作负载。 |
| 打印工作负荷状态 | 排除故障 | 包括用于以下操作的命令:打印资源的汇总状态和信息、打印资源的完整状态和信息、打印资源的特定字段以及查询与标签匹配的资源。 |
| 与容器交互 | 排除故障 | 用于调试 Exec、Attach、Cp 和 Logs 等操作，包括用于打印容器日志、打印群集事件、执行或附加到容器以及将文件从群集中的容器复制到用户文件系统等操作的命令。 |
| 集群管理 | 排除故障 | 用户需要在集群节点上执行操作，kubectl 支持 drain 和 cordon 节点等集群操作的命令。 |
注意
kubectl默认安装在 Azure 云壳中。要在本地安装kubectl，请在 Azure CLI 中执行az aks install-cli命令。
Kubernetes 基础
本节提供了基本 kubectl 命令的高级概述。在整本书中，您会注意到使用中的各种 kubectl 命令。在本节中，我们将只介绍最常用的命令。本节中展示的例子涉及到在 Kubernetes 中部署一个简单的 ngnix 集群。
立方结构语法
以下是从终端运行 kubectl 命令的语法:
-
命令:这指定了用户想要对资源执行的操作，比如创建、获取和删除**。**
-
类型:这表示资源。请记住，资源类型不区分大小写，您可以使用单数、复数或缩写形式来引用资源类型。
-
名称:这表示资源名称。资源名称区分大小写。如果不提供名称，将显示所有资源的详细信息。
-
标志:标志是可选的。例如，您可以利用
-s或--server标志来指定 Kubernetes API 服务器的地址和端口。
kubectl [command] [TYPE] [NAME] [flags]
注意
要获得使用 kubectl 可以执行的操作的完整参考，请访问 kubectl reference，网址为 kubernetes。io/docs/reference/kube CTL/kube CTL/。
您可以通过在终端中运行kubectl api-resources来列出所有支持的资源类型及其别名。
在 kubectl 中格式化输出
任何 kubectl 命令的默认输出都是纯文本。为了生成特定格式的输出，可以使用-o或--output标志。以下是您需要使用的语法:
kubectl [command] [TYPE] [NAME] -o <output_format>
表 4-2 列出了根据您执行的kubectl操作支持的输出格式。
表 4-2
立方结构输出格式
|输出格式
|
描述
|
| — | — |
| -o 自定义列= | 使用逗号分隔的自定义列列表显示表格。 |
| -o custom-columns-file= | 使用文件中的自定义列模板显示表格。 |
| -哦，我的上帝 | 打印 JSON 格式的 API 对象。 |
| -jsonpath = |
五、部署 Azure Kubernetes 服务
Azure Kubernetes Service (AKS)通过提供托管的 Kubernetes 即服务平台，简化了 Kubernetes 集群的部署。通过将健康监控和维护以及主节点管理等日常任务卸载到 Azure 平台，降低了管理 Kubernetes 的操作复杂性。
在本章中，我们将探讨如何使用 Azure 门户、Azure CLI、Azure 资源管理器(ARM)模板和 Terraform 部署 AKS 集群。我们将回顾每个部署选项的流程，然后解释其他功能配置，如高级网络、Azure Active Directory 集成和监控。在本章结束时，您将对 AKS 部署过程、选项和步骤有一个很好的了解。
Azure Kubernetes 服务部署概述
您可以使用几种方法部署 AKS 集群。每种方法都有自己的优点，选择如何部署 AKS 集群取决于您的偏好和场景。但是，您必须提供一些在所有这些方法中部署 AKS 集群所需的强制参数。我们将在接下来的章节中讨论这些参数是什么。
通过 Azure 门户进行部署
使用 Azure 门户创建 AKS 集群是一个简单的过程。下面解释了这样做的过程。
在 Azure Marketplace 中，选择 +创建资源 ➤ 容器 ➤ Kubernetes 服务。在创建 Kubernetes 集群页面中，配置以下选项:
-
在基础部分，需要配置以下选项:
-
项目细节:在这个部分中，选择您需要创建 AKS 集群的 Azure 订阅。
-
集群细节:为 AKS 集群选择或创建一个 Azure 资源组，为 Kubernetes 集群名称提供一个值，为部署 AKS 集群提供一个 Azure 区域，选择想要的 Kubernetes 版本，最后为 AKS 集群提供一个 DNS 名称前缀。
-
主节点池:在这个部分，您需要从 Azure VM SKUs 中为 AKS 节点选择一个 VM 大小。请记住，一旦创建了 AKS 集群，就不能更改虚拟机的大小。选择虚拟机大小和节点计数。您可以从将节点计数设置为 1 开始。
-
Click Next: Scale ➤.
图 5-1
创建一个 Kubernetes 集群基础部分
-
-
在刻度部分保留默认选项；之后，点击下一步:认证 ➤.
注意我们将在第七章“运营 Azure Kubernetes 服务”中详细讨论 AKS 的扩展选项
-
在认证部分:
-
您可以通过保持服务主体字段不变来创建新的服务主体，或者选择配置服务主体来使用现有的服务主体。请记住，如果您选择使用现有的，您将必须在下一个弹出的刀片中提供服务主体名称(SPN)客户端 ID 和机密。
-
启用 RBAC :将该选项设置为是以允许 Kubernetes 基于角色的访问控制(RBAC)，该控制对访问 AKS 集群资源提供更细粒度的控制
-
Click Next: Networking ➤.
图 5-2
创建一个 Kubernetes 集群验证部分
-
-
Leave the Network configuration radio button to Basic settings under the Networking section to use kubenet with a default VNet configuration. Selecting Advanced will redirect you to configure the following which allows you to use an Azure CNI with further options to customize your VNet. Click Next: Monitoring ➤.
图 5-3
创建一个 Kubernetes 集群网络部分
-
Under Monitoring section, leave the Enable container monitoring option to Yes. Here you can either create a new Log Analytics workspace for your new AKS cluster or create a new one. Once done, click the Review + Create button at the bottom of the screen. Once the validation is completed, click Create.
图 5-4
创建一个 Kubernetes 集群验证部分
创建 AKS 群集的过程需要几分钟时间来完成部署。部署完成后，您可以通过点击下的转到资源下的【后续步骤】或通过在屏幕顶部的搜索栏中搜索资源组名称或 AKS 集群名称来访问其仪表板，从而查看 AKS 集群的状态。
图 5-5
AKS 集群仪表板
通过 Azure CLI 部署
Azure CLI 是用于管理 Azure 资源的命令行工具。它被设计成一个跨平台的工具，可以部署在 Windows、Linux 或 MacOS 系统上。为了提供更好的 Azure CLI 体验，Azure 门户提供了 Azure Cloud Shell ，这是一个交互式 Shell 环境，您可以通过浏览器使用它。使用 Azure Cloud Shell 的优势在于，您可以将它与预安装的 bash 或 PowerShell Azure CLI 命令一起使用，而无需在本地计算机上安装任何东西。
注意
为了尝试本节中的说明，您可以选择使用安装在本地计算机上的 Azure CLI 或利用 Azure Cloud Shell。
-
Launch an Azure Cloud Shell session by clicking the Cloud Shell button on the top-right menu bar in the Azure Portal.
图 5-6
推出 Azure 云壳
-
通过输入以下 Azure CLI 命令，创建一个资源组来部署您的 AKS 群集。
az group create --name jcbaksrg01 --location eastus
Listing 5-1Create a resource group for the AKS cluster
如果资源组创建成功，您应该会看到以下输出。
- 使用
az aks create命令创建 AKS 集群。下面的示例创建了一个名为 jcbaksclu02 的集群，该集群有一个节点，--enable-addons monitoring参数将为该集群启用 Azure Monitor for containers。几分钟后，一旦集群创建完成，Azure CLI 将在 Azure Cloud Shell 窗口中返回 JSON 格式的集群信息。
{
"id": "/subscriptions/<guid>/jcbaskrg01",
"location": "eastus",
"managedBy": null,
"name": "jcbaskrg02",
"properties": {
"provisioningState": "Succeeded"
},
"tags": null,
"type": "Microsoft.Resources/resourceGroups"
}
Listing 5-2Create a resource group output
az aks create --resource-group jcbaksrg01 --name jcbaksclu01 --node-count 1 --enable-addons monitoring --generate-ssh-keys
Listing 5-3Create an AKS cluster
通过 Azure 资源管理器模板进行部署
Azure 资源管理器(ARM)模板引入了基础设施作为 Azure 部署的代码功能。ARM 模板是定义 Azure 部署的基础设施和配置的 JavaScript 对象符号(JSON)文件。ARM 模板使用声明性语法，您可以通过使用 ARM 模板指定要部署的资源及其各自的配置。
在使用 ARM 模板创建 AKS 集群之前，您需要首先提供一个 SSH 公钥和 Azure Active Directory 服务主体。
创建一个 SSH 密钥对
连接和访问 AKS 节点需要 SSH 密钥对。根据下面的例子，通过在 Azure Cloud Shell 会话中执行ssh-keygen命令，您将在~/中生成一个带有 2048 位长度的 RSA 加密的 SSH 公共和私有密钥对。Azure 云外壳文件存储中的 ssh 目录。
ssh-keygen -t rsa -b 2048
Listing 5-4Create an SSH key pair in Azure Cloud Shell
创建服务主体
Azure Active Directory 服务主体名称(SPN)是允许 AKS 群集与 Azure 环境中的其他 Azure 资源进行交互所必需的。通过执行az ad sp create-for-rbac CLI 命令，您可以为这个练习创建必要的服务主体。--skip-assignment参数防止分配任何额外的权限。默认情况下，此服务主体仅在一年内有效。
az ad sp create-for-rbac --skip-assignment
Listing 5-5Create a service principal in Azure Cloud Shell
从生成的输出中记下 appId 和密码的值。这些是在 ARM 模板中填充参数所必需的。
{
"appId": "141b2bef-9350-4e80-a0fa-a6aa456750a9",
"displayName": "azure-cli-2019-09-30-01-39-37",
"name": "http://azure-cli-2019-09-30-01-39-37",
"password": "182bb4e7-b53f-4cc4-811d-c72ba828a75d",
"tenant": "<tenant id>"
}
Listing 5-6JSON output of the create service principal operation
使用 Azure 资源管理器快速入门模板
如果你不是 ARM 模板方面的专家，你总是可以利用 Azure Resource Manager QuickStart 模板来开始。
注意
在这个例子中，我们将使用 101-aks 快速入门模板来解释使用 Azure 资源管理器模板部署 aks 集群的过程。有关更多示例，请访问以下 URL:
https://azure.microsoft.com/en-au/resources/templates/?term=Azure%20Kubernetes%20Service
-
导航到以下 URL 以打开 101-aks 快速入门模板，然后单击部署到 Azure :
https://azure.microsoft.com/en-au/resources/templates/101-aks/
图 5-7
Azure 快速入门模板 101-aks
-
在模板中输入和/或配置以下值:
-
订阅:选择想要部署 AKS 集群的 Azure 订阅。
-
资源组:您可以选择一个已有的资源组，也可以选择新建提供一个唯一的名称来创建一个新的资源组，点击确定。
-
位置:为你的 AKS 集群选择 Azure 区域。
-
集群名称:为 AKS 集群提供一个唯一的名称。
-
DNS 前缀:为您的集群提供一个唯一的 DNS 前缀。
-
Linux 管理员用户名:提供使用 SSH 连接的用户名。
-
SSH RSA 公钥:输入您的 SSH 密钥对的公共部分(默认为的内容)~/。ssh/id_rsa.pub 。
-
服务主体客户端 ID :提供上一节生成的 appId 值。
-
服务主客户端秘密:提供前面生成的密码。
-
Click the I agree to the terms and conditions stated above: checkbox to agree to the terms and conditions.
 图 5-8 101-aks 快速入门模板的部署屏幕 -
-
点击购买。您的 AKS 集群部署将需要几分钟才能完成。
注意
您可以使用编辑模板或编辑参数按钮定制手臂模板或编辑快速入门模板中提供的参数。
通过地形部署
Terraform 是一个基础设施即代码(IaC)工具，旨在安全高效地构建、更改和版本化基础设施。terra form 中的配置文件定义了运行应用所需的组件。在 Terraform 中生成一个执行计划来描述达到所需配置状态的指令，然后执行它来构建所描述的基础设施。如果配置发生变化，Terraform 能够确定变化并创建增量执行计划，然后应用这些计划。
使用 Terraform 创建 AKS 集群的步骤在( https://docs.microsoft.com/en-us/azure/terraform/terraform-create-k8s-cluster-with-tf-and-aks )中有很好的记录。
注意
Terraform 默认预装在 Azure 云壳中。如果您需要在本地设置 Terraform 以遵循前一篇文章中的说明，请参考以下 URL:
连接到您的 AKS 集群
您可以使用 Kubernetes 命令行客户端kubectl来管理您的 AKS 集群。如果你使用的是 Azure 云壳，那么kubectl是预装的。如果你想在你的本地计算机(已经安装了 Azure CLI 的地方)上本地安装kubectl，你可以使用下面的命令。
az aks install-cli
Listing 5-7Installing kubectl on a local installation of Azure CLI
通过使用az aks get-credentials命令，您可以配置 kubectl 来连接到您的 Kubernetes 集群。这会下载所需的凭证并配置 Kubernetes CLI 来使用它们。
az aks get-credentials --resource-group jcbaksrg01 --name jcbaksclu01
Listing 5-8az aks get-credentials command
然后，您可以执行kubectl get命令来验证到您的集群的连接，并查看它是否返回集群节点列表。
kubectl get nodes
Listing 5-9kubectl get command
以下是示例输出，显示了通过前面的方法创建的 Kubernetes 集群 jcbaksclu01 中的节点。在将任何应用部署到 AKS 集群之前，所有节点的状态都应该是就绪。
NAME STATUS ROLES AGE VERSION
aks-agentpool-26412741-0 Ready agent 120m v1.13.10
Listing 5-10kubectl get command output for jcbaksclu01
摘要
您可以使用几种方法部署 Azure Kubernetes 服务。正如本章前面所解释的，由您来决定哪种方法适合您的部署需求。本章介绍了如何部署 AKS 和配置启动和运行 AKS 集群所需的基本参数。
在本章中，你学习了如何使用四种不同的方法创建 AKS 集群，通过 Azure 门户、Azure CLI(通过本地安装的实例或通过 Azure 云外壳)、Azure 资源管理器模板，以及最后一个非常流行的第三方基础设施即代码工具“Terraform”我们回顾了使用上述每种方法对您的 AK 进行初始配置的过程。最后，我们简要讨论了如何使用 Kubernetes 的命令行工具kubectl连接到 AKS 集群。
六、通过 Azure Kubernetes 服务部署和使用 Rancher
随着您继续进入容器世界，您将到达临界质量点。将需要运行一个编排平台来处理容器的生命周期。在第三章“Kubernetes 内部”，我们进入了 Kubernetes，最常见的编排平台。在第五章中，“部署 Azure Kubernetes 服务”，我们介绍了如何部署 Azure Kubernetes 服务(AKS)。Kubernetes 对于刚开始使用容器编排平台的人来说可能很复杂。
微软的托管 Kubernetes 服务 AKS 消除了运行 Kubernetes 集群的一些复杂性；然而，运行 Kubernetes 集群仍然是一个挑战，包括随之而来的所有事情，例如操作多个 Kubernetes 集群、在集群中扩展、联网、RBAC、监控、通过 HELM charts 部署捆绑解决方案(将在后面的章节中介绍)等等。市场上有第三方解决方案可以降低运行 Kubernetes 的复杂性。牧场主是这个解决方案之一，如果不是最好的。
在这一章，我们将给出一个 Rancher 的概述，也将探讨 Rancher 如何与 AK 一起使用。
什么是牧场主？
简而言之，Rancher 是一个开源解决方案，可以用来部署和操作一个或多个 Kubernetes 集群。Rancher 可以跨内部或云提供商(如 AWS、GCP、数字海洋和 Azure)部署和管理 Kubernetes 集群。它可以用于在您自己的基础设施上部署和管理您自己的 Kubernetes 集群，甚至是来自云提供商的托管集群服务，例如 Azure Kubernetes 服务。
不像市场上的其他开源解决方案，Rancher 是完全免费的。它没有需要付费的社区版和企业版。使用 Rancher，您可以在部署时获得所有功能。牧场主在经济上支持自己的方式是通过为生产牧场主的组织设计的有偿支持选项。
因为 Rancher 几乎可以在任何地方操作 Kubernetes 集群，所以它还可以用来在提供者之间迁移资源。
Rancher 总体上有助于简化 Kubernetes 的管理。它简化管理的一些方法是集中身份验证和访问控制，通过 Prometheus 和 Grafana 引入开箱即用的监控，拥有自己的应用库，以及 HELM charts 和简化的 Kubernetes 版本升级。
虽然 Rancher 抽象了管理 Kubernetes 集群的大部分复杂性，但如果需要，它也允许高级管理。例如，Kubernetes 管理员可以通过 Rancher 门户访问 kubectl。
为什么使用牧场主与库伯内特？
当有人了解 Rancher 时，最常见的问题之一是:“为什么我应该将 Rancher 与 Kubernetes 一起使用，而不是单独使用 Kubernetes？”这个问题的答案是有很多理由使用牧场主与库伯内特；但是，在某些情况下，使用 Rancher 可能没有意义。这里我们将看看使用 Rancher 的理由。让我们浏览一下:
-
Kubernetes 集群的部署和升级:通过 Rancher 部署和升级 Kubernetes 集群是一个简化且无缝的过程。
-
用户界面和 API:Rancher 为使用 Kubernetes 的用户提供了一个简化的用户界面。Rancher 还提供了一个接口 API。
-
集中管理多个 Kubernetes 集群:许多组织正在采用多种云方法，因此他们可能会跨多个云提供商运行一个 Kubernetes 集群。当 Kubernetes 集群跨云提供商甚至在本地部署时，可以使用 Rancher 从一个地方集中管理所有集群。Rancher 集中管理 RBAC、安全策略管理、容量管理、委托管理、集群备份和恢复、日志记录和监控等。
-
集中和简化 Kubernetes 的 RBAC:Kubernetes 的授权和访问可以从 Rancher 轻松管理。
-
Rancher 和 Prometheus 和 Grafana 一起从箱子里出来:监控 Kubernetes 是至关重要的。Prometheus 和 Grafana 是常见的监控和可视化工具。由于这些解决方案与 Rancher 打包在一起，可以随时监控 Kubernetes，因此减少了部署这些解决方案并准备好监控 Kubernetes 的工作负载。
-
Rancher 简化 Helm 图 : Rancher 允许你加载 Helm 图库和/或 Rancher 库。这些库使得轻松地部署应用成为可能。
-
Kubernetes 采用:通过降低 Kubernetes 的学习曲线，让程序员专注于开发应用而不是运行应用，来推动 Kubernetes 的采用。
从前面的列表中可以看出，将 Rancher 与 Kubernetes 结合使用有很多价值。接下来，让我们看看如何部署 Rancher 并将其与 AKS 一起使用。
如何在 Azure 上部署 Rancher
Rancher 作为 Docker 顶部的容器运行。您可以在本地或云提供商上部署 Rancher。在这一节中，我们将在一个运行 Docker 的 Ubuntu 服务器上部署 Rancher。
我们将使用 Azure ARM 模板部署这个 VM 和 Rancher。我们将使用的 ARM 模板使用 Docker 和最新版本的 Rancher 作为容器来部署 Ubuntu VM。Rancher 容器从 Docker Hub 上的( https://hub.docker.com/r/rancher/rancher )部署。这确保了总是部署最新的 Rancher 版本。
我们将使用的 ARM 模板名为 RancherNode.JSON。下面是 ARM 模板代码:
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"adminUsername": {
"type": "string",
"metadata": {
"description": "Username for the Rancher Node Virtual Machine."
}
},
"adminPassword": {
"type": "securestring",
"metadata": {
"description": "Password for the Rancher Node Virtual Machine."
}
},
"dnsNameForPublicIP": {
"type": "string",
"metadata": {
"description": "Unique DNS Name for the Public IP used to access the Rancher Portal."
}
},
"vmSize": {
"type": "string",
"defaultValue": "Standard_F1",
"metadata": {
"description": "VM size for the Rancher Node."
}
},
"ubuntuOSVersion": {
"type": "string",
"defaultValue": "14.04.4-LTS",
"metadata": {
"description": "The Ubuntu version for deploying the Docker containers. This will pick a fully patched image of this given Ubuntu version. Allowed values: 14.04.4-LTS, 15.10, 16.04.0-LTS"
},
"allowedValues": [
"14.04.4-LTS",
"15.10",
"16.04.0-LTS"
]
},
"location": {
"type": "string",
"defaultValue": "[resourceGroup().location]",
"metadata": {
"description": "Location for all resources."
}
}
},
"variables": {
"imagePublisher": "Canonical",
"imageOffer": "UbuntuServer",
"nicName": "RancherNodeNic",
"extensionName": "DockerExtension",
"addressPrefix": "10.0.0.0/16",
"subnetName": "RancherSubnet",
"subnetPrefix": "10.0.0.0/24",
"diskStorageType": "Standard_LRS",
"publicIPAddressName": "RancherNodePublicIP",
"publicIPAddressType": "Dynamic",
"vmName": "RancherNode",
"virtualNetworkName": "RancherVNet",
"subnetRef": "[resourceId('Microsoft.Network/virtualNetworks/subnets', variables('virtualNetworkName'), variables('subnetName'))]"
},
"resources": [
{
"apiVersion": "2017-04-01",
"type": "Microsoft.Network/publicIPAddresses",
"name": "[variables('publicIPAddressName')]",
"location": "[parameters('location')]",
"properties": {
"publicIPAllocationMethod": "[variables('publicIPAddressType')]",
"dnsSettings": {
"domainNameLabel": "[parameters('dnsNameForPublicIP')]"
}
}
},
{
"apiVersion": "2017-04-01",
"type": "Microsoft.Network/virtualNetworks",
"name": "[variables('virtualNetworkName')]",
"location": "[parameters('location')]",
"properties": {
"addressSpace": {
"addressPrefixes": [
"[variables('addressPrefix')]"
]
},
"subnets": [
{
"name": "[variables('subnetName')]",
"properties": {
"addressPrefix": "[variables('subnetPrefix')]"
}
}
]
}
},
{
"apiVersion": "2017-04-01",
"type": "Microsoft.Network/networkInterfaces",
"name": "[variables('nicName')]",
"location": "[parameters('location')]",
"dependsOn": [
"[concat('Microsoft.Network/publicIPAddresses/', variables('publicIPAddressName'))]",
"[concat('Microsoft.Network/virtualNetworks/', variables('virtualNetworkName'))]"
],
"properties": {
"ipConfigurations": [
{
"name": "ipconfig1",
"properties": {
"privateIPAllocationMethod": "Dynamic",
"publicIPAddress": {
"id": "[resourceId('Microsoft.Network/publicIPAddresses',variables('publicIPAddressName'))]"
},
"subnet": {
"id": "[variables('subnetRef')]"
}
}
}
]
}
},
{
"apiVersion": "2017-03-30",
"type": "Microsoft.Compute/virtualMachines",
"name": "[variables('vmName')]",
"location": "[parameters('location')]",
"dependsOn": [
"[concat('Microsoft.Network/networkInterfaces/', variables('nicName'))]"
],
"properties": {
"hardwareProfile": {
"vmSize": "[parameters('vmSize')]"
},
"osProfile": {
"computerName": "[variables('vmName')]",
"adminUsername": "[parameters('adminUsername')]",
"adminPassword": "[parameters('adminPassword')]"
},
"storageProfile": {
"imageReference": {
"publisher": "[variables('imagePublisher')]",
"offer": "[variables('imageOffer')]",
"sku": "[parameters('ubuntuOSVersion')]",
"version": "latest"
},
"osDisk": {
"name": "[concat(variables('vmName'),'_OSDisk')]",
"caching": "ReadWrite",
"createOption": "FromImage",
"managedDisk": {
"storageAccountType": "[variables('diskStorageType')]"
}
}
},
"networkProfile": {
"networkInterfaces": [
{
"id": "[resourceId('Microsoft.Network/networkInterfaces',variables('nicName'))]"
}
]
}
}
},
{
"type": "Microsoft.Compute/virtualMachines/extensions",
"name": "[concat(variables('vmName'),'/', variables('extensionName'))]",
"apiVersion": "2017-03-30",
"location": "[parameters('location')]",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', variables('vmName'))]"
],
"properties": {
"publisher": "Microsoft.Azure.Extensions",
"type": "DockerExtension",
"typeHandlerVersion": "1.0",
"autoUpgradeMinorVersion": true,
"settings": {
"compose": {
"rancher": {
"image": "rancher/rancher:stable",
"ports": [
"80:80",
"443:443"
],
"volumes": [
"/opt/rancher:/var/lib/rancher"
]
}
}
}
}
}
]
}
这个 ARM 模板也可以在这里下载: https://github.com/Buchatech/DeployRanchertoAzure 。
使用您选择的部署选项部署 ARM 模板。您需要提供以下参数的数据:
-
签署
-
资源组
-
位置
-
管理员用户名
-
管理员密码
-
公共 IP 的 Dns 名称
-
虚拟机大小
-
Ubuntu OS 版本
部署 Ubuntu VM 后，您应该会看到新资源组中的资源，如表 6-1 所示。
表 6-1
资源组中蓝色资源上的牧场主
|名字
|
类型
|
| — | — |
| 兰彻网 | 虚拟网络 |
| 牧场主 | 虚拟计算机 |
| 兰彻诺尔德 PublicIP | 公共 IP 地址 |
| 蓝丘杜鹃 | 网络接口 |
| 兰彻罗德 _OSDisk | 唱片 |
为了完成 Rancher 部署，您需要通过 Rancher 门户完成设置。URL 是我们部署的 Rancher 节点 VM 的 DNS 名称。您可以通过在概述页面上的 Azure 门户中单击 Rancher 节点 VM 来找到 DNS 名称。以下是 URL 的一个示例:
https://NAMEOFTHEVM.centralus.cloudapp.azure.com
牧场主门户网站会提示您设置密码。如图 6-1 所示。
图 6-1
牧场主设置密码
设置密码后，Rancher 门户会提示您输入正确的 Rancher 服务器 URL。这将自动成为如图 6-2 所示的牧场主节点虚拟机 DNS 名称。单击保存 URL。
图 6-2
蓝丘保存 URL
然后，您将直接登录到 Rancher 门户的“您将看到集群”页面。这就完成了在 Azure 上部署 Rancher 的部署。接下来，我们将探索部署一个新的 AKS 集群，并从 Rancher 内部连接到一个现有的 AKS 集群。
使用 Azure Active Directory 对牧场主进行身份验证
您将需要从 Rancher 到 Azure working 的认证，然后才能部署或管理现有的 AKS 集群。为了从 Rancher 向 Azure 进行身份验证，您将需要 Azure Active Directory 中的服务主体名称(SPN)对象。这将用于 Azure 的身份验证。
要创建这个 SPN，您只需要运行一行语法。建议您在 Azure Cloud Shell 中从 Bash 运行这个。
注意
使用以下步骤在 Azure Cloud Shell 中打开 Bash:
登录 Azure 门户网站。
通过点击➤.从顶部导航启动云壳
如果这是您第一次运行云外壳，请选择订阅以创建存储帐户和 Microsoft Azure 文件共享。
当 Cloud Shell 在 Azure 门户底部启动时，确保 Shell 窗口左侧的环境下拉菜单显示的是 Bash 而不是 PowerShell。
占位符文本。稍后在能够清理便笺格式时删除。
注意
您将需要想要在其中创建 AKS 集群的订阅的订阅 ID。您可以在 Cloud Shell 中运行以下语法来获取您登录的帐户的订阅列表。这将列出包括 id 在内的订阅属性信息。复制订阅 ID 以备后用。
az account list
使用以下语法创建具有特定名称的 SPN，并将参与者角色分配给指定的订阅:
az ad sp create-for-rbac --name NAMEOFTHESPNHERE --role contributor --scopes /subscriptions/SUBSCRIPTIONIDHERE
例如:
az ad sp create-for-rbac --name rancherSPN --role contributor --scopes /subscriptions/148727f76-9q1b-4941-coa6-92c5d153fe73
输出将类似于:
将“rancherSPN”更改为“ http://rancherSPN ”的有效 URI，这是用于服务主体名称的必需格式
Retrying role assignment creation: 1/36
{
"appId": "012d8611-c9a3-4e90-80d9-ad6504c823g8",
"displayName": " rancherSPN ",
"name": "http:// rancherSPN",
"password": "6a4b83fc-31qa-40f0-c4c6-rba8c5av460b",
"tenant": "0pw0cc24-q010-4f7b-h08e-9o57a72t531d"
}
请记住将这些信息复制到某个地方，因为在创建 AKS 集群时，您将需要这些信息从 Rancher 连接到 Azure。
注意
appId 将用于 Rancher 中的 clientId 字段。
就是这样！这就是创建 SPN 并从 Rancher 获得向 Azure 认证所需的信息所要做的全部工作。在下一节中，我们将从 Rancher 创建一个新的 AKS 集群。
与牧场主一起部署 AK 步枪
此时，我们已经在 Azure 上部署了 Rancher。现在让我们看看使用 Rancher 部署新的 AKS 集群的过程。使用以下步骤在 Azure 中从 Rancher 部署新的 AKS。
注意
在下面的步骤中，我们将调用所需的设置，如 DNS 前缀，但不调用可选设置，如 Azure 标记或高级网络。在部署 AKS 集群时，您可以根据需要配置可选设置。
在 Rancher 门户中，单击顶部导航菜单中的集群。
点击添加集群，选择 Azure AKS，如图 6-3 所示。
图 6-3
Azure AKS 托管 Kubernetes 提供商
您将看到如图 6-4 所示的账户访问设置。
图 6-4
帐户访问设置
输入一个集群名称，如图 6-5 所示。
图 6-5
牧场主群集名称
创建 SPN 后，将您从上一部分复制的信息输入到帐户访问设置中。
单击下一步:验证和配置节点。
接下来，在集群选项下，给你的集群一个 DNS 前缀，如图 6-6 所示。
图 6-6
群集 DNS 前缀
在节点下，在集群资源组字段中输入资源组的名称，如图 6-7 所示。
图 6-7
集群资源组和 SSH 密钥
此外，在 Nodes 下，输入 SSH 公钥并单击 Create。
注意
PuTTY Key Generator 是一个免费的工具，可以用来生成一个新的 SSH 密钥。你可以在这里下载: www.puttygen.com 。
AKS 集群将开始供应，如图 6-8 所示。
图 6-8
AKS 集群配置
部署 AKS 集群后，它将在 Rancher 门户中显示为活动的。AKS 集群现已部署，您可以访问 Azure 门户，导航到它创建的资源组，并查看部署的资源管理器，包括 AKS 集群、日志分析工作区和 Containers Insights 解决方案，如图 6-9 所示。
图 6-9
Azure 上的 AKS 集群资源
回到 Rancher 门户，您现在可以单击 AKS 集群来访问仪表板、监控和集群设置，从 Rancher 或 Helm 目录安装应用，启动 Kubectl 等。图 6-10 是 Rancher 中 AKS 集群的仪表板示例。
图 6-10
牧场主的 AKS 集群仪表板
下面两个屏幕截图展示了 Rancher 中针对 AKS 集群的 Grafana 监控。图 6-11 显示了实时集群指标。
图 6-11
牧场主的 Grafana 聚类度量
图 6-12 显示了集群和 Kubernetes 组件的实时指标。
图 6-12
Grafana Kubernetes 牧场主的组件度量
您还可以访问完整的 Grafana UI 和系统，以更深入地了解您的 AKS 集群及其资源，如图 6-13 所示的节点和单元。
图 6-13
格拉凡·ui
摘要
这就把我们带到了本章的结尾。Rancher 不像 Docker 和 Kubernetes 那样出名。然而，正如您在本章中了解到的，Rancher 是简化 Kubernetes 生命周期的一个有用的解决方案。具体来说，在这一章中，我们介绍了什么是 Rancher，为什么您将它与 Kubernetes 一起使用，在 Azure 上部署 Rancher，最后将 Rancher 连接到 Azure，以便您可以部署新的 AKS 集群。
扫一扫
1199
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
