使用 KubeSpray 安装 Kubernetes 时，报错 1 2 3 4 5 6 fatal: [node0]: FAILED! => { "assertion": "ip in ansible_all_ipv4_addresses", "changed": false, "evaluated_to": false, "failed": true } 查看 inventory.ini

1. Velero 简介 Velero 是 heptio 团队（被 VMWare 收购）开源的 Kubernetes 集群备份、迁移工具。Velero 使用对象存储保存集群资源。默认支持的对象存储有 AWS、Azure、GCP ，兼容 S3 协议，也可以通过插件来扩展到其他平台，比如 Aliyun OSS。目前，Velero 不具备版本管理功能，只能进行增量恢复，不会进行删除或覆盖操作。 2. V

主要记录最近遇到的一些开发问题，解决方法。 1. macOS 快速切换不同 Kubernetes 环境 涉及 Kubernetes 相关开发时，经常需要在多个集群之间切换。配置多集群 context 是一个选择，但是如果集群在不断重置，可以试下如下方法：在 ~/.profile 文件中定义一系列相关 function，切换时只需要执行 on_cluster_name 即可。 1 2 3 4 5 6

1. 安装基础环境 安装 Kubernetes 参考链接：使用 Kubeadm 安装 Kubernetes 集群。值得注意的是 Kubeflow 并不是对每个版本的 Kubernetes 兼容，system-requirements。 1 2 3 4 kubectl version Client Version: version.Info{Major:"1", Minor:"15", GitVer

1. 关于 Prow 在 Kubernetes、Istio 等知名项目的 Github 仓库中，我们经常会看到 xxx-bot 用户，给 issues 添加标签、合并 PR 。这个机器人账户就是被 Prow 驱动的。Prow 是 Kubernetes 测试特别兴趣小组的项目，目前是 kubernetes/test-infra 的一部分。Prow 是一个基于 Kubernetes 使用各类事件驱动执

Helm 3 终于发布了。我们可以告别 Tiller 了，但 Helm 3 的改变不仅于此。让我们继续探讨其他的变化。 1. 告别 Tiller Helm 3 移除了 Tiller ，是个不错的决定。但是要理解为什么不错，我们还需要了解一下 Tiller 产生的背景。Tiller 是 Helm 的服务端组件（运行在 Kubernetes 集群上），主要目的是为了让多个不同的操作者能够在同一个集群上

1. Kubernetes 中的调度器 kube-scheduler 是 Kubernetes 中决定 Pending 状态的 Pod 运行在哪个 Node 的组件，被称之为调度器。Kubernetes 中内置了大量的调度策略，也提供了一些高级调度策略（nodeAffinity、podAffinity 等），以供用户使用，基本能够满足绝大部分的业务需求。前面的文档 Kubernetes 之 Lab

这里主要使用 Windows 节点作为 Worker，而 Master 控制平面依然在 Linux 。 1. 系统配置 1.1 Kubernetes 控制平面 Kubernetes 自 1.14 版本，增加了对 Windows 节点生产级的支持。由于微软官方文档主要提供的是 flannel 网络插件的安装方式，这里建议 Kubernetes 也采用 flannel 插件。 查看当前集群 Kuber

在前面两篇文档，在 Kubernetes 上动态创建 Jenkins Slave 和 Kubernetes 添加 Windows 节点提供 Jenkins 构建动态 Agent 的基础之上，本篇文档主要尝试在 Kubernetes 上动态提供 Windows 构建 Agent 。 1. 新增流水线 Kubernetes 与 Jenkins 集成部分可以参考上面的两篇文档，这里直接新建两条流水线进行

前面的文档中，我们利用 Kubernetes 提供的弹性，在 Kubernetes 上动态创建 Jenkins Slave 。本篇文档主要是对 Jenkins 进行大规模构建的压力测试。 1. 集群配置 1.1 Kubernetes 版本 这里使用的是 v1.16.7 1 2 3 4 kubectl version Client Version: version.Info{Major:"1", M

1. Jenkins X 简介 Jenkins 依靠庞大的插件生态，占据了目前大部分的企业级 CICD 引擎的份额。但在云原生时代，Jenkins 也暴露出很多的问题，单点服务、磁盘存储、内存占用等。Jenkins X 围绕 Kubernetes，提供了一种更适合云原生时代的 DevOps 方式。Jenkins X 不是 Jenkins 的发行版本，准确来说，Jenkins X 是一个应用发布部署

1. Terraform Vs Kubernetes 基础架构即代码（Iac) 基于不可变的基础架构，使用编排工具将基础架构文本化，允许像管理代码一样管理基础设施。2018 年，我在从事 SaaS 开发，使用 Kubernetes 平台进行部署，这一年 Terraform 很火。2019 年，我开始从事 Kubernetes 的二次开发，才听说 Terraform 。现在网上 Terraform

Kubernetes 平台管理软件运行在 Kubernetes ，用于管理运行在 Kubernetes 上的资源对象。 1. 测试思路 测试在一定负载一定集群规模下，平台软件的管理能力，而不是 Kubernetes 的管理能力。平台软件的管理能力主要体现在能通过 UI 对负载、PV 进行增删改查，在 UI 上能够直接查看负载的监控和日志。明确测试内容和目的非常重要。测试对象不是 Kubernete

本篇主要介绍如何运维 DevOps 流水线，怎么解决一些常见的问题。问题主要分为两大类，一类是 Kubernetes 相关的，具有一定通用性；另一类是与业务相关，需要对领域有所了解，解决问题时才能事半功倍。文档内容，会不断滚动更新。 1. Kubernetes 问题排查 1.1 基本的创建流程 如上图所示，是用户创建一个 Deployment 的简单流程。主要分为以下步骤: kubectl 根据用

作者: 杜军出版社: 电子工业出版社出版年: 2019-10ISBN: 9787121373398Notes:网络是 Kubernetes 中不易掌握的一个难点。网络故障会直接影响现有的负载，通常是十分紧急的问题。而网络相关的知识相较于应用开发更底层，很多的细节，需要长期的积累。书中相关的要点之前陆续都有所接触，通过阅读这本书，可以帮助梳理知识体系。这是一本不错的 Kubernetes 网络相关书

Kubernetes 依靠 kube-proxy 组件实现 Service 的通信与负载均衡。在这个过程中，由于使用了 SNAT 对源地址进行了转换，导致 Pod 中的服务拿不到真实的客户端 IP 地址信息。本篇主要解答了在 Kubernetes 集群中负载如何获取客户端真实 IP 地址这个问题。 1. 创建一个后端服务 1.1 服务选择 这里选择 containous/whoami 作为后端服务

1. 测试是海上的航标 项目越复杂、规模越大，越能体现测试的价值和重要性。测试保证了方向的正确性。就像航行时，海上出现的航标，可以用来检验、纠正路线。便于掌舵人，随时了解动态，做出调整。测试决定了迭代的速度。随着 Scrum 等敏捷开发方法的实践，交付的节奏在加快。测试是交付质量的保障，如果测试跟不上，敏捷将无法落地。测试很重要，但却是一本经济账。太少，不足以保障质量；太多，维护成本又很高。卡住关

从原理上看，在 Kubernetes 集群中，Jenkins 都可以使用 Podman 进行镜像构建，本文主要以 Containerd 为例。 1. 去 Docker 给 CICD 带来新的挑战 在 CICD 场景下, 我们经常需要在流水线中构建和推送镜像。在之前的文档 《在 Kubernetes 上动态创建 Jenkins Slave》 中, 我描述了通过挂载 /var/run/docker.s