#kubernetes

DevStream 是一个开源的 DevOps 工具链管理器，因开发者而生，由开发者开发，为开发者服务。

想象你正在开始一个新的项目或组建一个新的团队。在写第一行代码之前，你需要一个能够高效运转 SDLC(软件开发生命周期)和承载开发至部署全过程的工具。

通常情况下，你需要以下几个部分来高效地工作。

• 项目管理软件或 issue 追溯工具（JIRA 等）
• 源代码管理（GitHub、Bitbucket 等）
• 持续集成（Jenkins、CircleCI、Travis CI 等）
• 持续交付/部署（Flux CD/Flux2、Argo CD 等)
• 密钥和证书的单一事实来源(A single source of truth)（密钥管理器，如 HashiCorp 的 Vault）
• 集成化的日志和监控工具（例如，ELK、Prometheus/Grafana）
• ……

实际的情况可能远不止这些，要找到合适的组件本身就不容易了，再将这些工具整合起来就更难了，需要花费大量的时间和精力。而 DevStream 就是为简化整合 DevOps 组件而构建的工具，有点类似于 yum、apt 这些软件包管理工具，DevStream 就是 DevOps 工具领域的软件包管理器。

昨天网络环境出了点问题，本地的虚拟机搭建的 Kubernetes 环境没有固定 IP，结果节点 IP 变了，当然最简单的方式是将节点重新固定回之前的 IP 地址，但是自己头铁想去修改下集群的 IP 地址，结果一路下来踩了好多坑，压根就没那么简单~

为了方便测试，准备为 Ingress 控制器配置一个 LoadBalaner 类型的 Service，由于我这是本地私有环境，所以需要部署一个支持该服务类型的负载均衡器，在社区中目前最流行的应该是 MetalLB 这个项目，现在也属于 CNCF 沙箱项目，该项目在 2017 年底发起，经过 4 年的发展已经在社区被广泛采用，但是我这边在测试使用过程中一直表现不稳定，经常需要重启控制器才能生效。所以将目光转向了最近国内青云开源的另外一个负载均衡器 OpenELB。

昨天在 Prometheus 课程辅导群里面有同学提到一个问题，是关于 Prometheus 监控 Job 任务误报的问题，大概的意思就 CronJob 控制的 Job，前面执行失败了，监控会触发报警，解决后后面生成的新的 Job 可以正常执行了，但是还是会收到前面的报警：

这是因为一般在执行 Job 任务的时候我们会保留一些历史记录方便排查问题，所以如果之前有失败的 Job 了，即便稍后会变成成功的，那么之前的 Job 也会继续存在，而大部分直接使用 kube-prometheus 安装部署的话使用的默认报警规则是kube_job_status_failed > 0，这显然是不准确的，只有我们去手动删除之前这个失败的 Job 任务才可以消除误报，当然这种方式是可以解决问题的，但是不够自动化，一开始没有想得很深入，想去自动化删除失败的 Job 来解决，但是这也会给运维人员带来问题，就是不方便回头去排查问题。下面我们来重新整理下思路解决下这个问题。

虽然 Traefik 已经默认实现了很多中间件，可以满足大部分我们日常的需求，但是在实际工作中，用户仍然还是有自定义中间件的需求，为解决这个问题，官方推出了一个 Traefik Pilot 的功能了，此外在 Traefik v2.5 版本还推出了支持本地插件的功能。

随着 Kubernetes 的版本不断迭代发布，很多 Helm Chart 包压根跟不上更新的进度，导致在使用较新版本的 Kubernetes 的时候很多 Helm Chart 包不兼容，所以我们在开发 Helm Chart 包的时候有必要考虑到对不同版本的 Kubernetes 进行兼容。

前面我们有文章介绍过如何在 Kubernetes 集群中使用 GitLab CI 来实现 CI/CD，在构建镜像的环节我们基本上都是使用的 Docker On Docker 的模式，这是因为 Kubernetes 集群使用的是 Docker 这种容器运行时，所以我们可以将宿主机的 docker.sock 文件挂载到容器中构建镜像，而最近我们在使用 Kubernetes 1.22.X 版本后将容器运行时更改为了 Containerd，这样节点上没有可用的 Docker 服务了，这个时候就需要更改构建镜像的模式了，当然要实现构建镜像的方式有很多，我们这里还是选择使用 Docker 来构建我们的 Docker 镜像，也就是使用 Docker IN Docker 的模式。

在学习 Containerd 之前我们有必要对 Docker 的发展历史做一个简单的回顾，因为这里面牵涉到的组件实战是有点多，有很多我们会经常听到，但是不清楚这些组件到底是干什么用的，比如 libcontainer、runc、containerd、CRI、OCI 等等。

kube-vip 可以在你的控制平面节点上提供一个 Kubernetes 原生的 HA 负载均衡，我们不需要再在外部设置 HAProxy 和 Keepalived 来实现集群的高可用了。

kube-vip 是一个为 Kubernetes 集群内部和外部提供高可用和负载均衡的开源项目，在 Vmware 的 Tanzu 项目中已经使用 kube-vip 替换了用于 vSphere 部署的 HAProxy 负载均衡器，本文我们将先来了解 kube-vip 如何用于 Kubernetes 控制平面的高可用和负载均衡功能。

在 Kubernetes 中安全地运行工作负载是很困的，有很多配置都可能会影响到整个 Kubernetes API 的安全性，这需要我们有大量的知识积累来正确的实施。Kubernetes 在安全方面提供了一个强大的工具 securityContext，每个 Pod 和容器清单都可以使用这个属性。在本文中我们将了解各种 securityContext 的配置，探讨它们的含义，以及我们应该如何使用它们。

securityContext 设置在 PodSpec 和ContainerSpec 规范中都有定义，这里我们分别用[P]和[C]来表示。需要注意的是，如果一个设置在两个作用域中都可以使用和配置，那么我们应该优先考虑设置容器级别的。

前面我们已经介绍了 Kubernetes 社区内部为 Kubernetes 开发了一种改进的定义和管理入口流量的新接口，也就是新的 Kubernetes Service APIs。Traefik 在2.4 版本中引入了对 Service APIs 的初始支持。本文我们将演示如何通过 Traefik 来使用新的 Gateway、GatewayClass 和 HTTPRoute API 将请求路由到后端的服务 Pod。