人们经常用 x 相对于 y 这样的术语来考虑问题，但是它并不是一个技术对另一个技术的问题。Ben Hindman 在这里解释了 Mesos 是如何对另外一种技术进行补充的。

Mesos 的起源可以追溯到 2009 年，当时，Ben Hindman 还是加州大学伯克利分校研究并行编程的博士生。他们在 128 核的芯片上做大规模的并行计算，以尝试去解决多个问题，比如怎么让软件和库在这些芯片上运行更高效。他与同学们讨论能否借鉴并行处理和多线程的思想，并将它们应用到集群管理上。

Hindman 说 “最初，我们专注于大数据” 。那时，大数据非常热门，而 Hadoop 就是其中的一个热门技术。“我们发现，人们在集群上运行像 Hadoop 这样的程序与运行多线程应用及并行应用很相似。”Hindman 说。

但是，它们的效率并不高，因此，他们开始去思考，如何通过集群管理和资源管理让它们运行的更好。“我们查看了那个时期很多的各种技术” Hindman 回忆道。

然后，Hindman 和他的同事们决定去采用一种全新的方法。“我们决定对资源管理创建一个低级的抽象，然后在此之上运行调度服务和做其它的事情。” Hindman 说，“基本上，这就是 Mesos 的本质 —— 将资源管理部分从调度部分中分离出来。”

他成功了，并且 Mesos 从那时开始强大了起来。

将项目呈献给 Apache

这个项目发起于 2009 年。在 2010 年时，团队决定将这个项目捐献给 Apache 软件基金会（ASF）。它在 Apache 孵化，并于 2013 年成为顶级项目（TLP）。

为什么 Mesos 社区选择 Apache 软件基金会有很多的原因，比如，Apache 许可证，以及基金会已经拥有了一个充满活力的其它此类项目的社区。

与影响力也有关系。许多在 Mesos 上工作的人也参与了 Apache，并且许多人也致力于像 Hadoop 这样的项目。同时，来自 Mesos 社区的许多人也致力于其它大数据项目，比如 Spark。这种交叉工作使得这三个项目 —— Hadoop、Mesos，以及 Spark —— 成为 ASF 的项目。

与商业也有关系。许多公司对 Mesos 很感兴趣，并且开发者希望它能由一个中立的机构来维护它，而不是让它成为一个私有项目。

谁在用 Mesos？

更好的问题应该是，谁不在用 Mesos？从 Apple 到 Netflix 每个都在用 Mesos。但是，Mesos 也面临任何技术在早期所面对的挑战。“最初，我要说服人们，这是一个很有趣的新技术。它叫做‘容器’，因为它不需要使用虚拟机” Hindman 说。

从那以后，这个行业发生了许多变化，现在，只要与别人聊到基础设施，必然是从”容器“开始的 —— 感谢 Docker 所做出的工作。今天再也不需要做说服工作了，而在 Mesos 出现的早期，前面提到的像 Apple、Netflix，以及 PayPal 这样的公司。他们已经知道了容器替代虚拟机给他们带来的技术优势。“这些公司在容器成为一种现象之前，已经明白了容器的价值所在”， Hindman 说。

可以在这些公司中看到，他们有大量的容器而不是虚拟机。他们所做的全部工作只是去管理和运行这些容器，并且他们欣然接受了 Mesos。在 Mesos 早期就使用它的公司有 Apple、Netflix、PayPal、Yelp、OpenTable 和 Groupon。

“大多数组织使用 Mesos 来运行各种服务” Hindman 说，“但也有些公司用它做一些非常有趣的事情，比如，数据处理、数据流、分析任务和应用程序。“

这些公司采用 Mesos 的其中一个原因是，资源管理层之间有一个明晰的界线。当公司运营容器的时候，Mesos 为他们提供了很好的灵活性。

“我们尝试使用 Mesos 去做的一件事情是去创建一个层，以让使用者享受到我们的层带来的好处，当然也可以在它之上创建任何他们想要的东西，” Hindman 说。 “我认为这对一些像 Netflix 和 Apple 这样的大公司非常有用。”

但是，并不是每个公司都是技术型的公司；不是每个公司都有或者应该有这种专长。为帮助这样的组织，Hindman 联合创建了 Mesosphere 去围绕 Mesos 提供服务和解决方案。“我们最终决定，为这样的组织去构建 DC/OS，它不需要技术专长或者不想把时间花费在像构建这样的事情上。”

Mesos vs. Kubernetes?

人们经常用 x 相对于 y 这样的术语来考虑问题，但是它并不是一个技术对另一个技术的问题。大多数的技术在一些领域总是重叠的，并且它们可以是互补的。“我不喜欢将所有的这些东西都看做是竞争者。我认为它们中的一些与另一个在工作中是互补的，” Hindman 说。

“事实上，名字 Mesos 表示它处于 ‘中间’；它是一种中间的操作系统”， Hindman 说，“我们有一个容器调度器的概念，它能够运行在像 Mesos 这样的东西之上。当 Kubernetes 刚出现的时候，我们实际上在 Mesos 的生态系统中接受了它，并将它看做是在 Mesos 上的 DC/OS 中运行容器的另一种方式。”

