介绍

想在笔记本电脑上尝试 MongoDB？只需执行一个命令，你就会有一个轻量级的、独立的沙箱。完成后可以删除你所做的所有痕迹。

想在多个环境中使用相同的 程序栈 application stack 副本？构建你自己的容器镜像，让你的开发、测试、运维和支持团队使用相同的环境克隆。

容器正在彻底改变整个软件生命周期：从最早的技术性实验和概念证明，贯穿了开发、测试、部署和支持。

编排工具用来管理如何创建、升级多个容器，并使之高可用。编排还控制容器如何连接，以从多个微服务容器构建复杂的应用程序。

丰富的功能、简单的工具和强大的 API 使容器和编排功能成为 DevOps 团队的首选，将其集成到连续集成（CI） 和连续交付 （CD） 的工作流程中。

这篇文章探讨了在容器中运行和编排 MongoDB 时遇到的额外挑战，并说明了如何克服这些挑战。

MongoDB 的注意事项

使用容器和编排运行 MongoDB 有一些额外的注意事项：

• MongoDB 数据库节点是有状态的。如果容器发生故障并被重新编排，数据则会丢失（能够从副本集的其他节点恢复，但这需要时间），这是不合需要的。为了解决这个问题，可以使用诸如 Kubernetes 中的 数据卷 volume 抽象等功能来将容器中临时的 MongoDB 数据目录映射到持久位置，以便数据在容器故障和重新编排过程中存留。
• 一个副本集中的 MongoDB 数据库节点必须能够相互通信 - 包括重新编排后。副本集中的所有节点必须知道其所有对等节点的地址，但是当重新编排容器时，可能会使用不同的 IP 地址重新启动。例如，Kubernetes Pod 中的所有容器共享一个 IP 地址，当重新编排 pod 时，IP 地址会发生变化。使用 Kubernetes，可以通过将 Kubernetes 服务与每个 MongoDB 节点相关联来处理，该节点使用 Kubernetes DNS 服务提供“主机名”，以保持服务在重新编排中保持不变。
• 一旦每个单独的 MongoDB 节点运行起来（每个都在自己的容器中），则必须初始化副本集，并添加每个节点到其中。这可能需要在编排工具之外提供一些额外的处理。具体来说，必须使用目标副本集中的一个 MongoDB 节点来执行 rs.initiate 和 rs.add 命令。
• 如果编排框架提供了容器的自动化重新编排（如 Kubernetes），那么这将增加 MongoDB 的弹性，因为这可以自动重新创建失败的副本集成员，从而在没有人为干预的情况下恢复完全的冗余级别。
• 应该注意的是，虽然编排框架可能监控容器的状态，但是不太可能监视容器内运行的应用程序或备份其数据。这意味着使用 MongoDB Enterprise Advanced 和 MongoDB Professional 中包含的 MongoDB Cloud Manager 等强大的监控和备份解决方案非常重要。可以考虑创建自己的镜像，其中包含你首选的 MongoDB 版本和 MongoDB Automation Agent。

使用 Docker 和 Kubernetes 实现 MongoDB 副本集

如上节所述，分布式数据库（如 MongoDB）在使用编排框架（如 Kubernetes）进行部署时，需要稍加注意。本节将介绍详细介绍如何实现。

我们首先在单个 Kubernetes 集群中创建整个 MongoDB 副本集（通常在一个数据中心内，这显然不能提供地理冗余）。实际上，很少有必要改变成跨多个集群运行，这些步骤将在后面描述。

副本集的每个成员将作为自己的 pod 运行，并提供一个公开 IP 地址和端口的服务。这个“固定”的 IP 地址非常重要，因为外部应用程序和其他副本集成员都可以依赖于它在重新编排 pod 的情况下保持不变。

下图说明了其中一个 pod 以及相关的复制控制器和服务。

图 1：MongoDB 副本集成员被配置为 Kubernetes Pod 并作为服务公开

逐步介绍该配置中描述的资源：

• 从核心开始，有一个名为 mongo-node1 的容器。mongo-node1 包含一个名为 mongo 的镜像，这是一个在 Docker Hub 上托管的一个公开可用的 MongoDB 容器镜像。容器在集群中暴露端口 27107。
• Kubernetes 的数据卷功能用于将连接器中的 /data/db 目录映射到名为 mongo-persistent-storage1 的永久存储上，这又被映射到在 Google Cloud 中创建的名为 mongodb-disk1 的磁盘中。这是 MongoDB 存储其数据的地方，这样它可以在容器重新编排后保留。
• 容器保存在一个 pod 中，该 pod 中有标签命名为 mongo-node，并提供一个名为 rod 的（任意）示例。
• 配置 mongo-node1 复制控制器以确保 mongo-node1 pod 的单个实例始终运行。
• 名为 mongo-svc-a 的 负载均衡 服务给外部开放了一个 IP 地址以及 27017 端口，它被映射到容器相同的端口号上。该服务使用选择器来匹配 pod 标签来确定正确的 pod。外部 IP 地址和端口将用于应用程序以及副本集成员之间的通信。每个容器也有本地 IP 地址，但是当容器移动或重新启动时，这些 IP 地址会变化，因此不会用于副本集。

下一个图显示了副本集的第二个成员的配置。

图 2：第二个 MongoDB 副本集成员配置为 Kubernetes Pod

90％ 的配置是一样的，只有这些变化：

• 磁盘和卷名必须是唯一的，因此使用的是 mongodb-disk2 和 mongo-persistent-storage2
• Pod 被分配了一个 instance: jane 和 name: mongo-node2 的标签，以便新的服务可以使用选择器与图 1 所示的 rod Pod 相区分。
• 复制控制器命名为 mongo-rc2
• 该服务名为mongo-svc-b，并获得了一个唯一的外部 IP 地址（在这种情况下，Kubernetes 分配了 104.1.4.5）

第三个副本成员的配置遵循相同的模式，下图展示了完整的副本集：

图 3：配置为 Kubernetes 服务的完整副本集成员

