作为k8s和cicd专家的我 在tekton实战中 开发或者需要注意的点

tekton的优点

  • 结合k8s的诸多特点:整体上设计的十分巧妙
  • hub中有丰富的 task 供我们封装自己的pipeline
  • 我在通读它的源码后感慨其伟大之初
  • 实话说在k8s中还在玩jenkins的就比较落伍了

作为k8s和cicd专家的我 在tekton实战中 开发或者需要注意的点

01 封装几种常见的流水线

  • 01 build-push :只构建并推送镜像
  • 02 auth-clone-build-push-apply:新服务 or 同时调整镜像和yaml ,构建+部署yaml+替换image
  • 03 auth-set-image:只需要更新镜像版本,测试环境测好的镜像部署到线上
  • 04 auth-apply-yaml-image:只需要部署yaml,需替换IMAGE_HOLDER, 比如yaml的日志采集等字段更新了,或者configMap参数变更
  • 05 apply一个git仓库中的yaml文件,无需替换IMAGE_HOLDER
  • 06 apply-yaml-dir:apply一个git仓库中的目录,目录中有多个yaml文件
  • 07 apply一个外部的url对应的yaml文件,如装github上的开源组件
  • 08 auth-apply-yaml-image-var : 给需要传额外参数的流水线

02 关于镜像的随机标签问题

  • 应研发需求,为了防止镜像被污染,在镜像标签中添加时间和commit字符串
  • 添加规则如下:

    • 如果GIT_REVISION为空,分支或tag信息则为master
    • 如果GIT_REVISION不为空,分支或tag信息则为对应的传参
    • 加分钟级别时间
    • 加commit字符串
  • {IMAGE_BASE_PATH}:{GIT_REVISION}-{date}-{commitid}
  • 举例 xxx/web/nignx:v1.2.3-20220512-10-55-c8873a524
  • 举例 xxx/web/nignx:master-20220512-11-08-a47ac5b8c

03 对应代码仓库需要做的改造应该尽可能的少

  • deployment部署的yaml模板在git仓库中
  • 经常需要变更镜像版本的地方 用IMAGE_HOLDER做占位符
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: IMAGE_HOLDER
          ports:
            - containerPort: 80

04 在cd时应该限制往在线k8s集群发布的权限

  • 在需要部署到k8s集群的流水线中添加鉴权步骤,逻辑如下
  • 用户需要传参USER_TOKEN
  • 如果是部署的目标集群名字中包含live,去校验接口验证USER_TOKEN

    • 成功则放行
    • 失败则流水线停止
  • 校验接口每隔一段时间生成随机token
  • 随机token请找对应的SRE索要:目的就是研发发布的时候要通知SRE,大家都知道要往在线集群发布了,避免私下发布或误发布
  • 使用admintoken可以通过接口获取随机token,然后填入USER_TOKEN校验即可

其它注意事项就不展开了,有问题请购买课程后再答疑

  • 关于golang项目 go mod 引用公司内其他私有仓库的问题
  • 关于habor镜像仓库权限的问题等

k8s纯源码解读教程(3个课程内容合成一个大课程)

k8s运维进阶调优课程

k8s二次开发课程

prometheus全组件的教程

go语言课程

直播答疑sre职业发展规划

你可能感兴趣的:(作为k8s和cicd专家的我 在tekton实战中 开发或者需要注意的点)