Mesos 也复活了一个名为 Marathon（一个用于 Mesos 和 DC/OS 的容器编排器）的项目，它成为了 Mesos 生态系统中最重要的成员。但是，Marathon 确实无法与 Kubernetes 相比较。“Kubernetes 比 Marathon 做的更多，因此，你不能将它们简单地相互交换，” Hindman 说，“与此同时，我们在 Mesos 中做了许多 Kubernetes 中没有的东西。因此，这些技术之间是互补的。”

不要将这些技术视为相互之间是敌对的关系，它们应该被看做是对行业有益的技术。它们不是技术上的重复；它们是多样化的。据 Hindman 说，“对于开源领域的终端用户来说，这可能会让他们很困惑，因为他们很难去知道哪个技术适用于哪种任务，但这是这个被称之为开源的本质所在。“

这只是意味着有更多的选择，并且每个都是赢家。

via: https://www.linux.com/blog/2018/6/mesos-and-kubernetes-its-not-competition

作者：Swapnil Bhartiya 选题：lujun9972 译者：qhwdw 校对：wxy

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

这是我以前的 10 分钟内配置 Kubernetes 教程的精简版和更新版。我删除了一些我认为可以去掉的内容，所以，这个指南仍然是通顺的。当你想在云上创建一个集群或者尽可能快地构建基础设施时，你可能会用到它。

1.0 挑选一个主机

我们在本指南中将使用 Ubuntu 16.04，这样你就可以直接拷贝/粘贴所有的指令。下面是我用本指南测试过的几种环境。根据你运行的主机，你可以从中挑选一个。

• DigitalOcean - 开发者云
• Civo - UK 开发者云
• Packet - 裸机云
• 2x Dell Intel i7 服务器 —— 它在我家中

Civo 是一个相对较新的开发者云，我比较喜欢的一点是，它开机时间只有 25 秒，我就在英国，因此，它的延迟很低。

1.1 准备机器

你可以使用一个单台主机进行测试，但是，我建议你至少使用三台机器，这样你就有一个主节点和两个工作节点。

下面是一些其他的指导原则：

• 最好选至少有 2 GB 内存的双核主机
• 在准备主机的时候，如果你可以自定义用户名，那么就不要使用 root。例如，Civo 通常让你在 ubuntu、civo 或者 root 中选一个。

现在，在每台机器上都运行以下的步骤。它将需要 5-10 钟时间。如果你觉得太慢了，你可以使用我放在 Gist 的脚本 ：

$ curl -sL https://gist.githubusercontent.com/alexellis/e8bbec45c75ea38da5547746c0ca4b0c/raw/23fc4cd13910eac646b13c4f8812bab3eeebab4c/configure.sh | sh

1.2 登入和安装 Docker

从 Ubuntu 的 apt 仓库中安装 Docker。它的版本可能有点老，但是，Kubernetes 在老版本的 Docker 中是测试过的，工作的很好。

$ sudo apt-get update \
  && sudo apt-get install -qy docker.io

1.3 禁用 swap 文件

这是 Kubernetes 的强制步骤。实现它很简单，编辑 /etc/fstab 文件，然后注释掉引用 swap 的行即可。

保存它，重启后输入 sudo swapoff -a。

一开始就禁用 swap 内存，你可能觉得这个要求很奇怪，如果你对这个做法感到好奇，你可以去 这里阅读它的相关内容。

1.4 安装 Kubernetes 包

$ sudo apt-get update \
  && sudo apt-get install -y apt-transport-https \
  && curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -

$ echo "deb http://apt.kubernetes.io/ kubernetes-xenial main" \
  | sudo tee -a /etc/apt/sources.list.d/kubernetes.list \
  && sudo apt-get update 

$ sudo apt-get update \
  && sudo apt-get install -y \
  kubelet \
  kubeadm \
  kubernetes-cni

1.5 创建集群

这时候，我们使用 kubeadm 初始化主节点并创建集群。这一步仅在主节点上操作。

虽然有警告，但是 Weaveworks 和 Lucas（他们是维护者）向我保证，kubeadm 是可用于生产系统的。

$ sudo kubeadm init

如果你错过一个步骤或者有问题，kubeadm 将会及时告诉你。

我们复制一份 Kube 配置：

mkdir -p $HOME/.kube  
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config  
sudo chown $(id -u):$(id -g) $HOME/.kube/config

确保你一定要记下如下的加入 token 的命令。

$ sudo kubeadm join --token c30633.d178035db2b4bb9a 10.0.0.5:6443 --discovery-token-ca-cert-hash sha256:<hash>

2.0 安装网络

许多网络提供商提供了 Kubernetes 支持，但是，默认情况下 Kubernetes 都没有包括。这里我们使用来自 Weaveworks 的 Weave Net，它是 Kebernetes 社区中非常流行的选择之一。它近乎不需要额外配置的 “开箱即用”。

$ kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"

如果在你的主机上启用了私有网络，那么，你可能需要去修改 Weavenet 使用的私有子网络，以便于为 Pod（容器）分配 IP 地址。下面是命令示例：

$ curl -SL "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')&env.IPALLOC_RANGE=172.16.6.64/27" \
| kubectl apply -f -