请注意，即使在三个或更多节点的 Kubernetes 群集上运行图 3 所示的配置，Kubernetes 可能（并且经常会）在同一主机上编排两个或多个 MongoDB 副本集成员。这是因为 Kubernetes 将三个 pod 视为属于三个独立的服务。

为了在区域内增加冗余，可以创建一个附加的 headless 服务。新服务不向外界提供任何功能（甚至不会有 IP 地址），但是它可以让 Kubernetes 通知三个 MongoDB pod 形成一个服务，所以 Kubernetes 会尝试在不同的节点上编排它们。

图 4：避免同一 MongoDB 副本集成员的 Headless 服务

配置和启动 MongoDB 副本集所需的实际配置文件和命令可以在白皮书《启用微服务：阐述容器和编排》中找到。特别的是，需要一些本文中描述的特殊步骤来将三个 MongoDB 实例组合成具备功能的、健壮的副本集。

多个可用区 MongoDB 副本集

上面创建的副本集存在风险，因为所有内容都在相同的 GCE 集群中运行，因此都在相同的 可用区 availability zone 中。如果有一个重大事件使可用区离线，那么 MongoDB 副本集将不可用。如果需要地理冗余，则三个 pod 应该在三个不同的可用区或地区中运行。

令人惊奇的是，为了创建在三个区域之间分割的类似的副本集（需要三个集群），几乎不需要改变。每个集群都需要自己的 Kubernetes YAML 文件，该文件仅为该副本集中的一个成员定义了 pod、复制控制器和服务。那么为每个区域创建一个集群，永久存储和 MongoDB 节点是一件很简单的事情。

图 5：在多个可用区域上运行的副本集

下一步

要了解有关容器和编排的更多信息 - 所涉及的技术和所提供的业务优势 - 请阅读白皮书《启用微服务：阐述容器和编排》。该文件提供了获取本文中描述的副本集，并在 Google Container Engine 中的 Docker 和 Kubernetes 上运行的完整的说明。

作者简介：

Andrew 是 MongoDB 的产品营销总经理。他在去年夏天离开 Oracle 加入 MongoDB，在 Oracle 他花了 6 年多的时间在产品管理上，专注于高可用性。他可以通过 @andrewmorgan 或者在他的博客（clusterdb.com）评论联系他。

via: https://www.mongodb.com/blog/post/running-mongodb-as-a-microservice-with-docker-and-kubernetes

作者：Andrew Morgan 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

Kubernetes，简称 k8s（k，8 个字符，s——明白了？）或者 “kube”，是一个开源的 Linux 容器自动化运维平台，它消除了容器化应用程序在部署、伸缩时涉及到的许多手动操作。换句话说，你可以将多台主机组合成集群来运行 Linux 容器，而 Kubernetes 可以帮助你简单高效地管理那些集群。构成这些集群的主机还可以跨越公有云、私有云以及混合云。

Kubernetes 最开始是由 Google 的工程师设计开发的。Google 作为 Linux 容器技术的早期贡献者之一，曾公开演讲介绍 Google 如何将一切都运行于容器之中（这是 Google 的云服务背后的技术）。Google 一周内的容器部署超过 20 亿次，全部的工作都由内部平台 Borg 支撑。Borg 是 Kubernetes 的前身，几年来开发 Borg 的经验教训也成了影响 Kubernetes 中许多技术的主要因素。

趣闻: Kubernetes logo 中的七个辐条来源于项目原先的名称, “Seven of Nine 项目”（LCTT 译注：Borg 是「星际迷航」中的一个宇宙种族，Seven of Nine 是该种族的一名女性角色）。

红帽作为最早与 Google 合作开发 Kubernetes 的公司之一（甚至早于 Kubernetes 的发行），已经是 Kubernetes 上游项目的第二大贡献者。Google 在 2015 年把 Kubernetes 项目捐献给了新成立的 云计算基金会 Cloud Native Computing Foundation （CNCF）。

为什么你需要 Kubernetes ？

真实的生产环境应用会包含多个容器，而这些容器还很可能会跨越多个服务器主机部署。Kubernetes 提供了为那些工作负载大规模部署容器的编排与管理能力。Kubernetes 编排让你能够构建多容器的应用服务，在集群上调度或伸缩这些容器，以及管理它们随时间变化的健康状态。

Kubernetes 也需要与网络、存储、安全、监控等其它服务集成才能提供综合性的容器基础设施。

当然，这取决于你如何在你的环境中使用容器。一个初步的 Linux 容器应用程序把容器视作高效、快速的虚拟机。一旦把它部署到生产环境或者扩展为多个应用，很显然你需要许多组托管在相同位置的容器合作提供某个单一的服务。随着这些容器的累积，你的运行环境中容器的数量会急剧增加，复杂度也随之增长。

Kubernetes 通过将容器分类组成 “pod” 来解决了容器增殖带来的许多常见问题。pod 为容器分组提供了一层抽象，以此协助你调度工作负载以及为这些容器提供类似网络与存储这类必要的服务。Kubernetes 的其它组件帮助你对 pod 进行负载均衡，以保证有合适数量的容器支撑你的工作负载。

正确实施的 Kubernetes，结合类似 Atomic Registry、Open vSwitch、heapster、OAuth 和 SELinux 的开源项目，让你可以管理你自己的整个容器基础设施。

Kubernetes 能做些什么？

在生产环境中使用 Kubernetes 的主要优势在于它提供了在物理机或虚拟机集群上调度和运行容器的平台。更宽泛地说，它能帮你在生产环境中实现可以依赖的基于容器的基础设施。而且，由于 Kubernetes 本质上就是运维任务的自动化平台，你可以执行一些其它应用程序平台或管理系统支持的操作，只不过操作对象变成了容器。

有了 Kubernetes，你可以：

• 跨主机编排容器。
• 更充分地利用硬件资源来最大化地满足企业应用的需求。
• 控制与自动化应用的部署与升级。
• 为有状态的应用程序挂载和添加存储器。
• 线上扩展或裁剪容器化应用程序与它们的资源。
• 声明式的容器管理，保证所部署的应用按照我们部署的方式运作。
• 通过自动布局、自动重启、自动复制、自动伸缩实现应用的状态检查与自我修复。

