DevOps 工具链管理器 DevStream 还真是神器
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 地址?
昨天网络环境出了点问题,本地的虚拟机搭建的 Kubernetes 环境没有固定 IP,结果节点 IP 变了,当然最简单的方式是将节点重新固定回之前的 IP 地址,但是自己头铁想去修改下集群的 IP 地址,结果一路下来踩了好多坑,压根就没那么简单~
[阅读全文]本地集群使用 OpenELB 实现 Load Balancer 负载均衡
Prometheus 监控 Kubernetes Job 资源误报的坑
昨天在 Prometheus 课程辅导群里面有同学提到一个问题,是关于 Prometheus 监控 Job 任务误报的问题,大概的意思就 CronJob 控制的 Job,前面执行失败了,监控会触发报警,解决后后面生成的新的 Job 可以正常执行了,但是还是会收到前面的报警:
这是因为一般在执行 Job 任务的时候我们会保留一些历史记录方便排查问题,所以如果之前有失败的 Job 了,即便稍后会变成成功的,那么之前的 Job 也会继续存在,而大部分直接使用 kube-prometheus 安装部署的话使用的默认报警规则是kube_job_status_failed > 0
,这显然是不准确的,只有我们去手动删除之前这个失败的 Job 任务才可以消除误报,当然这种方式是可以解决问题的,但是不够自动化,一开始没有想得很深入,想去自动化删除失败的 Job 来解决,但是这也会给运维人员带来问题,就是不方便回头去排查问题。下面我们来重新整理下思路解决下这个问题。
自定义 Traefik(本地)插件
虽然 Traefik 已经默认实现了很多中间件,可以满足大部分我们日常的需求,但是在实际工作中,用户仍然还是有自定义中间件的需求,为解决这个问题,官方推出了一个 Traefik Pilot 的功能了,此外在 Traefik v2.5 版本还推出了支持本地插件的功能。
[阅读全文]Helm Chart 兼容不同 Kubernetes 版本
随着 Kubernetes 的版本不断迭代发布,很多 Helm Chart 包压根跟不上更新的进度,导致在使用较新版本的 Kubernetes 的时候很多 Helm Chart 包不兼容,所以我们在开发 Helm Chart 包的时候有必要考虑到对不同版本的 Kubernetes 进行兼容。
[阅读全文]Gitlab CI 在 Kubernetes 中的 Docker 缓存
前面我们有文章介绍过如何在 Kubernetes 集群中使用 GitLab CI 来实现 CI/CD,在构建镜像的环节我们基本上都是使用的 Docker On Docker
的模式,这是因为 Kubernetes 集群使用的是 Docker 这种容器运行时,所以我们可以将宿主机的 docker.sock
文件挂载到容器中构建镜像,而最近我们在使用 Kubernetes 1.22.X 版本后将容器运行时更改为了 Containerd,这样节点上没有可用的 Docker 服务了,这个时候就需要更改构建镜像的模式了,当然要实现构建镜像的方式有很多,我们这里还是选择使用 Docker 来构建我们的 Docker 镜像,也就是使用 Docker IN Docker
的模式。
一文搞懂容器运行时 Containerd
在学习 Containerd 之前我们有必要对 Docker 的发展历史做一个简单的回顾,因为这里面牵涉到的组件实战是有点多,有很多我们会经常听到,但是不清楚这些组件到底是干什么用的,比如 libcontainer
、runc
、containerd
、CRI
、OCI
等等。
使用 kube-vip 搭建高可用 Kubernetes 集群
kube-vip 可以在你的控制平面节点上提供一个 Kubernetes 原生的 HA 负载均衡,我们不需要再在外部设置 HAProxy 和 Keepalived 来实现集群的高可用了。
kube-vip
是一个为 Kubernetes 集群内部和外部提供高可用和负载均衡的开源项目,在 Vmware 的 Tanzu 项目中已经使用 kube-vip 替换了用于 vSphere 部署的 HAProxy 负载均衡器,本文我们将先来了解 kube-vip 如何用于 Kubernetes 控制平面的高可用和负载均衡功能。
你应该了解的10个 Kubernetes 安全上下文设置[译]
在 Kubernetes 中安全地运行工作负载是很困的,有很多配置都可能会影响到整个 Kubernetes API 的安全性,这需要我们有大量的知识积累来正确的实施。Kubernetes 在安全方面提供了一个强大的工具 securityContext
,每个 Pod 和容器清单都可以使用这个属性。在本文中我们将了解各种 securityContext
的配置,探讨它们的含义,以及我们应该如何使用它们。
[阅读全文]
securityContext
设置在PodSpec
和ContainerSpec
规范中都有定义,这里我们分别用[P]
和[C]
来表示。需要注意的是,如果一个设置在两个作用域中都可以使用和配置,那么我们应该优先考虑设置容器级别的。
通过 Traefik 使用 Kubernetes Service APIs 进行流量路由
前面我们已经介绍了 Kubernetes 社区内部为 Kubernetes 开发了一种改进的定义和管理入口流量的新接口,也就是新的 Kubernetes Service APIs
。Traefik 在2.4 版本中引入了对 Service APIs 的初始支持。本文我们将演示如何通过 Traefik 来使用新的 Gateway
、GatewayClass
和 HTTPRoute API
将请求路由到后端的服务 Pod。