Weave 也有很酷的称为 Weave Cloud 的可视化工具。它是免费的，你可以在它上面看到你的 Pod 之间的路径流量。这里有一个使用 OpenFaaS 项目的示例。

2.2 在集群中加入工作节点

现在，你可以切换到你的每一台工作节点，然后使用 1.5 节中的 kubeadm join 命令。运行完成后，登出那个工作节点。

3.0 收获

到此为止 —— 我们全部配置完成了。你现在有一个正在运行着的集群，你可以在它上面部署应用程序。如果你需要设置仪表板 UI，你可以去参考 Kubernetes 文档。

$ kubectl get nodes
NAME        STATUS    ROLES     AGE       VERSION  
openfaas1   Ready     master    20m       v1.9.2  
openfaas2   Ready     <none>    19m       v1.9.2  
openfaas3   Ready     <none>    19m       v1.9.2  

如果你想看到我一步一步创建集群并且展示 kubectl 如何工作的视频，你可以看下面我的视频，你可以订阅它。

你也可以在你的 Mac 电脑上，使用 Minikube 或者 Docker 的 Mac Edge 版本，安装一个 “开箱即用” 的 Kubernetes 集群。阅读在这里的我的评估和第一印象。

via: https://blog.alexellis.io/your-instant-kubernetes-cluster/

作者：Alex Ellis 译者：qhwdw 校对：wxy

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

这篇文章最初发表在 Kevin Monroe 的博客 上。

监视日志和指标状态是集群管理员的重点工作。它的好处很明显：指标能帮你设置一个合理的性能目标，而日志分析可以发现影响你工作负载的问题。然而，困难的是如何找到一个与大量运行的应用程序一起工作的监视解决方案。

在本文中，我将使用 Graylog （用于日志）和 Prometheus （用于指标）去打造一个 Kubernetes 集群的监视解决方案。当然了，这不仅是将三个东西连接起来那么简单，实现上，最终结果看起来应该如题图所示：

正如你所了解的，Kubernetes 不是一件东西 —— 它由主控节点、工作节点、网络连接、配置管理等等组成。同样，Graylog 是一个配角（apache2、mongodb、等等），Prometheus 也一样（telegraf、grafana 等等）。在部署中连接这些点看起来似乎有些让人恐惧，但是使用合适的工具将不会那么困难。

我将使用 conjure-up 和 Canonical 版本的 Kubernetes (CDK) 去探索 Kubernetes。我发现 conjure-up 接口对部署大型软件很有帮助，但是我知道一些人可能不喜欢 GUI、TUI 以及其它用户界面。对于这些人，我将用命令行再去部署一遍。

在开始之前需要注意的一点是，Graylog 和 Prometheus 是部署在 Kubernetes 外侧而不是集群上。像 Kubernetes 仪表盘和 Heapster 是运行的集群的非常好的信息来源，但是我的目标是为日志/指标提供一个分析机制，而不管集群运行与否。

开始探索

如果你的系统上没有 conjure-up，首先要做的第一件事情是，请先安装它，在 Linux 上，这很简单：

sudo snap install conjure-up --classic

对于 macOS 用户也提供了 brew 包：

brew install conjure-up

你需要最新的 2.5.2 版，它的好处是添加了 CDK spell，因此，如果你的系统上已经安装了旧的版本，请使用 sudo snap refresh conjure-up 或者 brew update && brew upgrade conjure-up 去更新它。

安装完成后，运行它：

conjure-up

你将发现有一个 spell 列表。选择 CDK 然后按下回车。

这个时候，你将看到 CDK spell 可用的附加组件。我们感兴趣的是 Graylog 和 Prometheus，因此选择这两个，然后点击 “Continue”。

它将引导你选择各种云，以决定你的集群部署的地方。之后，你将看到一些部署的后续步骤，接下来是回顾屏幕，让你再次确认部署内容：

除了典型的 K8s 相关的应用程序（etcd、flannel、load-balancer、master 以及 workers）之外，你将看到我们选择的日志和指标相关的额外应用程序。

Graylog 栈包含如下：

• apache2：graylog web 界面的反向代理
• elasticsearch：日志使用的文档数据库
• filebeat：从 K8s master/workers 转发日志到 graylog
• graylog：为日志收集器提供一个 api，以及提供一个日志分析界面
• mongodb：保存 graylog 元数据的数据库

Prometheus 栈包含如下：

• grafana：指标相关的仪表板的 web 界面
• prometheus：指标收集器以及时序数据库
• telegraf：发送主机的指标到 prometheus 中

你可以在回顾屏幕上微调部署，但是默认组件是必选 的。点击 “Deploy all Remaining Applications” 继续。

部署工作将花费一些时间，它将部署你的机器和配置你的云。完成后，conjure-up 将展示一个摘要屏幕，它包含一些链接，你可以用你的终端去浏览各种感兴趣的内容：

浏览日志