然而 Kubernetes 依赖其它项目来提供完整的编排服务。结合其它开源项目作为其组件，你才能充分感受到 Kubernetes 的能力。这些必要组件包括：

• 仓库：Atomic Registry、Docker Registry 等。
• 网络：OpenvSwitch 和智能边缘路由等。
• 监控：heapster、kibana、hawkular 和 elastic。
• 安全：LDAP、SELinux、 RBAC 与 支持多租户的 OAUTH。
• 自动化：通过 Ansible 的 playbook 进行集群的安装和生命周期管理。
• 服务：大量事先创建好的常用应用模板。

红帽 OpenShift 为容器部署预先集成了上面这些组件。

Kubernetes 入门

和其它技术一样，大量的专有名词有可能成为入门的障碍。下面解释一些通用的术语，希望帮助你理解 Kubernetes。

• Master（主节点）： 控制 Kubernetes 节点的机器，也是创建作业任务的地方。
• Node（节点）： 这些机器在 Kubernetes 主节点的控制下执行被分配的任务。
• Pod： 由一个或多个容器构成的集合，作为一个整体被部署到一个单一节点。同一个 pod 中的容器共享 IP 地址、进程间通讯（IPC）、主机名以及其它资源。Pod 将底层容器的网络和存储抽象出来，使得集群内的容器迁移更为便捷。
• Replication controller（复制控制器）： 控制一个 pod 在集群上运行的实例数量。
• Service（服务）： 将服务内容与具体的 pod 分离。Kubernetes 服务代理负责自动将服务请求分发到正确的 pod 处，不管 pod 移动到集群中的什么位置，甚至可以被替换掉。
• Kubelet： 这个守护进程运行在各个工作节点上，负责获取容器列表，保证被声明的容器已经启动并且正常运行。
• kubectl： 这是 Kubernetes 的命令行配置工具。

上面这些知识就足够了吗？不，这仅仅是一小部分，更多内容请查看 Kubernetes 术语表。

生产环境中使用 Kubernetes

Kubernetes 是开源的，所以没有正式的技术支持机构为你的商业业务提供支持。如果在生产环境使用 Kubernetes 时遇到问题，你恐怕不会太愉快，当然你的客户也不会太高兴。

这就是红帽 OpenShift 要解决的问题。OpenShift 是为企业提供的 Kubernetes ——并且集成了更多的组件。OpenShift 包含了强化 Kubernetes 功能、使其更适用于企业场景的额外部件，包括仓库、网络、监控、安全、自动化和服务在内。OpenShift 使得开发者能够在具有伸缩性、控制和编排能力的云端开发、托管和部署容器化的应用，快速便捷地把想法转变为业务。

而且，OpenShift 还是由头号开源领导公司红帽支持和开发的。

Kubernetes 如何适用于你的基础设施

Kubernetes 运行在操作系统（例如 Red Hat Enterprise Linux Atomic Host）之上，操作着该节点上运行的容器。Kubernetes 主节点（master）从管理员（或者 DevOps 团队）处接受命令，再把指令转交给附属的节点。这种带有大量服务的切换工作自动决定最适合该任务的节点，然后在该节点上分配资源并指派 pod 来完成任务请求。

所以从基础设施的角度，管理容器的方式发生了一点小小的变化。对容器的控制在更高的层次进行，提供了更佳的控制方式，而无需用户微观管理每个单独的容器或者节点。必要的工作则主要集中在如何指派 Kubernetes 主节点、定义节点和 pod 等问题上。

docker 在 Kubernetes 中的角色

Docker 技术依然执行它原本的任务。当 kubernetes 把 pod 调度到节点上，节点上的 kubelet 会指示 docker 启动特定的容器。接着，kubelet 会通过 docker 持续地收集容器的信息，然后提交到主节点上。Docker 如往常一样拉取容器镜像、启动或停止容器。不同点仅仅在于这是由自动化系统控制而非管理员在每个节点上手动操作的。

via: https://www.redhat.com/en/containers/what-is-kubernetes

作者：www.redhat.com 译者：haoqixu 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

如果你的运维团队在使用 Docker 和 Kubernetes，那么建议开发上采用相同或相似的技术。这将减少不兼容性和可移植性问题的数量，并使每个人都会认识到应用程序容器是开发和运维团队的共同责任。

这篇博客文章介绍了 Kubernetes 在开发模式中的用法，它的灵感来自于一个视频教程，你可以在“无痛 Docker 教程”中找到它。

Minikube 是一个允许开发人员在本地使用和运行 Kubernetes 集群的工具，从而使开发人员的生活变得轻松。

在这篇博客中，对于我测试的例子，我使用的是 Linux Mint 18，但其它 Linux 发行版在安装部分没有区别。

cat /etc/lsb-release 

DISTRIB_ID=LinuxMint
DISTRIB_RELEASE=18.1
DISTRIB_CODENAME=serena
DISTRIB_DESCRIPTION=”Linux Mint 18.1 Serena”

先决条件

为了与 Minkube 一起工作，我们应该安装 Kubectl 和 Minikube 和一些虚拟化驱动程序。

• 对于 OS X，安装 xhyve 驱动、VirtualBox 或者 VMware Fusion，然后再安装 Kubectl 和 Minkube。

curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl

chmod +x ./kubectl

sudo mv ./kubectl /usr/local/bin/kubectl

curl -Lo minikube https://storage.googleapis.com/minikube/releases/v0.21.0/minikube-darwin-amd64 && chmod +x minikube && sudo mv minikube /usr/local/bin/

• 对于 Windows，安装 VirtualBox 或者 Hyper-V，然后再安装 Kubectl 和 Minkube。

curl -LO https://storage.googleapis.com/kubernetes-release/release/v1.7.0/bin/windows/amd64/kubectl.exe

将二进制文件添加到你的 PATH 中（这篇文章解释了如何修改 PATH）

下载 minikube-windows-amd64.exe，将其重命名为 minikube.exe，并将其添加到你的 PATH 中。在这可以找到最新版本。

