#kubernetes

本文是 Drone 系列文章的第三篇，在第一篇文章中我们介绍了如何在 Kubernetes 集群中使用 Helm 来快速安装 Drone，并且用 cert-manager 给 Drone 应用做了自动化 HTTPS，在第二篇文章中我们介绍了如何在 Drone 中使用 Pipeline 来自动化构建 Docker 镜像

本文我们将创建一个 Helm Chart 包，然后使用 Drone Pipeline 来进行自动部署或更新应用到 Kubernetes 集群中。

如果对 Helm 如何部署应用还不熟悉的，同样的，可以查看我们前面的 Helm 系列文章

本文是 Drone 系列文章的第二篇，在第一篇文章中我们介绍了如何在 Kubernetes 集群中使用 Helm 来快速安装 Drone，并且用 cert-manager 给 Drone 应用做了自动化 HTTPS。

本文我们将创建一个简单的 Golang 应用，通过 Drone 的 Pipeline 来自动化构建 Docker 镜像。

我们知道 CI/CD 是 devops 中最重要的环节，特别是对于现在的云原生应用，CI/CD 更是不可或缺的部分，对于 CI/CD 工具有很多优秀的开源工具，比如前面我们介绍的Jenkins以及gitlab ci都是非常流行常用的 CI/CD 工具，但是这两个工具整体使用来说有点陈旧和笨重，本文将为大家介绍一个比较热门的轻量级 CI/CD 开源工具：Drone，介绍如何将 Drone 和 Kubernetes 进行结合使用。

我们知道在使用 Kubernetes 的过程中，kubectl 工具可能是最常用的工具了（可能还没有之一），所以当我们花费大量的时间在使用 kubectl 上面的时候，那么我们就非常有必要去了解下如何高效的使用它了。

本文包含一系列提示和技巧，可以让你更加高效的使用 kubectl，同时还可以加深你对 Kubernetes 各方面工作原理的理解。

Kubernetes 提供了需要扩展其内置功能的方法，最常用的可能是自定义资源类型和自定义控制器了，除此之外，Kubernetes 还有一些其他非常有趣的功能，比如 admission webhooks 或者 initializers，这些也可以用于扩展 API，它们可以用于修改某些 Kubernetes 资源的基本行为，接下来我们来看看那些引入了 admission webhooks 的动态准入控制。

随着 kubernetes 的快速发展，很多应用都在往 kubernetes 上面迁移，现阶段对于无状态应用的迁移是非常容易做到的，但是对于有状态应用的迁移还是有一定门槛的，主要是有状态应用的运行方式各有不同，比如 MySQL、MongoDB、Redis 这些应用运行的方式方法都不太相同，特别是对于线上环境需要高可用的集群模式的时候，则差别就更大了，这就导致了有状态应用向 Kubernetes 的迁移必然进度会很慢。现在比较好的解决方案就是针对有状态应用开发对应的 Operator 应用，比如 prometheus-operator、etcd-operator 等等，关于 Operator 的开发，可以查看前面的一篇入门文章：Kubernetes Operator 快速入门教程 以了解更多信息。

同样的，对于 Elasticsearch 应用，现在官方也推出了基于 Kubernetes Operator 的应用：Elastic Cloud on Kubernetes (ECK)，用户可使用该产品在 Kubernetes 上配置、管理和运行 Elasticsearch 集群。

我们知道可以通过 RBAC 为操作 kubectl 的用户或组来进行权限控制，但是我们往往是通过 kubernetes 集群的超级管理员手动为这些用户进行分配的，并没有一个开箱即用的 kubectl 身份验证工具。

那么我们可以用什么办法来可以很方便的为用户进行授权访问 kubernetes 集群呢？

在 Kubernetes 的监控方案中我们经常会使用到一个Promethues Operator的项目，该项目可以让我们更加方便的去使用 Prometheus，而不需要直接去使用最原始的一些资源对象，比如 Pod、Deployment，随着 Prometheus Operator 项目的成功，CoreOS 公司开源了一个比较厉害的工具：Operator Framework，该工具可以让开发人员更加容易的开发 Operator 应用。

在本篇文章中我们会为大家介绍一个简单示例来演示如何使用 Operator Framework 框架来开发一个 Operator 应用。

kubernetes 集群资源监控之前可以通过 heapster 来获取数据，在 1.11 开始开始逐渐废弃 heapster 了，采用 metrics-server 来代替，metrics-server 是集群的核心监控数据的聚合器，它从 kubelet 公开的 Summary API 中采集指标信息，metrics-server 是扩展的 APIServer，依赖于kube-aggregator，因为我们需要在 APIServer 中开启相关参数。

由于课程中的集群版本是 v1.10.0，这个版本相对有点旧了，最新版本都已经 v1.14.x 了，为了尽量保证课程内容的更新度，所以我们需要将集群版本更新。我们的集群是使用的 kubeadm 搭建的，我们知道使用 kubeadm 搭建的集群来更新是非常方便的，但是由于我们这里版本跨度太大，不能直接从 1.10.x 更新到 1.14.x，kubeadm 的更新是不支持跨多个主版本的，所以我们现在是 1.10，只能更新到 1.11 版本了，然后再重 1.11 更新到 1.12…… 不过版本更新的方式方法基本上都是一样的，所以后面要更新的话也挺简单了，下面我们就先将集群更新到 v1.11.0 版本。

当 Kubernetes 中 Node 节点出现状态异常的情况下，节点上的 Pod 会被重新调度到其他节点上去，但是有的时候我们会发现节点 Down 掉以后，Pod 并不会立即触发重新调度，这实际上就是和 Kubelet 的状态更新机制密切相关的，Kubernetes 提供了一些参数配置来触发重新调度到嗯时间，下面我们来分析下 Kubelet 状态更新的基本流程。

上节课我们完成了最基本的流水线流程，接下来的工作就是来实现之前的具体 Pipeline 脚本了。