1. 多集群构建 Tekton 的优势 借助于 Kubernetes, Tekton 已经具备很好的弹性, 能够支持大规模构建。同时, 开发 Task 主要使用 Yaml 和 Shell, 这扩大了 Tekton 的各种场景适配范围。 上面是一张 Tekton 在多集群下的示意图。为什么 Tekton 需要多集群执行流水线？ 随时可变的 Kubernetes 集群。单一的 Kubernetes 集群, 无法满足运维的要求,

1. 创建一个 Go Modules 项目 创建目录 1 2 mkdir go-test cd go-test 初始化包 1 2 3 4 5 go mod init gitlab.private.com/shaowenchen/go-test go: creating new go.mod: module gitlab.private.com/shaowenchen/go-test go: to add module requirements and sums: go mod tidy 添加业务代码 main.go 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 package main import ( "github.com/gin-gonic/gin" ) func main() { r := gin.Default() r.GET("/", func(c *gin.Context) { c.JSON(200, gin.H{ "message": "hello world.", }) }) r.Run() } 下载依赖到 vendor 1 2 go mod tidy go mod vendor 本地运行 1 2 3 4 5 go run

1. CICD 平台的基本功能 常见的 CICD 引擎并不适合直接提供给业务方使用。主要原因在于用户学习成本高、缺乏必要的鉴权、维护升级难度大。 我们通常会基于流程引擎，针对业务进行适配提高易用性，针对场景进行封装收敛复杂度，那么一个 CICD 平台需要具备哪些基本的功能呢？

1. 需求背景 如上图，业务方需要隔离 namespae 的服务，禁止 bar 空间的负载访问，而允许用户从 Load Balancer (LB) 通过 NodePort 访问服务。可以很容易地写出一个网络策略: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 apiVersion:networking.k8s.io/v1kind:NetworkPolicymetadata:name:test-network-policynamespace:foospec:podSelector:matchLabels:{}policyTypes:- Ingressingress:- from:- ipBlock:cidr:10.2.3.4/32- namespaceSelector:matchExpressions:- key:regionoperator:NotInvalues:- bar 然而从 LB 访问的流量被完全禁止，不符合预期。在技术社区检索得

不能 1. 问题背景 基于 Kubernetes 构建可靠、稳定的运维系统时，虚拟机 (VM) 的销毁和新建是一种常态。VM 提供的是计算和内存资源，而使用外部存储，通过 StorageClass 提供给集群中的 PVC 消费。 在这样的背景下，如何快速初始化 VM 成为新的挑战。常见的思路是制作 Node 节点的 VM 镜像，提前将依赖