• 对于 Linux，安装 VirtualBox 或者 KVM，然后再安装 Kubectl 和 Minkube。

curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl

chmod +x ./kubectl

sudo mv ./kubectl /usr/local/bin/kubectl

curl -Lo minikube https://storage.googleapis.com/minikube/releases/v0.21.0/minikube-linux-amd64 && chmod +x minikube && sudo mv minikube /usr/local/bin/

使用 Minikube

我们先从这个 Dockerfile 创建一个镜像：

FROM busybox
ADD index.html /www/index.html
EXPOSE 8000
CMD httpd -p 8000 -h /www; tail -f /dev/null

添加你希望在 index.html 中看到的内容。

构建镜像：

docker build -t eon01/hello-world-web-server .

我们来运行容器来测试它：

docker run -d --name webserver -p 8000:8000 eon01/hello-world-web-server

这是 docker ps 的输出：

docker ps

CONTAINER ID        IMAGE                          COMMAND                  CREATED             STATUS              PORTS                    NAMES
2ad8d688d812        eon01/hello-world-web-server   "/bin/sh -c 'httpd..."   3 seconds ago       Up 2 seconds        0.0.0.0:8000->8000/tcp   webserver

让我们提交镜像并将其上传到公共 Docker Hub 中。你也可以使用自己的私有仓库：

docker commit webserver
docker push eon01/hello-world-web-server

删除容器，因为我们将与 Minikube 一起使用它。

docker rm -f webserver

启动 Minikube：

minkube start

检查状态：

minikube status

我们运行一个单一节点：

kubectl get node

运行 webserver：

kubectl run webserver --image=eon01/hello-world-web-server --port=8000

webserver 应该会暴露它的端口：

kubectl expose deployment webserver --type=NodePort

为了得到服务 url 输入：

minikube service webserver --url

使用下面的命令得到 Web 页面的内容：

curl $(minikube service webserver --url)

显示运行中集群的摘要：

kubectl cluster-info

更多细节：

kubectl cluster-info dump

我们还可以使用以下方式列出 pod：

kubectl get pods

使用下面的方式访问面板：

minikube dashboard

如果你想访问 Web 程序的前端，输入：

kubectl proxy

如果我们要在容器内部执行一个命令，请使用以下命令获取 pod id：

kubetctl get pods

然后像这样使用：

kubectl exec webserver-2022867364-0v1p9 -it -- /bin/sh

最后完成了，请删除所有部署：

kubectl delete deployments --all

删除所有 pod：

kubectl delete pods --all

并且停止 Minikube。

minikube stop

我希望你享受这个介绍。

更加深入

如果你对本文感到共鸣，您可以在无痛 Docker 教程中找到更多有趣的内容。

我们 Eralabs 将很乐意为你的 Docker 和云计算项目提供帮助，联系我们，我们将很乐意听到你的项目。

请订阅 DevOpsLinks：成千上万的 IT 专家和 DevOps 爱好者在线社区。

你可能也有兴趣加入我们的新闻订阅 Shipped，一个专注于容器，编排和无服务技术的新闻订阅。

你可以在 Twitter、Clarity 或我的网站上找到我，你也可以看看我的书：SaltStack For DevOps。

不要忘记加入我的最后一个项目 DevOps 的职位！

如果你喜欢本文，请推荐它，并与你的关注者分享。

作者简介：

Aymen El Amri - 云和软件架构师、企业家、作者、www.eralabs.io 的 CEO、www.devopslinks.com 的创始人，个人页面：www.aymenelamri.com

via: https://medium.com/devopslinks/using-kubernetes-minikube-for-local-development-c37c6e56e3db

作者：Aymen El Amri 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

这是一篇 Kubernetes 的概览。

Kubernetes 是一个自动化部署、伸缩和操作应用程序容器的开源平台。

使用 Kubernetes，你可以快速、高效地满足用户以下的需求：

• 快速精准地部署应用程序
• 即时伸缩你的应用程序
• 无缝展现新特征
• 限制硬件用量仅为所需资源

我们的目标是培育一个工具和组件的生态系统，以减缓在公有云或私有云中运行的程序的压力。

Kubernetes 的优势

• 可移动: 公有云、私有云、混合云、多态云
• 可扩展: 模块化、插件化、可挂载、可组合
• 自修复: 自动部署、自动重启、自动复制、自动伸缩

Google 公司于 2014 年启动了 Kubernetes 项目。Kubernetes 是在 Google 的长达 15 年的成规模的产品级任务的经验下构建的，结合了来自社区的最佳创意和实践经验。

为什么选择容器?

想要知道你为什么要选择使用 容器?

程序部署的传统方法是指通过操作系统包管理器在主机上安装程序。这样做的缺点是，容易混淆程序之间以及程序和主机系统之间的可执行文件、配置文件、库、生命周期。为了达到精准展现和精准回撤，你可以搭建一台不可变的虚拟机镜像。但是虚拟机体量往往过于庞大而且不可转移。

容器部署的新的方式是基于操作系统级别的虚拟化，而非硬件虚拟化。容器彼此是隔离的，与宿主机也是隔离的：它们有自己的文件系统，彼此之间不能看到对方的进程，分配到的计算资源都是有限制的。它们比虚拟机更容易搭建。并且由于和基础架构、宿主机文件系统是解耦的，它们可以在不同类型的云上或操作系统上转移。

正因为容器又小又快，每一个容器镜像都可以打包装载一个程序。这种一对一的“程序 - 镜像”联系带给了容器诸多便捷。有了容器，静态容器镜像可以在编译/发布时期创建，而非部署时期。因此，每个应用不必再等待和整个应用栈其它部分进行整合，也不必和产品基础架构环境之间进行妥协。在编译/发布时期生成容器镜像建立了一个持续地把开发转化为产品的环境。相似地，容器远比虚拟机更加透明，尤其在设备监控和管理上。这一点，在容器的进程生命周期被基础架构管理而非被容器内的进程监督器隐藏掉时，尤为显著。最终，随着每个容器内都装载了单一的程序，管理容器就等于管理或部署整个应用。

