Kubernetes是基于 GO 编写的,所有的组件都是基于 GO 编写的,kubernetes甚至使用GO编写了一个客户端。学习使用 GO 语言编写的 Kubernetes 客户端并在 Kubernetes 中使用它,这是我对所以使用 Kubernetes 集群的朋友提出的最大的建议。
在Kubernetes中支持配置探针。kubelet使用探针来确定pod和应用程序是否健康。这里提供了两种类型来实现这一功能,Readiness探针和Liveiness探针。Readiness探针用于确定容器何时准备好接收流量。Liveiness探针用于确定容器是健康的还是需要重新启动。在deployment 的yaml中,可以直接定义Readiness 探针和Liveiness探针,还可以设置超时、重试和延迟等参数。
标签是Kubernetes的基础配置之一。它允许进群内资源与资源之间松散耦合,还允许基于标签进行查询。你甚至可以使用Kubernetes go客户端,根据标签查看事件。你几乎可以使用标签做任何事情,一个典型的例子是是同一个集群中存在多个环境。假设开发和QA使用相同的集群。这意味着你的集群可能同时进行QA和开发。要以一种简单的方式实现这一点,你必须使用服务对象,一个服务对象在app上执行标签select: app-a以及environment: dev,另一个服务对象在app上打上:app-a标签,但将环境从dev切换到QA。这将为您提供两个相同的应用程序,每个应用程序具有不同的端点,允许同时进行测试。
Kubernetes是一个非常强大的系统,但是就像任何系统一样,它也会出现阻塞。只有一个不连接其他任何服务的服务才不会让系统陷入停滞。当kubernetes规模较小时,几台或者几十台,可能不会有任何问题。但如果把服务扩大到上万,kubelet就会可是出现阻塞。因为Kubelet不仅会对你发出的指令进行校验,同时还要做内部检查。因此,切记,从现在开始,养成习惯。如果你需要删除deployment(或相关的任何内容),请确保用它清理了所有其他内容,比如service,volume等等,避免日后影响kubelet的查询效率。
如何保证在kubernetes集群中的应用程序总能正常运行?答案是使用PodDisruptionBudget控制器。在进行kubectl drain操作时,kubernetes会根据PodDisruptionBudget控制器判断应用POD集群数量,进而保证在业务不中断或业务SLA不降级的情况下进行应用POD销毁。PDB(PodDisruptionBudget)应该放在每个拥有一个以上实例的deployment上。我们可以使用简单yaml为集群创建PDB,并使用标签选择器确定PDB应该作用在哪些带有标签的资源上。注意:PDB只考虑主动中断,硬件故障之类的情况不在PDB考虑范围内。PDB可以参考如下例子:
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
name: app-a-pdb
spec:
minAvailable: 2
selector:
matchLabels:
app: app-a
在众多配置中,我们最需要关注两个选项是matchlabel和minAvailable部分。匹配标签是kubernetes查看部署是否附加到PDB。例如:如果我有一个带有标签app: app-a的部署和一个带有标签app: app-b的部署,那么示例PDB将只应用于第一个部署。minAvailable会在kubernetes在执行类似 kubectl drain 的操作时起作用。假设app-a正在节点1上运行,如果在节点1上执行drain,那么它将只驱逐app-a,即当前至少有2个app在运行。这让你可以控制在给定时间需要运行多少实例。
这可能是最简单也是使用Kubernetes时最有帮助的方法之一。要添加自动完成(如果使用bash),只需运行以下命令:
echo “source <(kubectl completion bash)” >> ~/.bashrc
这将在.bashrc中添加自动完成功能,这样无论何时打开shell,它都会启用它。你将会发现使用自动补全功能对于输入长指令来说是尤为方便的,尤其是当需要指定命名空间时。
人们总会犯错,这是常有的事。如果有人编写了一个应用程序,比方说,每秒打开一个数据库的连接,但是从来没有关闭它,这时就会导致在集群上的应用程序中出现内存泄漏。如果将它们部署到没有设置限制的集群中,则可能导致节点崩溃。为了防止这种情况,Kubernetes允许根据每个命名空间设置默认限制。要做到这一点,只需创建一个yaml来限制范围并将其应用于这个命名空间。下面是yaml的一个例子:
apiVersion: v1
kind: LimitRange
metadata:
name: mem-limit-range
spec:
limits:
- default:
memory: 512Mi
defaultRequest:
memory: 256Mi
type: Container
kubelet默认情况下已经做到了这一点。如果在启动kubelet时没有设置任何标志,那么当var/lib/docker达到90%的容量时,它将启动垃圾收集。这一功能非常贴心,但请注意,kubelet并没有为node节点设置默认阈值(在Kubernetes 1.7之前)。试想这种情况,你的/var/lib/docker可能只占用了50%的磁盘空间,但此时全部的物理机磁盘空间已经被占满。这会给你的容器服务带来很多问题。如果您目前正在使用的kubelet版本是1.4-1.6,那么你必须显式为kubelet添加如下标志。
--eviction-hard=memory.available<100Mi,nodefs.available<10%,nodefs.inodesFree<5%
这些配置在1.7或更高版本时是默认配置项。1.6版本默认情况下不监视 node 节点的资源利用率,因此添加该标志将解决这个问题。
Minikube绝对是本地运行Kubernetes集群最简单的方法了。一旦一切都安装好了,简单的命令就能运行它。
minikube start
这时我们将在本地运行一个 K8S 集群。当你想要在本地构建一个应用程序并在本地运行它时,这是有个技巧需要注意。如果你没有运行其他命令,当你执行docker build时,仍然会在物理机上构建一个映像。要让你的docker build将镜像push到本地kubernetes集群,你需要使用以下命令:
eval $(minikube docker-env)
这能让你在本地kubernetes集群上构建应用程序。
这可能说起来很简单,但是当多个团队部署应用到一个 kubernetes 集群时,情况就可能变得很复杂。切记不要把 kubectl 权限开放给每个人。个人建议是,根据命名空间来区分隔离每个团队,然后使用RBAC策略只允许各自团队访问各自的命名空间。如果我们把kubectl权限开放给每个人,那么在pod级上进行读取、创建和删除访问时,可能让人抓狂,因为误操作的情况会经常发生。为此,我们应该只允许管理员有权访问,从而将管理集群和部署集群的人员权限区分开。