Kubernetes的十大使用技巧

1. bash针对kubectl命令的自动补充
这多是在使用Kubernetes过程当中最容易作的事，但它也是其中一个最有用的。要添加自动补充功能，若是使用bash，只需执行如下命令：

echo "source <(kubectl completion bash)" >> ~/.bashrc

它将添加自动补全命令到你的.bashrc文件。所以每一个你打开的shell窗口都支持该功能。我发现自动补全对一些长的参数，好比--all-namespaces特别有用。
2. 给每一个namespace添加默认的内存和CPU限额
是人就会犯错。咱们假定某人写了个应用，他每秒就会打开一个数据库链接，可是不会关闭。这样集群中就有了一个内存泄漏的应用。假定咱们把该应用部署到了没有限额设置的集群，那么该应用就会crash掉一个节点。
为了不这种状况，Kubernetes容许为每一个namespace设置默认的限额。要作到这很简单，咱们只需建立一个limit range 的 yaml 并应用到特定namespace。如下是一个例子：

apiVersion: v1  
 kind: LimitRange  
 metadata:  
   name: mem-limit-range  
 spec:  
   limits:  
   - default:  
       memory: 512Mi  
     defaultRequest:  
       memory: 256Mi  
     type: Container

将该内容建立一个yaml文件并将它应用到任何你想应用的namespace，例如namespace limit-example。使用了限额后，任何部署到该namespace的应用，假如没有主动设置限额，都将获得一个默认的512Mi的内存限额。
3. kebelet能够帮我清理掉Docker镜像吗
这是kubelet默认已实现的功能。若是kubelet启动时没有设置flag，当/var/lib/docker目录到达90%的容量时，它就会自动进行垃圾回收。这是极好的，可是针对inode阈值它没有默认设置（Kubernetes 1.7以前）。
你可能会遇到/var/lib/docker只使用了50%磁盘空间，可是inode所有用光的状况。这可能会引发工做节点各类各样的问题。若是你运行的kubelet版本在1.4到1.6之间，那你得给kubelet添加如下flag：

--eviction-hard
=memory.available<100Mi,nodefs.available<10%,nodefs.inodesFree<5%

若是kubelet版本是1.7或更高，它默认就有这个配置。1.6默认不会监控inode的使用率，因此得添加那个flag来解决这个问题。
4. minikube虽然是mini，可是本地使用功能强大
minikube绝对是本地启动Kubernetes集群最容易的方式。你只需遵循这个[1]指南去下载全部东西。
一旦全部组件安装完毕，你只需运行以下命令：

minikube start

待命令执行完毕，你本地就有一个运行的Kubernetes集群了。
当你想在本地构建一个应用并在本地运行时，有一个技巧。当你在本地构建一个Docker镜像时，若是不运行其它命令，你的镜像将被构建在你的本地计算机。
为了使你构建的Docker镜像可以直接push到本地Kubernetes集群，你须要使用以下命令告知Docker机器：

eval $(minikube docker-env)

这将使你能直接推送本地构建的应用到你的本地集群。
5. 不要将kubectl的权限开放给全部人
这多是一个明摆着的事，可是当多个团队部署应用到同一个集群时，而这种场景就是Kubernetes的目标，不要开放一个通用的kubectl给每一个人。个人建议是基于namespace来隔离团队，而后使用RBAC策略来限制能且仅能访问那个namespace。
在权限被控制以后，你可能会变得疯狂，好比只能基于Pod来读取，建立和删除Pod。可是其中一个最须要作的事是只能访问管理员凭证，这样能够隔离谁能管理集群，而谁只能在集群上部署应用。
这个话题我期待着后续单独开一篇博客来进行更详细的分析。
6. Pod中断预算（Pod Disruption Budgets）是你的朋友
在Kubernetes集群中咱们如何确保应用零宕机？
PodDisruptionBudgetPodDisruptionBudgetPodDisruptionBudget
集群会更新。节点会打上drain标签且Pod会被移除，这无法避免。因此咱们应该针对每一个deployment都设置一个PDB，保证至少有一个实例。咱们可使用一个简单的yaml来建立一个PDB，应用到集群里，并使用标签选择器来肯定这个PDB覆盖了哪些资源。
注意：PDB只对自愿中断的资源负责，某些如硬件失败这种错误，PDB没法起做用。
PDB例子以下：

apiVersion: policy/v1beta1  
 kind: PodDisruptionBudget  
 metadata:  
   name: app-a-pdb  
 spec:  
   minAvailable: 2  
   selector:  
       matchLabels:  
         app: app-a

两个最须要关注的字段是matchLabels和minAvailable。
matchLabels字段用来肯定是否一个deployment能够关联到这个PDB。
例如，若是我有一个带标签app:app-a的deployment，和另外一个带标签app:app-b的deployment，例子中的PDB将只对第一个deployment起做用。
minAvailable字段是Kubernetes在某些场景下，好比node被打上drain标签时，进行操做的依据。假设app-a运行在node1上，若是node1被打上了drain标签，那么kubernetes只会清除那些有至少2个实例的app-a。
这容许你在任什么时候候均可控制运行的实例数。
7. 你的APP还活着且可用吗
Kubernetes容许咱们定义探针，供kubelet确认咱们的Pod和APP是不是健康的。
Kubernetes提供了两种类型的探针，Readiness探针和Liveness探针。
Readiness探针用来确认容器是否可接受流量。
Liveness探针用来确认容器是不是健康的，或者须要被重启。
这些配置能够很容易得追加到deployment的yaml，而且能够自定义超时时间，重试次数，延时时间等。须要更进一步得了解如何使用它们的，请阅读此文[2]。
8. 给全部事物都打上标签
标签是Kubernetes的其中一个基石。它使得对象和对象之间保持松耦合，且容许咱们根据标签来查询对象。你甚至可使用go client根据标签来监控事件。
你几乎能够用标签作任何事，其中一个极佳的例子是同一集群中的多个环境。
咱们假定你在dev和qa环境使用了相同的集群。这说明你将在dev和qa环境同时运行一个app-a应用。
为了达到这个目的，最简单的方式是使用service对象，其中一个选择带标签app:app-a和environment:dev的Pod，而另外一个，则选择带标签app:app-a和environment:qa的Pod。
这样作的好处是，两个相同的APP，每个有不一样的endpoint，这样就支持同时测试。
9. 主动清理
Kubernetes是一个很是很是强大的系统，可是和其它系统同样，它最终也会陷入混乱。kubelet必须进行任何你告诉它的校验，同时它也进行本身的校验。
固然，Kubernetes有一个服务没法链接了，系统是不会挂掉的，由于它支持扩缩容。可是一个服务一旦扩大到成千上万个endpoint，那么kubelet就会一会儿陷入瘫痪。
简单的说，不论你由于什么理由须要删除一个deployment（或者其它东西），你都必须确保清理干净和它相关的一切东西。
10. 你热爱GO语言吗
最后一点是我我的以为最重要的：持续的学习GO语言。
Kubernetes是由GO编写的，它的全部插件也是用GO写的，他们甚至还编写了一个GO语言的客户端。client-go可用来作各类有趣的事。你能够用它根据本身的爱好扩展kubernetes。好比数据收集，部署引擎，或者一个简单的清理应用。
学习这个GO 客户端，并在Kubernetes中使用它，这是我给每一个使用Kubernetes的用户的最大建议。
原文连接：

1. https://kubernetes.io/docs/tasks/tools/install-minikube/

2. https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes

原文连接：https://hackernoon.com/top-10-kubernetes-tips-and-tricks-27528c2d0222