容器优势总结：

• 敏捷的应用创建与部署：相比虚拟机镜像，容器镜像的创建更简便、更高效。
• 持续的开发、集成，以及部署：在快速回滚下提供可靠、高频的容器镜像编译和部署（基于镜像的不可变性）。
• 开发与运营的关注点分离：由于容器镜像是在编译/发布期创建的，因此整个过程与基础架构解耦。
• 跨开发、测试、产品阶段的环境稳定性：在笔记本电脑上的运行结果和在云上完全一致。
• 在云平台与 OS 上分发的可转移性：可以在 Ubuntu、RHEL、CoreOS、预置系统、Google 容器引擎，乃至其它各类平台上运行。
• 以应用为核心的管理: 从在虚拟硬件上运行系统，到在利用逻辑资源的系统上运行程序，从而提升了系统的抽象层级。
• 松散耦联、分布式、弹性、无拘束的微服务：整个应用被分散为更小、更独立的模块，并且这些模块可以被动态地部署和管理，而不再是存储在大型的单用途机器上的臃肿的单一应用栈。
• 资源隔离：增加程序表现的可预见性。
• 资源利用率：高效且密集。

为什么我需要 Kubernetes，它能做什么?

至少，Kubernetes 能在实体机或虚拟机集群上调度和运行程序容器。而且，Kubernetes 也能让开发者斩断联系着实体机或虚拟机的“锁链”，从以主机为中心的架构跃至以容器为中心的架构。该架构最终提供给开发者诸多内在的优势和便利。Kubernetes 提供给基础架构以真正的以容器为中心的开发环境。

Kubernetes 满足了一系列产品内运行程序的普通需求，诸如：

• 协调辅助进程，协助应用程序整合，维护一对一“程序 - 镜像”模型。
• 挂载存储系统
• 分布式机密信息
• 检查程序状态
• 复制应用实例
• 使用横向荚式自动缩放
• 命名与发现
• 负载均衡
• 滚动更新
• 资源监控
• 访问并读取日志
• 程序调试
• 提供验证与授权

以上兼具平台即服务（PaaS）的简化和基础架构即服务（IaaS）的灵活，并促进了在平台服务提供商之间的迁移。

Kubernetes 是一个什么样的平台?

虽然 Kubernetes 提供了非常多的功能，总会有更多受益于新特性的新场景出现。针对特定应用的工作流程，能被流水线化以加速开发速度。特别的编排起初是可接受的，这往往需要拥有健壮的大规模自动化机制。这也是为什么 Kubernetes 也被设计为一个构建组件和工具的生态系统的平台，使其更容易地部署、缩放、管理应用程序。

标签 （ label ） 可以让用户按照自己的喜好组织资源。 注释 （ annotation ） 让用户在资源里添加客户信息，以优化工作流程，为管理工具提供一个标示调试状态的简单方法。

此外，Kubernetes 控制面板是由开发者和用户均可使用的同样的 API 构建的。用户可以编写自己的控制器，比如 调度器 （ scheduler ） ，使用可以被通用的命令行工具识别的他们自己的 API。

这种设计让大量的其它系统也能构建于 Kubernetes 之上。

Kubernetes 不是什么？

Kubernetes 不是传统的、全包容的平台即服务（Paas）系统。它尊重用户的选择，这很重要。

Kubernetes：

• 并不限制支持的程序类型。它并不检测程序的框架 (例如，Wildfly)，也不限制运行时支持的语言集合 (比如， Java、Python、Ruby)，也不仅仅迎合 12 因子应用程序，也不区分 应用 与 服务 。Kubernetes 旨在支持尽可能多种类的工作负载，包括无状态的、有状态的和处理数据的工作负载。如果某程序在容器内运行良好，它在 Kubernetes 上只可能运行地更好。
• 不提供中间件（例如消息总线）、数据处理框架（例如 Spark）、数据库（例如 mysql），也不把集群存储系统（例如 Ceph）作为内置服务。但是以上程序都可以在 Kubernetes 上运行。
• 没有“点击即部署”这类的服务市场存在。
• 不部署源代码，也不编译程序。持续集成 (CI) 工作流程是不同的用户和项目拥有其各自不同的需求和表现的地方。所以，Kubernetes 支持分层 CI 工作流程，却并不监听每层的工作状态。
• 允许用户自行选择日志、监控、预警系统。（ Kubernetes 提供一些集成工具以保证这一概念得到执行）
• 不提供也不管理一套完整的应用程序配置语言/系统（例如 jsonnet）。
• 不提供也不配合任何完整的机器配置、维护、管理、自我修复系统。

另一方面，大量的 PaaS 系统运行在 Kubernetes 上，诸如 Openshift、Deis，以及 Eldarion。你也可以开发你的自定义 PaaS，整合上你自选的 CI 系统，或者只在 Kubernetes 上部署容器镜像。

因为 Kubernetes 运营在应用程序层面而不是在硬件层面，它提供了一些 PaaS 所通常提供的常见的适用功能，比如部署、伸缩、负载平衡、日志和监控。然而，Kubernetes 并非铁板一块，这些默认的解决方案是可供选择，可自行增加或删除的。

而且， Kubernetes 不只是一个编排系统 。事实上，它满足了编排的需求。 编排 的技术定义是，一个定义好的工作流程的执行：先做 A，再做 B，最后做 C。相反地， Kubernetes 囊括了一系列独立、可组合的控制流程，它们持续驱动当前状态向需求的状态发展。从 A 到 C 的具体过程并不唯一。集中化控制也并不是必须的；这种方式更像是编舞。这将使系统更易用、更高效、更健壮、复用性、扩展性更强。

Kubernetes 这个单词的含义？k8s？

Kubernetes 这个单词来自于希腊语，含义是 舵手 或 领航员 。其词根是 governor 和 cybernetic。 K8s 是它的缩写，用 8 字替代了“ubernete”。

via: https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/

作者：kubernetes.io 译者：songshuang00 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

