有很多团队在使用kubernetes的时候是将一个namespace当成一个租户的，所以对namespace的权限控制，资源控制就很重要了，你总是会担心你的某个租户使用的资源就超出了应有的配额。幸运的是kubernetes本身就为我们提供了解决这一问题的工具：资源配额控制器(ResourceQuotaController)

资源配额控制器确保了指定的资源对象始终不会超过配置的资源，能够有效的降低整个系统宕机的机率，增强系统的鲁棒性，对整个集群的稳定性有非常重要的作用。

一转眼都已经过了龙抬头的日子了，可能你自己没注意到，要是仔细一算的话，2018年已经过了1/4了，是不是今年的规划还没提上日程呢？总之，咱们还是需要撸起袖子加油继续干啊~~~

今天的文章是总结我们知识星球在本周的一些精华的分享内容，同时，也欢迎大家加入我们的【微信群】和【知识星球】共同探讨，共同进步。

一般情况下我们部署的 POD 是通过集群自动调度选择某个节点的，默认情况下调度器考虑的是资源足够，并且负载尽量平均，但是有的时候我们需要能够更加细粒度的去控制 POD 的调度，比如我们内部的一些服务 gitlab 之类的也是跑在Kubernetes集群上的，我们就不希望对外的一些服务和内部的服务跑在同一个节点上了，害怕内部服务对外部的服务产生影响；有的时候呢我们两个服务直接交流比较频繁，又希望能够将这两个服务的 POD 调度到同样的节点上。这就需要用到 Kubernetes 里面的一个概念：亲和性，亲和性主要分为两类：nodeAffinity和podAffinity。

前面我们为Hugo集成了Algolia搜索插件，要让我们的网站具备博客的基本功能的话，一般情况下评论也是非常需要的，评论承载着作者与读者之间交流的桥梁，所以我们可以看到市面上有很多单独的评论服务，比如最出名的disqus，国内也有之前比较出名的多说(现在已经关闭)、有言等等，要使用他们非常简单，只需要嵌入一些简单的代码即刻开启移动社交评论 服务。不是这些服务不好，只是觉得稍微有点笨重，这里我们使用一个基于GitHub Issues的轻量级评论系统：Gitment。

前面在k8s技术圈微信群里面有朋友问到如何在容器中获取 POD 的基本信息，其实kubernetes原生就提供了支持的，那就是Downward API。

Hugo是由 Steve Francis 大神(http://spf13.com/)基于Go语言开发的静态网站构建工具。没错你现在看到的本博客就是基于Hugo的，使用 Hugo 创建一个网站是非常简单的，基本上没有什么门槛，官方还提供了大量的主题供你选择，你只需要专心写的文章就行。不过有个问题是搜索，我们知道搜索属于动态行为了，如何给静态网站增加搜索功能呢？当然我们可以使用Google的站内搜索功能，Hugo 官方也提供了一些开源的和商业的解决方案，今天我们要介绍的就是一个非常优秀的商业解决方案：Algolia。

我们经常都需要为我们的应用程序配置一些特殊的数据，比如密钥、Token 、数据库连接地址或者其他私密的信息。你的应用可能会使用一些特定的配置文件进行配置，比如settings.py文件，或者我们可以在应用的业务逻辑中读取环境变量或者某些标志来处理配置信息。

当然你可以直接将这些应用配置信息直接硬编码到你的应用程序中去，对于一个小型的应用，这或许是可以接受的，但是，对于一个相对较大的应用程序或者微服务的话，硬编码就会变得难以管理了。比如你现在有10个微服务，都连接了数据库A，如果现在需要更改数据库A的连接地址的话，就需要修改10个地方，显然这是难以忍受的。

我们前面介绍了很多关于kubernetes本身的操作，但是对于如何写一个完整的kubernetes应用还没有介绍过。在这篇文章中我们将介绍如何一步一步的写一个kubernetes的golang服务。

Docker的口号是 Build,Ship,and Run Any App,Anywhere，在我们使用 Docker 的大部分时候，的确能感觉到其优越性，但是往往在我们 Build 一个应用的时候，是将我们的源代码也构建进去的，这对于类似于 golang 这样的编译型语言肯定是不行的，因为实际运行的时候我只需要把最终构建的二进制包给你就行，把源码也一起打包在镜像中，需要承担很多风险，即使是脚本语言，在构建的时候也可能需要使用到一些上线的工具，这样无疑也增大了我们的镜像体积。

在之前的文章中，我们一直在讨论如何使用kubernetes，很多时候我们知道怎么使用kubectl命令行工具来启动一个POD，也看到我们在安装kubernetes 过程中使用了一些 YAML 文件来创建，但是发现很多朋友对 YAML 文件来创建一个 POD 还是非常陌生。所以我们来简单看看 YAML 文件是如何工作的，并使用 YAML 文件来定义一个 kubernetes pod，然后再来定义一个 kubernetes deployment吧。

Helm这个东西其实早有耳闻，但是一直没有用在生产环境，而且现在对这货的评价也是褒贬不一。正好最近需要再次部署一套测试环境，对于单体服务，部署一套测试环境我相信还是非常快的，但是对于微服务架构的应用，要部署一套新的环境，就有点折磨人了，微服务越多、你就会越绝望的。虽然我们线上和测试环境已经都迁移到了kubernetes环境，但是每个微服务也得维护一套yaml文件，而且每个环境下的配置文件也不太一样，部署一套新的环境成本是真的很高。如果我们能使用类似于yum的工具来安装我们的应用的话是不是就很爽歪歪了啊？Helm就相当于kubernetes环境下的yum包管理工具。

最近在kubernetes上安装 sentry 的时候，我将sentry需要运行的3个服务放到同一个POD中的，WEB、Celery Worker、Crontab 分别用一个独立的容器来运行的，但是这三个容器需要用到环境变量基本上都是一样的，比如数据库的配置、消息队列的配置，这样就造成一个问题是我需要把完全一模一样的环境配置复制3份，因为3个容器都需要使用，这样如果需要更改的话也要改3个地方。幸好kubernetes给我们提供了一种新的特性：PodPreset，该对象用来在 Pod 创建的时候向 Pod 中注入某些特定信息，可以包括 secret、volume、volume mount 和环境变量等。