CloudNative|云原生应用架构|云原生架构|容器化架构|微服务架构|平台架构|基础架构

前言

近期线上 k8s 时不时就会出现一些内部服务间的调用超时问题，通过日志可以得知超时的原因都是出现在域名解析上，并且都是 k8s 内部的域名解析超时，于是直接先将内部域名替换成 k8s service 的 IP，观察一段时间发现没有超时的情况发生了，但是由于使用 service IP 不是长久之计，所以还要去找解决办法。

Kubernetes是什么？

Kubernetes其实就是一个集群，从我们此前运维的角度来理解，它就是一个集群，组合多台主机的资源（内存、CPU、磁盘等）整合成一个大的资源池并统一对外提供计算存储等能力的集群。我们找很多台主机，每台主机上面安装Kubernetes的相关程序，而不同的主机程序之间相互通信，从而完成彼此之间的协调，并且通过这些应用程序之间的协同工作，把多个主机当成一个主机来使用，形成一个集群，仅此而已，但是在kubernetes集群当中主机是分角色的，即所谓的有中心结点架构的集群系统，master/nodes模型, 由一组节点用于master不需要太多，一般高可用的话需要三个（根据集群规模来判断），nodes节点（worker节点）就是干活的，Kubernetes上提供的各种资源服务，运行在node节点上面。

前言

由于外部等不确定因素印象，kubernetes集群中的主机IP修改了，会导致集群受影响，故出以下教程来保证集群的稳定性。此教程适用于kubeadm安装的kubernetes集群，使用版本kubeadm1.15+

我们在使用 Kubernetes 过程中，偶尔会遇到如下所示的一段配置：

1
2
3
4
5
6

securityContext:
  capabilities:
    drop:
    - ALL
    add:
    - NET_BIND_SERVICE

实际上这是配置对应的容器的 Capabilities，在我们使用 docker run 的时候可以通过 --cap-add 和 --cap-drop 命令来给容器添加 Linux Capabilities。对于大部分同学可能又要疑问 Linux Capabilities 是什么呢？

背景

之前写了个工具，用于检测gitlab runner是否能承受住当前runner job的构建，根据Prometheus的监控，在资源使用过载的情况下，就临期启动服务器加入到集群中用于分担runner job构建时的压力。在运行一段时间后发现内存有时占用有点高（goroutine过多），于是就有了下面一步步的优化。