在这个快速入门教程中，我们使用 Azure CLI 创建一个 Kubernetes 集群，然后在集群上部署运行由 Web 前端和 Redis 实例组成的多容器应用程序。一旦部署完成，应用程序可以通过互联网访问。

这个快速入门教程假设你已经基本了解了 Kubernetes 的概念，有关 Kubernetes 的详细信息，请参阅 Kubernetes 文档。

如果您没有 Azure 账号，请在开始之前创建一个免费帐户。

登录 Azure 云控制台

Azure 云控制台是一个免费的 Bash shell，你可以直接在 Azure 网站上运行。它已经在你的账户中预先配置好了， 单击 Azure 门户右上角菜单上的 “Cloud Shell” 按钮；

该按钮会启动一个交互式 shell，您可以使用它来运行本教程中的所有操作步骤。

此快速入门教程所用的 Azure CLI 的版本最低要求为 2.0.4。如果您选择在本地安装和使用 CLI 工具，请运行 az --version 来检查已安装的版本。 如果您需要安装或升级请参阅安装 Azure CLI 2.0 。

创建一个资源组

使用 az group create 命令创建一个资源组，一个 Azure 资源组是指 Azure 资源部署和管理的逻辑组。

以下示例在 eastus 区域中创建名为 myResourceGroup 的资源组。

az group create --name myResourceGroup --location eastus

输出：

{
  "id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroup",
  "location": "eastus",
  "managedBy": null,
  "name": "myResourceGroup",
  "properties": {
    "provisioningState": "Succeeded"
  },
  "tags": null
}

创建一个 Kubernetes 集群

使用 az acs create 命令在 Azure 容器服务中创建 Kubernetes 集群。 以下示例使用一个 Linux 主节点和三个 Linux 代理节点创建一个名为 myK8sCluster 的集群。

az acs create --orchestrator-type=kubernetes --resource-group myResourceGroup --name=myK8sCluster --generate-ssh-keys 

几分钟后，命令将完成并返回有关该集群的 json 格式的信息。

连接到 Kubernetes 集群

要管理 Kubernetes 群集，可以使用 Kubernetes 命令行工具 kubectl。

如果您使用 Azure CloudShell ，则已经安装了 kubectl 。如果要在本地安装，可以使用 az acs kubernetes install-cli 命令。

要配置 kubectl 连接到您的 Kubernetes 群集，请运行 az acs kubernetes get-credentials 命令下载凭据并配置 Kubernetes CLI 以使用它们。

az acs kubernetes get-credentials --resource-group=myResourceGroup --name=myK8sCluster

要验证与集群的连接，请使用 kubectl get 命令查看集群节点的列表。

kubectl get nodes

输出：

NAME                    STATUS                     AGE       VERSION
k8s-agent-14ad53a1-0    Ready                      10m       v1.6.6
k8s-agent-14ad53a1-1    Ready                      10m       v1.6.6
k8s-agent-14ad53a1-2    Ready                      10m       v1.6.6
k8s-master-14ad53a1-0   Ready,SchedulingDisabled   10m       v1.6.6

运行应用程序

Kubernetes 清单文件为集群定义了一个所需的状态，包括了集群中应该运行什么样的容器镜像。 对于此示例，清单用于创建运行 Azure Vote 应用程序所需的所有对象。

创建一个名为 azure-vote.yaml ，将下面的内容拷贝到 YAML 中。

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: azure-vote-back
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: azure-vote-back
    spec:
      containers:
      - name: azure-vote-back
        image: redis
        ports:
        - containerPort: 6379
          name: redis
---
apiVersion: v1
kind: Service
metadata:
  name: azure-vote-back
spec:
  ports:
  - port: 6379
  selector:
    app: azure-vote-back
---
apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: azure-vote-front
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: azure-vote-front
    spec:
      containers:
      - name: azure-vote-front
        image: microsoft/azure-vote-front:redis-v1
        ports:
        - containerPort: 80
        env:
        - name: REDIS
          value: "azure-vote-back"
---
apiVersion: v1
kind: Service
metadata:
  name: azure-vote-front
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: azure-vote-front

使用 kubectl create 命令来运行该应用程序。

kubectl create -f azure-vote.yaml

输出：

deployment "azure-vote-back" created
service "azure-vote-back" created
deployment "azure-vote-front" created
service "azure-vote-front" created

测试应用程序

当应用程序的跑起来之后，需要创建一个 Kubernetes 服务，将应用程序前端暴露在互联网上。 此过程可能需要几分钟才能完成。

要监控这个进程，使用 kubectl get service 命令时加上 --watch 参数。

kubectl get service azure-vote-front --watch

最初，azure-vote-front 服务的 EXTERNAL-IP 显示为 pending 。 一旦 EXTERNAL-IP 地址从 pending 变成一个具体的 IP 地址，请使用 “CTRL-C” 来停止 kubectl 监视进程。

azure-vote-front   10.0.34.242   <pending>     80:30676/TCP   7s
azure-vote-front   10.0.34.242   52.179.23.131   80:30676/TCP   2m

现在你可以通过这个外网 IP 地址访问到 Azure Vote 这个应用了。

删除集群

当不再需要集群时，可以使用 az group delete 命令删除资源组，容器服务和所有相关资源。

az group delete --name myResourceGroup --yes --no-wait

获取示例代码

在这个快速入门教程中，预先创建的容器镜像已被用于部署 Kubernetes 。相关应用程序代码 Dockerfile 和 Kubernetes 清单文件可在 GitHub 中获得。Github 仓库地址是 https://github.com/Azure-Samples/azure-voting-app-redis

下一步

在这个快速入门教程中，您部署了一个 Kubernetes 集群，并部署了一个多容器应用程序。

要了解有关 Azure 容器服务的更多信息，走完一个完整的从代码到部署的全流程，请继续阅读 Kubernetes 集群教程。

via: https://docs.microsoft.com/en-us/azure/container-service/kubernetes/container-service-kubernetes-walkthrough

作者：neilpeterson，mmacy 译者：rieonke 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