现在，Graylog 已经部署和配置完成，我们可以看一下采集到的一些数据。默认情况下，filebeat 应用程序将从 Kubernetes 的 master 和 worker 中转发系统日志（ /var/log/*.log ）和容器日志（/var/log/containers/*.log）到 graylog 中。

记住如下的 apache2 的地址和 graylog 的 admin 密码：

juju status --format yaml apache2/0 | grep public-address
 public-address: <your-apache2-ip>
juju run-action --wait graylog/0 show-admin-password
 admin-password: <your-graylog-password>

在浏览器中输入 http://<your-apache2-ip> ，然后以管理员用户名（admin）和密码（）登入。

注意： 如果这个界面不可用，请等待大约 5 分钟时间，以便于配置的反向代理生效。

登入后，顶部的 “Sources” 选项卡可以看到从 K8s 的 master 和 workers 中收集日志的概述：

通过点击 “System / Inputs” 选项卡深入这些日志，选择 “Show received messages” 查看 filebeat 的输入：

在这里，你可以应用各种过滤或者设置 Graylog 仪表板去帮助识别大多数比较重要的事件。查看 Graylog Dashboard 文档，可以了解如何定制你的视图的详细资料。

浏览指标

我们的部署通过 grafana 仪表板提供了两种类型的指标：系统指标，包括像 K8s master 和 worker 的 CPU /内存/磁盘使用情况，以及集群指标，包括像从 K8s cAdvisor 端点上收集的容器级指标。

记住如下的 grafana 的地址和 admin 密码：

juju status --format yaml grafana/0 | grep public-address
 public-address: <your-grafana-ip>
juju run-action --wait grafana/0 get-admin-password
 password: <your-grafana-password>

在浏览器中输入 http://<your-grafana-ip>:3000，输入管理员用户（admin）和密码（）登入。成功登入后，点击 “Home” 下拉框，选取 “Kubernetes Metrics (via Prometheus)” 去查看集群指标仪表板：

我们也可以通过下拉框切换到 “Node Metrics (via Telegraf) ” 去查看 K8s 主机的系统指标。

另一种方法

正如在文章开始的介绍中提到的，我喜欢用 conjure-up 的向导去完成像 Kubernetes 这种复杂软件的部署。现在，我们来看一下 conjure-up 的另一种方法，你可能希望去看到实现相同结果的一些命令行的方法。还有其它的可能已经部署了前面的 CDK，并想去扩展使用上述的 Graylog/Prometheus 组件。不管什么原因你既然看到这了，既来之则安之，继续向下看吧。

支持 conjure-up 的工具是 Juju。CDK spell 所做的一切，都可以使用 juju 命令行来完成。我们来看一下，如何一步步完成这些工作。

从 Scratch 中启动

如果你使用的是 Linux，安装 Juju 很简单，命令如下：

sudo snap install juju --classic

对于 macOS，Juju 也可以从 brew 中安装：

brew install juju

现在为你选择的云配置一个控制器。你或许会被提示请求一个凭据（用户名密码）：

juju bootstrap

我们接下来需要基于 CDK 捆绑部署：

juju deploy canonical-kubernetes

从 CDK 开始

使用我们部署的 Kubernetes 集群，我们需要去添加 Graylog 和 Prometheus 所需要的全部应用程序：

## deploy graylog-related applications
juju deploy xenial/apache2
juju deploy xenial/elasticsearch
juju deploy xenial/filebeat
juju deploy xenial/graylog
juju deploy xenial/mongodb

## deploy prometheus-related applications
juju deploy xenial/grafana
juju deploy xenial/prometheus
juju deploy xenial/telegraf

现在软件已经部署完毕，将它们连接到一起，以便于它们之间可以相互通讯：

## relate graylog applications
juju relate apache2:reverseproxy graylog:website
juju relate graylog:elasticsearch elasticsearch:client
juju relate graylog:mongodb mongodb:database
juju relate filebeat:beats-host kubernetes-master:juju-info
juju relate filebeat:beats-host kubernetes-worker:jujuu-info

## relate prometheus applications
juju relate prometheus:grafana-source grafana:grafana-source
juju relate telegraf:prometheus-client prometheus:target
juju relate kubernetes-master:juju-info telegraf:juju-info
juju relate kubernetes-worker:juju-info telegraf:juju-info

这个时候，所有的应用程序已经可以相互之间进行通讯了，但是我们还需要多做一点配置（比如，配置 apache2 反向代理、告诉 prometheus 如何从 K8s 中取数、导入到 grafana 仪表板等等）：

## configure graylog applications
juju config apache2 enable_modules="headers proxy_html proxy_http"
juju config apache2 vhost_http_template="$(base64 <vhost-tmpl>)"
juju config elasticsearch firewall_enabled="false"
juju config filebeat \
 logpath="/var/log/*.log /var/log/containers/*.log"
juju config filebeat logstash_hosts="<graylog-ip>:5044"
juju config graylog elasticsearch_cluster_name="<es-cluster>"

## configure prometheus applications
juju config prometheus scrape-jobs="<scraper-yaml>"
juju run-action --wait grafana/0 import-dashboard \
 dashboard="$(base64 <dashboard-json>)"

以上的步骤需要根据你的部署来指定一些值。你可以用与 conjure-up 相同的方法得到这些：

• <vhost-tmpl>： 从 github 获取我们的示例 模板
• <graylog-ip>： juju run --unit graylog/0 'unit-get private-address'
• <es-cluster>： juju config elasticsearch cluster-name
• <scraper-yaml>： 从 github 获取我们的示例 scraper ；[K8S_PASSWORD][20] 和 [K8S_API_ENDPOINT][21] substitute 的正确值
• <dashboard-json>： 从 github 获取我们的 主机 和 k8s 仪表板

最后，发布 apache2 和 grafana 应用程序，以便于可以通过它们的 web 界面访问：

## expose relevant endpoints
juju expose apache2
juju expose grafana

现在我们已经完成了所有的部署、配置、和发布工作，你可以使用与上面的浏览日志和浏览指标部分相同的方法去查看它们。

总结

我的目标是向你展示如何去部署一个 Kubernetes 集群，很方便地去监视它的日志和指标。无论你是喜欢向导的方式还是命令行的方式，我希望你清楚地看到部署一个监视系统并不复杂。关键是要搞清楚所有部分是如何工作的，并将它们连接到一起工作，通过断开/修复/重复的方式，直到它们每一个都能正常工作。

这里有一些像 conjure-up 和 Juju 一样非常好的工具。充分发挥这个生态系统贡献者的专长让管理大型软件变得更容易。从一套可靠的应用程序开始，按需定制，然后投入到工作中！

大胆去尝试吧，然后告诉我你用的如何。你可以在 Freenode IRC 的 #conjure-up 和 #juju 中找到像我这样的爱好者。感谢阅读！

关于作者

Kevin 在 2014 年加入 Canonical 公司，他专注于复杂软件建模。他在 Juju 大型软件团队中找到了自己的位置，他的任务是将大数据和机器学习应用程序转化成可重复的（可靠的）解决方案。

via: https://insights.ubuntu.com/2018/01/16/monitor-your-kubernetes-cluster/

作者：Kevin Monroe 译者：qhwdw 校对：wxy

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

Google 的工程总监 Chen Goldberg 在最近的奥斯汀 KubeCon 和 CloudNativeCon上说，Kubernetes 的扩展能力是它的秘密武器。

在建立帮助工程师提高工作效率的工具的竞赛中，Goldberg 谈到他曾经领导过一个开发这样一个平台的团队。尽管平台最初有用，但它无法扩展，并且修改也很困难。

幸运的是，Goldberg 说，Kubernetes 没有这些问题。首先，Kubernetes 是一个自我修复系统，因为它使用的控制器实现了“ 协调环 Reconciliation Loop ”。在协调环中，控制器观察系统的当前状态并将其与所需状态进行比较。一旦它确定了这两个状态之间的差异，它就会努力实现所需的状态。这使得 Kubernetes 非常适合动态环境。

3 种扩展 Kubernetes 的方式

Goldberg 然后解释说，要建立控制器，你需要资源，也就是说，你需要扩展 Kubernetes。有三种方法可以做到这一点，从最灵活（但也更困难）到最简单的依次是：使用 Kube 聚合器、使用 API​​ 服务器构建器或创建 自定义资源定义 Custom Resource Definition （CRD）。

后者甚至可以使用极少的代码来扩展 Kubernetes 的功能。为了演示它是如何完成的，Goggle 软件工程师 Anthony Yeh 上台展示了为 Kubernetes 添加一个状态集。 （状态集对象用于管理有状态应用，即需要存储应用状态的程序，跟踪例如用户身份及其个人设置。）使用 catset，在一个 100 行 JavaScript 的文件中实现的 CRD，Yeh 展示了如何将状态集添加到 Kubernetes 部署中。之前的扩展不是 CRD，需要 24 个文件和 3000 多行代码。

为解决 CRD 可靠性问题，Goldberg 表示，Kubernetes 已经启动了一项认证计划，允许公司在 Kubernetes 社区注册和认证其扩展。在一个月内，已有 30 多家公司报名参加该计划。

Goldberg 继续解释 Kubernetes 的可扩展性如何成为今年 KubeCon 的热门话题，以及 Google 和 IBM 如何构建一个使用 CRD 管理和保护微服务的平台。或者一些开发人员如何将机器学习带入 Kubernetes，另外展示开放服务代理以及在混合设置上的服务消费。

Goldberg 总结说，可扩展性是种增能。而且，Kubernetes 的可扩展性使其成为开发者的通用平台，并且易于使用，这使得他们可以运行任何应用程序。

你可以在下面观看整个视频：

via: https://www.linux.com/blog/event/kubecon/2018/2/3-ways-extend-power-kubernetes

作者：PAUL BROWN 译者：geekpi 校对：wxy

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

在我刚开始学习 Kubernetes（大约是一年半以前吧？）时，我真的不明白为什么应该去关注它。

在我使用 Kubernetes 全职工作了三个多月后，我才逐渐明白了为什么我应该使用它。（我距离成为一个 Kubernetes 专家还很远！）希望这篇文章对你理解 Kubernetes 能做什么会有帮助！

我将尝试去解释我对 Kubernetes 感兴趣的一些原因，而不去使用 “ 原生云 cloud native ”、“ 编排系统 orchestration ”、“ 容器 container ”，或者任何 Kubernetes 专用的术语 :)。我去解释的这些观点主要来自一位 Kubernetes 操作者/基础设施工程师，因为，我现在的工作就是去配置 Kubernetes 和让它工作的更好。

我不会去尝试解决一些如 “你应该在你的生产系统中使用 Kubernetes 吗？”这样的问题。那是非常复杂的问题。（不仅是因为“生产系统”根据你的用途而总是有不同的要求）

Kubernetes 可以让你无需设置一台新的服务器即可在生产系统中运行代码

我首次被说教使用 Kubernetes 是与我的伙伴 Kamal 的下面的谈话：

大致是这样的：

• Kamal： 使用 Kubernetes 你可以通过一条命令就能设置一台新的服务器。
• Julia： 我觉得不太可能吧。
• Kamal： 像这样，你写一个配置文件，然后应用它，这时候，你就在生产系统中运行了一个 HTTP 服务。
• Julia： 但是，现在我需要去创建一个新的 AWS 实例，明确地写一个 Puppet 清单，设置服务发现，配置负载均衡，配置我们的部署软件，并且确保 DNS 正常工作，如果没有什么问题的话，至少在 4 小时后才能投入使用。
• Kamal: 是的，使用 Kubernetes 你不需要做那么多事情，你可以在 5 分钟内设置一台新的 HTTP 服务，并且它将自动运行。只要你的集群中有空闲的资源它就能正常工作！
• Julia: 这儿一定是一个“坑”。

这里有一种陷阱，设置一个生产用 Kubernetes 集群（在我的经险中）确实并不容易。（查看 Kubernetes 艰难之旅 中去开始使用时有哪些复杂的东西）但是，我们现在并不深入讨论它。

因此，Kubernetes 第一个很酷的事情是，它可能使那些想在生产系统中部署新开发的软件的方式变得更容易。那是很酷的事，而且它真的是这样，因此，一旦你使用一个运作中的 Kubernetes 集群，你真的可以仅使用一个配置文件就在生产系统中设置一台 HTTP 服务（在 5 分钟内运行这个应用程序，设置一个负载均衡，给它一个 DNS 名字，等等）。看起来真的很有趣。

对于运行在生产系统中的代码，Kubernetes 可以提供更好的可见性和可管理性

在我看来，在理解 etcd 之前，你可能不会理解 Kubernetes 的。因此，让我们先讨论 etcd！

想像一下，如果现在我这样问你，“告诉我你运行在生产系统中的每个应用程序，它运行在哪台主机上？它是否状态很好？是否为它分配了一个 DNS 名字？”我并不知道这些，但是，我可能需要到很多不同的地方去查询来回答这些问题，并且，我需要花很长的时间才能搞定。我现在可以很确定地说不需要查询，仅一个 API 就可以搞定它们。

在 Kubernetes 中，你的集群的所有状态 – 运行中的应用程序 (“pod”)、节点、DNS 名字、 cron 任务、 等等 —— 都保存在一个单一的数据库中（etcd）。每个 Kubernetes 组件是无状态的，并且基本是通过下列方式工作的：

• 从 etcd 中读取状态（比如，“分配给节点 1 的 pod 列表”）
• 产生变化（比如，“在节点 1 上运行 pod A”）
• 更新 etcd 中的状态（比如，“设置 pod A 的状态为 ‘running’”）

这意味着，如果你想去回答诸如 “在那个可用区中有多少台运行着 nginx 的 pod？” 这样的问题时，你可以通过查询一个统一的 API（Kubernetes API）去回答它。并且，你可以在每个其它 Kubernetes 组件上运行那个 API 去进行同样的访问。

这也意味着，你可以很容易地去管理每个运行在 Kubernetes 中的任何东西。比如说，如果你想要：

• 部署实现一个复杂的定制的部署策略（部署一个东西，等待 2 分钟，部署 5 个以上，等待 3.7 分钟，等等）
• 每当推送到 github 上一个分支，自动化 启动一个新的 web 服务器
• 监视所有你的运行的应用程序，确保它们有一个合理的内存使用限制。

这些你只需要写一个程序与 Kubernetes API（“controller”）通讯就可以了。

另一个关于 Kubernetes API 的令人激动的事情是，你不会局限于 Kubernetes 所提供的现有功能！如果对于你要部署/创建/监视的软件有你自己的方案，那么，你可以使用 Kubernetes API 去写一些代码去达到你的目的！它可以让你做到你想做的任何事情。

即便每个 Kubernetes 组件都“挂了”，你的代码将仍然保持运行

关于 Kubernetes 我（在各种博客文章中 :)）承诺的一件事情是，“如果 Kubernetes API 服务和其它组件‘挂了’也没事，你的代码将一直保持运行状态”。我认为理论上这听起来很酷，但是我不确定它是否真是这样的。

到目前为止，这似乎是真的！

我已经断开了一些正在运行的 etcd，发生了这些情况：

1. 所有的代码继续保持运行状态
2. 不能做 新的 事情（你不能部署新的代码或者生成变更，cron 作业将停止工作）
3. 当它恢复时，集群将赶上这期间它错过的内容

这样做意味着如果 etcd 宕掉，并且你的应用程序的其中之一崩溃或者发生其它事情，在 etcd 恢复之前，它不能够恢复。

Kubernetes 的设计对 bug 很有弹性

与任何软件一样，Kubernetes 也会有 bug。例如，到目前为止，我们的集群控制管理器有内存泄漏，并且，调度器经常崩溃。bug 当然不好，但是，我发现 Kubernetes 的设计可以帮助减轻它的许多核心组件中的错误的影响。

如果你重启动任何组件，将会发生：

• 从 etcd 中读取所有的与它相关的状态
• 基于那些状态（调度 pod、回收完成的 pod、调度 cron 作业、按需部署等等），它会去做那些它认为必须要做的事情

因为，所有的组件并不会在内存中保持状态，你在任何时候都可以重启它们，这可以帮助你减轻各种 bug 的影响。

例如，如果在你的控制管理器中有内存泄露。因为，控制管理器是无状态的，你可以每小时定期去重启它，或者，在感觉到可能导致任何不一致的问题发生时重启它。又或者，在调度器中遇到了一个 bug，它有时忘记了某个 pod，从来不去调度它们。你可以每隔 10 分钟来重启调度器来缓减这种情况。（我们并不会这么做，而是去修复这个 bug，但是，你可以这样做 :））

因此，我觉得即使在它的核心组件中有 bug，我仍然可以信任 Kubernetes 的设计可以让我确保集群状态的一致性。并且，总在来说，随着时间的推移软件质量会提高。唯一你必须去操作的有状态的东西就是 etcd。

不用过多地讨论“状态”这个东西 —— 而我认为在 Kubernetes 中很酷的一件事情是，唯一需要去做备份/恢复计划的东西是 etcd （除非为你的 pod 使用了持久化存储的卷）。我认为这样可以使 Kubernetes 运维比你想的更容易一些。

在 Kubernetes 之上实现新的分布式系统是非常容易的

假设你想去实现一个分布式 cron 作业调度系统！从零开始做工作量非常大。但是，在 Kubernetes 里面实现一个分布式 cron 作业调度系统是非常容易的！（仍然没那么简单，毕竟它是一个分布式系统）

我第一次读到 Kubernetes 的 cron 作业控制器的代码时，我对它是如此的简单感到由衷高兴。去读读看，其主要的逻辑大约是 400 行的 Go 代码。去读它吧！ => cronjob\_controller.go <=

cron 作业控制器基本上做的是：

• 每 10 秒钟：

  • 列出所有已存在的 cron 作业
  • 检查是否有需要现在去运行的任务
  • 如果有，创建一个新的作业对象去调度，并通过其它的 Kubernetes 控制器实际运行它
  • 清理已完成的作业
  • 重复以上工作

Kubernetes 模型是很受限制的（它有定义在 etcd 中的资源模式，控制器读取这个资源并更新 etcd），我认为这种相关的固有的/受限制的模型，可以使它更容易地在 Kubernetes 框架中开发你自己的分布式系统。

Kamal 给我说的是 “Kubernetes 是一个写你自己的分布式系统的很好的平台” ，而不是“ Kubernetes 是一个你可以使用的分布式系统”，并且，我觉得它真的很有意思。他做了一个 为你推送到 GitHub 的每个分支运行一个 HTTP 服务的系统 的原型。这花了他一个周末的时间，大约 800 行 Go 代码，我认为它真不可思议！

Kubernetes 可以使你做一些非常神奇的事情（但并不容易）

我一开始就说 “kubernetes 可以让你做一些很神奇的事情，你可以用一个配置文件来做这么多的基础设施，它太神奇了”。这是真的！

为什么说 “Kubernetes 并不容易”呢？是因为 Kubernetes 有很多部分，学习怎么去成功地运营一个高可用的 Kubernetes 集群要做很多的工作。就像我发现它给我了许多抽象的东西，我需要去理解这些抽象的东西才能调试问题和正确地配置它们。我喜欢学习新东西，因此，它并不会使我发狂或者生气，但是我认为了解这一点很重要 :）

对于 “我不能仅依靠抽象概念” 的一个具体的例子是，我努力学习了许多 Linux 上网络是如何工作的，才让我对设置 Kubernetes 网络稍有信心，这比我以前学过的关于网络的知识要多很多。这种方式很有意思但是非常费时间。在以后的某个时间，我或许写更多的关于设置 Kubernetes 网络的困难/有趣的事情。

或者，为了成功设置我的 Kubernetes CA，我写了一篇 2000 字的博客文章，述及了我不得不学习 Kubernetes 不同方式的 CA 的各种细节。

我觉得，像 GKE （Google 的 Kubernetes 产品) 这样的一些监管的 Kubernetes 的系统可能更简单，因为，他们为你做了许多的决定，但是，我没有尝试过它们。

via: https://jvns.ca/blog/2017/10/05/reasons-kubernetes-is-cool/

作者：Julia Evans 译者：qhwdw 校对：wxy

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

为什么选择 Docker 和 Kubernetes 呢？

容器允许我们构建、发布和运行分布式应用。它们使应用程序摆脱了机器限制，可以让我们以一定的方式创建一个复杂的应用程序。

使用容器编写应用程序可以使开发、QA 更加接近生产环境（如果你努力这样做的话）。通过这样做，可以更快地发布修改，并且可以更快地测试整个系统。

Docker 这个容器式平台就是为此为生，可以使软件独立于云提供商。

但是，即使使用容器，移植应用程序到任何一个云提供商（或私有云）所需的工作量也是不可忽视的。应用程序通常需要自动伸缩组、持久远程磁盘、自动发现等。但是每个云提供商都有不同的机制。如果你想使用这些功能，很快你就会变的依赖于云提供商。

这正是 Kubernetes 登场的时候。它是一个容器 编排 orchestration 系统，它允许您以一定的标准管理、缩放和部署应用程序的不同部分，并且成为其中的重要工具。它的可移植抽象层兼容主要云的提供商（Google Cloud，Amazon Web Services 和 Microsoft Azure 都支持 Kubernetes）。

可以这样想象一下应用程序、容器和 Kubernetes。应用程序可以视为一条身边的鲨鱼，它存在于海洋中（在这个例子中，海洋就是您的机器）。海洋中可能还有其他一些宝贵的东西，但是你不希望你的鲨鱼与小丑鱼有什么关系。所以需要把你的鲨鱼（你的应用程序）移动到一个密封的水族馆中（容器）。这很不错，但不是特别的健壮。你的水族馆可能会被打破，或者你想建立一个通道连接到其他鱼类生活的另一个水族馆。也许你想要许多这样的水族馆，以防需要清洁或维护……这正是应用 Kubernetes 集群的作用。

进化到 Kubernetes

主流云提供商对 Kubernetes 提供了支持，从开发环境到生产环境，它使您和您的团队能够更容易地拥有几乎相同的环境。这是因为 Kubernetes 不依赖专有软件、服务或基础设施。

事实上，您可以在您的机器中使用与生产环境相同的部件启动应用程序，从而缩小了开发和生产环境之间的差距。这使得开发人员更了解应用程序是如何构建在一起的，尽管他们可能只负责应用程序的一部分。这也使得在开发流程中的应用程序更容易的快速完成测试。

如何使用 Kubernetes 工作？

随着更多的人采用 Kubernetes，新的问题出现了；应该如何针对基于集群环境进行开发？假设有 3 个环境，开发、质量保证和生产， 他们如何适应 Kubernetes？这些环境之间仍然存在着差异，无论是在开发周期（例如：在运行中的应用程序中我的代码的变化上花费时间）还是与数据相关的（例如：我不应该在我的质量保证环境中测试生产数据，因为它里面有敏感信息）。

那么，我是否应该总是在 Kubernetes 集群中编码、构建映像、重新部署服务，在我编写代码时重新创建部署和服务？或者，我是否不应该尽力让我的开发环境也成为一个 Kubernetes 集群（或一组集群）呢？还是，我应该以混合方式工作？

用本地集群进行开发

如果继续我们之前的比喻，上图两边的洞表示当使其保持在一个开发集群中的同时修改应用程序的一种方式。这通常通过卷来实现

Kubernetes 系列

本 Kubernetes 系列资源是开源的，可以在这里找到： https://github.com/red-gate/ks 。

我们写这个系列作为以不同的方式构建软件的练习。我们试图约束自己在所有环境中都使用 Kubernetes，以便我们可以探索这些技术对数据和数据库的开发和管理造成影响。

这个系列从使用 Kubernetes 创建基本的 React 应用程序开始，并逐渐演变为能够覆盖我们更多开发需求的系列。最后，我们将覆盖所有应用程序的开发需求，并且理解在数据库生命周期中如何最好地迎合容器和集群。

以下是这个系列的前 5 部分：

1. ks1：使用 Kubernetes 构建一个 React 应用程序
2. ks2：使用 minikube 检测 React 代码的更改
3. ks3：添加一个提供 API 的 Python Web 服务器
4. ks4：使 minikube 检测 Python 代码的更改
5. ks5：创建一个测试环境

本系列的第二部分将添加一个数据库，并尝试找出最好的方式来开发我们的应用程序。

通过在各种环境中运行 Kubernetes，我们被迫在解决新问题的同时也尽量保持开发周期。我们不断尝试 Kubernetes，并越来越习惯它。通过这样做，开发团队都可以对生产环境负责，这并不困难，因为所有环境（从开发到生产）都以相同的方式进行管理。

下一步是什么？

我们将通过整合数据库和练习来继续这个系列，以找到使用 Kubernetes 获得数据库生命周期的最佳体验方法。

这个 Kubernetes 系列是由 Redgate 研发部门 Foundry 提供。我们正在努力使数据和容器的管理变得更加容易，所以如果您正在处理数据和容器，我们希望听到您的意见，请直接联系我们的开发团队。 [email protected]

我们正在招聘。您是否有兴趣开发产品、创建未来技术 并采取类似创业的方法（没有风险）？看看我们的软件工程师 - 未来技术的角色吧，并阅读更多关于在 英国剑桥的 Redgate 工作的信息。

via: https://medium.com/ingeniouslysimple/adopting-kubernetes-step-by-step-f93093c13dfe

作者：santiago arias 译者：aiwhj 校对：wxy

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