有无数的文章、讨论、以及很多社区喋喋不休地比较 Docker、Kubernetes 和 Mesos。如果你只是听信了只言片语，你可能会认为这三个开源项目正为了称霸容器界而殊死搏斗。你可能还相信从他们中选出一个如宗教信仰般神圣——真正的信徒会忠于他们的信仰，而且会烧死那些敢于考虑替代方案的异教徒。

那都是废话。

虽然所有这三种技术都使得使用容器来部署、管理和伸缩应用成为可能，但实际上它们各自解决了不同的问题，并且根植于迥异的上下文环境中。事实上，这三种被广泛采用的工具链，都是有差别的。

让我们重新审视每个项目的原始任务、技术架构，以及它们是如何相互补充和交互的，而不是纠结于比较这些快速迭代的技术之间重叠的特性。

让我们从 Docker 开始……

Docker 公司，始于名为 dotCloud 的平台即服务（PaaS）供应商。dotCloud 团队发现，在许多应用和客户之间管理依赖和二进制文件时需要付出大量的工作。因此他们将 Linux 的 cgroups 和 namespace 的一些功能合并成一个单一且易于使用的软件包，以便于应用程序可以一致地运行在任何基础设施上。这个软件包就是所谓的 Docker 镜像，它提供了如下的功能：

• 将应用程序和依赖库封装在一个软件包（即 Docker 镜像）中，因此应用可以被一致地部署在各个环境上；
• 提供类似 Git 的语义，例如 docker push，docker commit 等命令让应用开发者可以快速接受这门新的技术，并将其融入到现有的工作流中；
• 定义 Docker 镜像为不可变的层，支持不可变的基础设施。新提交的变更被分别保存为只读层，让复用镜像和追踪变更记录变得十分简单。层还通过只传输更新而不是整个镜像来节省磁盘空间和网络流量；
• 通过实例化不可变的镜像和读写层来运行 Docker 容器，读写层可以临时地存储运行时变更，从而轻松部署和扩展应用程序的多个实例。

Docker 变得越来越受欢迎，开发者们开始从在笔记本电脑上运行容器转而在生产环境中运行容器。跨多个机器之间协调这些容器需要额外的工具，这称之为 容器编排 container orchestration 。有趣的是，第一个支持 Docker 镜像的容器编排工具（2014 年 6月）是 Apache Mesos 的 Marathon（后面会有详细介绍) 。那年，Docker 的创始人兼首席技术官 Solomon Hykes 将 Mesos 推荐为“生产集群的黄金标准”。不久之后，除了 Mesos 的 Marathon 之外，还出现了许多的容器编排技术：Nomad、Kubernetes，不出所料还有 Docker Swarm （它如今是 Docker 引擎的一部分）。

随着 Docker 开始商业化其开源的文件格式（LCTT 译注：指 Docker 镜像的 dockerfile 文件格式），该公司还开始引入工具来完善其核心的 Docker 文件格式和运行时引擎，包括：

• 为公开存储 Docker 镜像的而生的 Docker hub；
• 存储私有镜像的 Docker 仓库（Docker registry）；
• Docker cloud，用于构建和运行容器的管理性服务；
• Docker 数据中心作为一种商业产品体现了许多 Docker 技术；

来源: www.docker.com

Docker 将软件及其依赖关系封装在一个软件包中的洞察力改变了软件行业的游戏规则，正如 mp3 的出现重塑了音乐行业一般。Docker 文件格式成为行业标准，领先的容器技术供应商（包括 Docker、Google、Pivotal、Mesosphere 等) 组建了 云计算基金会 Cloud Native Computing Foundation (CNCF) 和 开放容器推进联盟 Open Container Initiative (OCI)。如今，CNCF 和 OCI 旨在确保容器技术之间的互操性和标准化接口，并确保使用任何工具构建的任何 Docker 容器都可以在任何运行时或基础架构上运行。

进入 Kubernetes

Google 很早就认识到了 Docker 的潜力，并试图在 Google Cloud Platform （GCP）上提供容器编排“即服务”。 Google 在容器方面拥有丰富的经验（是他们在 Linux 中引入了 cgroups），但现有的内部容器和 Borg 等分布式计算工具直接与其基础架构相耦合。所以，Google 没有使用原有系统的任何代码，而是从头开始设计 Kubernetes （K8S）来编排 Docker 容器。 Kubernetes 于 2015 年 2 月发布，其目标和考虑如下：

• 为应用程序开发人员提供编排 Docker 容器的强大工具，而无需与底层基础设施交互；
• 提供标准部署接口和原语，以实现云端一致的应用部署体验和 API;
• 基于模块化 API 核心，允许供应商围绕 Kubernetes 的核心技术集成其系统。

2016 年 3 月，Google 将 Kubernetes 捐赠给了 CNCF，并且直到今天仍然是该项目的主要贡献者（其次是Redhat，CoreOS 等）。

来源: wikipedia

Kubernetes 对应用程序开发人员非常有吸引力，因为它减轻了对基础架构和运营团队的依赖程度。供应商也喜欢 Kubernetes，因为它提供了一个容易的方式来拥抱容器化运动，并为客户部署自己的 Kubernetes（这仍然是一个值得重视的挑战）提供商业解决方案。 Kubernetes 也是有吸引力的，因为它是 CNCF 旗下的开源项目，与 Docker Swarm 相反，Docker Swarm 尽管是开源的，但是被 Docker 公司紧紧地掌控着。

Kubernetes 的核心优势是为应用程序开发人员提供了用于编排无状态 Docker 容器的强大工具。 虽然有多个扩大项目范围的提议，以提供更多的功能（例如分析和有状态数据服务），但这些提议仍处于非常早期的阶段，它们能取得多大的成功还有待观察。

Apache Mesos

Apache Mesos 始于 加州大学伯克利分校 UC Berkeley 的下一代容器集群管理器项目，并应用了从云计算级别的分布式基础架构（如 Google 的 Borg 和 Facebook 的 Tupperware）中习得的经验和教训。 虽然 Borg 和 Tupperware 具有单一的架构，并且是与物理基础架构紧密结合的闭源专有技术，但 Mesos 推出了一种模块化架构，一种开源的开发方法，旨在完全独立于基础架构。Mesos 迅速被 Twitter、Apple（Siri 中）、Yelp、Uber、Netflix 和许多领先的技术公司采用，支持从微服务、大数据和实时分析到弹性扩展的一切。

作为集群管理器，Mesos 被设计用来解决一系列不同的挑战：

• 将数据中心资源抽象为单个池来简化资源分配，同时在私有云或公有云中提供一致的应用和运维体验；
• 在相同的基础架构上协调多个工作负载，如分析、无状态微服务、分布式数据服务和传统应用程序，以提高利用率，降低成本和台面空间;
• 为应用程序特定的任务（如部署、自我修复、扩展和升级），自动执行第二天的操作；提供高度可用的容错基础设施；
• 提供持久的可扩展性来运行新的应用程序和技术，而无需修改集群管理器或其上构建的任何现有应用程序；
• 弹性扩展可以将应用程序和底层基础设施从少量扩展到数十到数万个节点。

Mesos 独有的独立管理各种工作负载的能力 —— 包括 Java 这样的传统应用程序、无状态 Docker 微服务、批处理作业、实时分析和有状态的分布式数据服务。Mesos 广泛的工作负载覆盖来自于其两级架构，从而实现了“应用感知”调度。通过将应用程序特定的操作逻辑封装在“Mesos 框架”（类似于操作中的运行手册）中来实现应用程序感知调度。资源管理器 Mesos Master 提供了这些框架基础架构的部分，同时保持隔离。这种方法允许每个工作负载都有自己的专门构建的应用程序调度程序，可以了解其部署、扩展和升级的特定操作要求。应用程序调度程序也是独立开发、管理和更新的，这让 Mesos 拥有高度可扩展的能力，支持新的工作负载或随着时间的推移而增加更多的操作功能。

举一个团队如何管理应用软件升级的例子。无状态应用程序可以从“蓝/绿”部署方案中受益；当新版本的应用运行起来时，原先旧版本的软件依然还正常运转着，然后当旧应用被销毁时流量将会切换到新的应用上。但是升级数据工作负载例如 HDFS 或者 Cassandra 要求节点停机一次，此时需要持久化本地数据卷以防止数据丢失，并且按照特定的顺序执行原位升级，在升级之前和升级完成之后，都要在每一个节点类型上执行特定的检查和命令。任何这些步骤都是应用程序或服务特定的，甚至可能是版本特定的。这让使用常规容器编排调度程序来管理数据服务变得非常困难。

Mesos 以每一个工作负载所需的特定方式管理各种工作负载，使得许多公司将 Mesos 作为一个统一的平台，将微服务和数据服务结合在一起。数据密集型应用程序的通用参考架构是 “SMACK 家族”（LCTT 译注：SMACK 即 Spark、Mesos、Akka、Cassandra、Kafka)。

是时候搞清楚这些了

请注意，我们尚未对 Apache Mesos 的容器编排有任何描述。所以为什么人们会自动地将 Mesos 和容器编排联系起来呢？容器编排是可以在 Mesos 的模块化架构上运行的工作负载的一个例子，它是通过一个专门的编排“框架”来完成的，这个框架就 Marathon，一个构建于 Mesos 之上的工具。 Marathon 最初是为了在 cgroup 容器中编排应用归档（如 JAR、tarball、ZIP 文件）而开发的，是 2014 年最先支持 Docker 容器的编排工具之一。

所以当人们将 Docker 和 Kubernetes 与 Mesos 进行比较时，他们实际上是将 Kubernetes 和 Docker Swarm 与在 Mesos 上运行的 Marathon 进行比较。

为什么搞清楚这一点很重要？ 因为 Mesos 坦率地讲并不在乎它上面运行了什么。 Mesos 可以在共享的基础设施上弹性地为 Java 应用服务器提供集群服务、Docker 容器编排、Jenkins 持续集成任务、Apache Spark 分析、Apache Kafka 流，以及更多其他的服务。Mesos 甚至可以运行 Kubernetes 或者其他的容器编排工具，即使公共的集成目前还不可用。

来源: Apache Mesos 2016 调查问卷

Mesos 的另一个考虑因素（也是为什么它对许多企业架构师来说如此有吸引力）是运行关键任务工作负载的成熟度。 Mesos 已经在大规模生产环境下（成千上万台服务器）运行了超过 7 年的时间，这就是为什么它比市场上许多其他的容器技术更具有生产上的可行性和扩展上的可靠性。

我所说的这些什么意思？

总而言之，所有这三种技术都与 Docker 容器有关，可以让你在容器编排上实现应用程序的可移植性和扩展性。那么你在它们之间如何选择呢？ 归根到底是为工作选择合适的工具（也可能是为不同的工作选择不同的工具）。如果您是一个应用开发人员，正在寻找现代化的方式来构建和打包你的应用程序，或者想加速你的微服务计划，Docker 容器和开发工具就是最好的选择。

如果你们是一个开发人员或者 DevOps 的团队，并希望构建一个专门用于 Docker 容器编排的系统，而且愿意花时间折腾集成解决方案与底层基础设施（或依靠公共云基础架构，如 Google 容器引擎（GCE）或 Azure 容器服务（ACS）），Kubernetes 是一个可以考虑的好技术。

如果你们想要建立一个运行多个关键任务工作负载的可靠平台，包括 Docker 容器、传统应用程序（例如 Java）和分布式数据服务（例如 Spark、Kafka、Cassandra、Elastic），并希望所有这些可依移植到云端提供商或者数据中心，那么 Mesos（或我们自己的 Mesos 发行版，Mesosphere DC/OS）更适合你们的需求。

无论您选择什么，您都将拥抱一套可以更有效地利用服务器资源的工具，简化应用程序的可移植性，并提高开发人员的敏捷性。你的选择真的不会有错。

via: https://mesosphere.com/blog/docker-vs-kubernetes-vs-apache-mesos/

作者：Amr Abdelrazik 译者：rieonke 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出