Kubernetes部署

-----------------------------------------------------------------

Tekton 是谷歌开源的Kubernetes 原生 CI/CD 框架，前身是 Knative 的构建模块，后发展为独立开源项目并归属 Linux 基金会，专为在 Kubernetes 集群中实现标准化的构建、测试和部署流程而设计，适配多云、多集群场景，还能支持滚动部署、GitOps 等高级工作流。以下是其核心信息的详细介绍：
  1. 核心组件
    组件作用
    Tekton Pipeline 核心组件，通过 Step、Task、Pipeline 等自定义资源定义 CI/CD 工作流。其中 Step 是最小执行单元（如编译代码），多个 Step 组成 Task（对应 K8s 的一个 Pod），多个 Task 串联成 Pipeline（对应多个 Pod 构成的有向无环图）。
    Tekton Trigger 负责接收外部事件触发流水线，包含 TriggerBinding（提取事件字段为参数）、TriggerTemplate（模板化生成 Tekton 资源）、EventListener（监听 HTTP 事件并衔接前两者），比如接收 Git 代码提交事件触发构建流程。
    Tekton CLI 提供 tkn命令行工具，开发者可通过命令行创建、管理和查看 Task、Pipeline 等资源的运行状态。
    Tekton Dashboard Web 可视化界面，支持直观地创建 Tekton 资源、执行流水线，以及查看运行日志和资源状态，降低运维操作门槛。
    Tekton Catalog 社区维护的共享仓库，包含大量可复用的 Task 和 Pipeline 模板（如代码拉取、镜像构建等通用任务），减少重复开发。
    Tekton Operator 基于 K8s Operator 实现，用于一键在 K8s 集群中安装、升级、卸载 Tekton 相关组件，简化集群级别的 Tekton 部署管理。
  2. 核心特性
    • 强云原生属性：所有任务均以 K8s Pod 形式运行，能充分借助 K8s 的资源调度、弹性扩展和高可用能力，且资源定义符合 K8s 的 CRD 规范，可通过kubectl工具直接管理。
    • 高复用与解耦：Task、Pipeline 等模块可独立定义，搭配 Catalog 中的通用模板，能跨项目、跨团队复用；同时 Trigger 与 Pipeline 解耦，不同触发规则可适配同一流水线。
    • 灵活扩展：支持自定义 Step、Task 适配特殊业务场景，也可通过扩展资源类型适配 Git、云存储、容器镜像等多种外部资源。
    • 可追溯性：通过 TaskRun（执行 Task 的实例）和 PipelineRun（执行 Pipeline 的实例）记录每次运行的状态、日志和参数，便于问题排查和流程审计。
  3. 典型工作流程
    1. 开发者向 Git 仓库提交代码，Git 平台（如 GitLab）推送提交事件至 Tekton 的 EventListener；
    2. TriggerBinding 从事件数据中提取关键信息（如代码分支、仓库地址）；
    3. 这些信息传入 TriggerTemplate，生成对应的 Task、Pipeline 等资源；
    4. 系统自动创建 TaskRun 和 PipelineRun，实例化并执行流水线任务，比如拉取代码、编译构建、推送镜像、部署到 K8s 集群；
    5. 开发者可通过 Tekton Dashboard 或 tkn命令查看运行进度和日志。
  4. 与传统 CI/CD 工具的差异
     
    相比 Jenkins 等传统工具，Tekton 无独立服务器依赖，无需额外维护计算节点；其声明式 YAML 配置比 Jenkins 的 Groovy 脚本更贴合云原生配置习惯，且任务间资源隔离性更强（每个 Task 对应独立 Pod），避免了传统工具中任务共享资源导致的冲突问题。不过 Jenkins 的插件生态更成熟，而 Tekton 在云原生场景下的扩展性和集群适配性更具优势。
5 篇资料
 
tekton 和jenkins
Tekton 和 Jenkins 是两款主流的 CI/CD 工具，但核心设计理念、适用场景和技术架构差异显著。以下从 核心定位、架构设计、适用场景 等维度进行深度对比，并给出选型建议，帮助研发人员根据实际需求决策：

一、核心差异总览表

对比维度TektonJenkins
核心定位 Kubernetes 原生 CI/CD 框架（声明式、资源化） 通用型 CI/CD 服务器（插件化、脚本化）
部署形态 完全基于 K8s CRD（无独立服务器，组件以 Pod 运行） 独立 Java 进程（可部署在 K8s 或物理机 / 虚拟机）
配置方式 YAML 声明式配置（Task/Pipeline 等 CRD 资源） 图形化界面 + Groovy 脚本（Jenkinsfile）
任务执行模型 每个 Task 对应 1 个 Pod，Step 对应 Pod 内容器（资源隔离强） 任务运行在 Agent 节点（可共享节点资源，支持 Docker 容器化执行）
扩展性 基于 K8s CRD 扩展（自定义 Task、Trigger），云原生生态适配 插件生态极丰富（超 1500+ 插件），支持多场景扩展（但插件质量参差不齐）
学习曲线 需掌握 K8s 基础，YAML 配置门槛较高 图形化界面降低入门门槛，复杂流水线需学习 Groovy 脚本
资源调度 复用 K8s 调度能力（弹性伸缩、亲和性、资源限制） 需手动配置 Agent 节点，调度逻辑依赖插件（如 Kubernetes Plugin）
可观测性 依赖 K8s 监控体系（Prometheus + Grafana）+ Tekton Dashboard 内置日志、构建历史，支持插件扩展监控（如 Prometheus 插件）
GitOps 适配 天然适配（声明式配置可纳入 Git 管理，支持 ArgoCD/Flux 同步） 需通过插件或自定义脚本适配，原生支持较弱
多集群 / 多云支持 原生支持（通过 K8s 多集群管理能力扩展） 需通过联邦插件或代理节点实现，配置复杂
维护成本 低（复用 K8s 运维体系，无额外服务器维护） 高（需维护 Java 进程、插件更新、Agent 节点）

二、关键维度深度解析

1. 架构设计：云原生 vs 传统服务器

  • Tekton：
    • 完全遵循 K8s 设计理念，所有核心组件（Pipeline、Trigger、Dashboard）均以 K8s CRD 或 Deployment 形式部署，无独立 “服务器” 概念。
    • 任务执行时，Tekton 会自动创建 Pod（Task 级别）和容器（Step 级别），执行完成后自动清理，资源利用率高且隔离性强。
    • 依赖 K8s 的核心能力（如 Namespace 隔离、RBAC 权限控制、PV/PVC 存储），无需额外开发适配层。
  • Jenkins：
    • 基于 Java 开发的独立进程，核心是 Jenkins Master 节点，任务执行依赖 Agent 节点（可是物理机、虚拟机或 Docker 容器）。
    • 任务执行时，Agent 节点需提前注册，任务共享节点资源（若未使用容器化 Agent，可能出现环境冲突）。
    • 虽支持通过 Kubernetes Plugin 将 Agent 部署为 K8s Pod，但本质是 “传统工具适配云原生”，而非原生设计。

2. 配置与易用性：声明式 vs 图形化 + 脚本化

  • Tekton：
    • 所有流水线配置通过 YAML 声明式定义（如 Task、Pipeline、PipelineRun），示例如下：
      yaml
       
       
      # 定义一个简单的 Task（拉取代码并编译）
apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: build-java-app
spec:
  params:
    - name: repo-url
      type: string
  steps:
    - name: git-clone
      image: alpine/git
      script: git clone $(params.repo-url) /workspace
    - name: maven-build
      image: maven:3.8-openjdk-11
      script: cd /workspace && mvn clean package
       
       
    • 配置严格遵循 K8s YAML 规范，适合研发人员（尤其是熟悉 K8s 的后端 / 运维），但非研发人员上手成本高。
    • 支持通过 Tekton Catalog 复用社区现成 Task（如代码拉取、镜像构建、部署到 K8s），减少重复开发。
  • Jenkins：
    • 支持两种配置方式：
      1. 图形化界面：适合快速搭建简单流水线（如 “拉取代码 → 执行脚本 → 发送邮件”），无需编写代码。
      2. Jenkinsfile（Groovy 脚本）：用于复杂流水线，示例如下：
        groovy
         
         
        pipeline {
  agent any
  stages {
    stage('Clone') {
      steps { git url: 'https://github.com/xxx/java-app.git' }
    }
    stage('Build') {
      steps { sh 'mvn clean package' }
    }
  }
}
         
         
    • 图形化界面降低入门门槛，但复杂流水线依赖 Groovy 脚本，且脚本语法灵活（无严格规范），容易导致不同团队的流水线配置风格不一致，维护成本高。

3. 扩展性与生态：云原生生态适配 vs 通用插件生态

  • Tekton：
    • 扩展性聚焦云原生场景：
      • 自定义 CRD：支持扩展 Task、Pipeline 类型，适配特殊业务（如边缘计算部署、云厂商资源调用）。
      • 生态联动：无缝集成 K8s 周边工具（如 ArgoCD/Flux 用于 GitOps 部署、Prometheus 监控流水线状态、Harbor 存储镜像）。
      • 多集群支持：通过 K8s 多集群管理（如 Karmada），可实现跨集群流水线执行。
    • 社区生态相对较新，但增长迅速，核心场景（构建、测试、部署）的模板和工具已成熟。
  • Jenkins：
    • 插件生态极丰富（超 1500+ 插件），覆盖所有 CI/CD 场景：
      • 源码管理：支持 Git、SVN、Mercurial 等。
      • 构建工具：支持 Maven、Gradle、npm、Go 等。
      • 部署目标：支持 K8s、Docker、AWS、Azure、物理机等。
      • 通知与集成：支持 Slack、Email、Jira、GitLab 等。
    • 缺点：插件质量参差不齐，部分老旧插件存在兼容性问题，且多插件组合可能导致流水线复杂度上升。

4. 适用场景：云原生团队 vs 通用场景团队

  • Tekton 更适合：
    • 核心基础设施基于 K8s 的团队（如微服务、云原生应用研发）。
    • 追求 “基础设施即代码（IaC）”，希望流水线配置纳入 Git 管理（GitOps 实践）。
    • 需跨集群、多云部署，重视资源隔离和弹性伸缩。
    • 研发团队以后端 / 运维为主，熟悉 YAML 和 K8s 操作。
  • Jenkins 更适合：
    • 技术栈多样（既有云原生应用，也有传统应用如 Java Web、桌面程序）。
    • 团队包含非研发人员（如测试、运维），需要图形化界面快速配置流水线。
    • 依赖特殊插件（如老旧系统集成、定制化通知），Tekton 生态暂不支持。
    • 现有流水线基于 Jenkins 构建，迁移成本过高。

三、选型建议与迁移思路

1. 选型决策树

plaintext
 
 
是否已采用 K8s 作为核心基础设施？
├─ 是 → 团队是否熟悉 YAML/声明式配置？
│  ├─ 是 → 优先选 Tekton（适配云原生生态，降低长期维护成本）
│  └─ 否 → 若需快速落地，可先用 Jenkins + Kubernetes Plugin，逐步迁移到 Tekton
└─ 否 → 团队是否有复杂定制化需求？
   ├─ 是 → 选 Jenkins（插件生态满足定制化）
   └─ 否 → 小型团队可考虑更轻量工具（如 GitLab CI），无需引入 Jenkins/Tekton
 

2. 从 Jenkins 迁移到 Tekton 的关键步骤

  1. 拆解 Jenkins 流水线：将 Jenkinsfile 中的 Stage 拆分为 Tekton 的 Task，Step 对应 Tekton 的 Step（每个 Step 用独立容器镜像）。
  2. 复用现有脚本：将 Jenkins 中的 Shell/Python 脚本直接迁移到 Tekton Step 的 script 字段，无需大幅修改。
  3. 替换插件功能：
    • 源码拉取：用 Tekton Catalog 的 git-clone Task 替代 Jenkins Git 插件。
    • 镜像构建：用 kaniko Task 替代 Jenkins Docker 插件（无需 Docker daemon 权限）。
    • 部署到 K8s：用 kubectl Task 或 ArgoCD 集成替代 Jenkins Kubernetes Plugin。
  4. 配置 Trigger：用 Tekton Trigger 替代 Jenkins 的 WebHook 触发（如 Git 提交、合并请求事件）。
  5. 逐步灰度：先迁移非核心流水线（如测试环境构建），验证稳定性后再迁移生产环境流水线。

四、总结

  • Tekton 是云原生时代的 CI/CD 首选，其声明式配置、K8s 原生架构和 GitOps 适配能力，能大幅降低云原生应用的流水线维护成本，适合长期投入。
  • Jenkins 仍是通用场景的 “万能工具”，插件生态和图形化界面使其适合技术栈多样、定制化需求强的团队，但长期维护成本较高。
  • 对于已落地 K8s 的团队，建议优先尝试 Tekton，即使短期内需要学习成本，长期来看能更好地适配云原生技术体系的演进。
 
Kubernetes 组件有哪些
Kubernetes（K8s）是一个分布式容器编排平台，其架构采用主从模式（Master-Slave），核心组件分为控制平面组件（Control Plane） 和节点组件（Node），辅以核心附件（Add-ons） 实现完整功能。以下是各组件的详细解析，结合功能、作用场景和核心特性，帮助研发人员理解其工作原理：

一、控制平面组件（Control Plane）

控制平面是 K8s 集群的 “大脑”，负责全局决策（如调度、集群状态管理），可部署在单节点或多节点（高可用），核心组件包括：
组件名称核心功能关键特性与注意事项
kube-apiserver 集群统一入口，提供 RESTful API 接口，处理所有请求（如创建 Pod、部署服务） - 唯一与 etcd 交互的组件（读写集群状态）
 
- 支持 RBAC 权限控制、API 版本管理
 
- 高可用部署需负载均衡（如 Nginx、HAProxy）
etcd 分布式键值存储，保存集群所有状态数据（如 Pod 配置、服务端点、权限规则） - 集群的 “数据库”，数据一致性至关重要
 
- 生产环境需部署 3/5 节点集群（避免单点故障）
 
- 需定期备份，支持数据加密和压缩
kube-scheduler 负责 Pod 调度，根据节点资源、亲和性规则等选择最优节点运行 Pod - 调度策略：默认调度（资源请求匹配）、亲和性 / 反亲和性、污点（Taint）与容忍（Toleration）
 
- 支持自定义调度器（适配特殊业务场景）
kube-controller-manager 运行各类控制器进程，确保集群状态与期望状态一致（如 Pod 故障重启、副本数维持） - 内置控制器：节点控制器（Node Controller）、副本控制器（ReplicaSet Controller）、端点控制器（Endpoint Controller）等
 
- 多实例部署时通过 Leader 选举避免冲突
cloud-controller-manager 对接云厂商 API（如 AWS、阿里云、腾讯云），实现云资源联动（如负载均衡、存储卷） - 仅在云环境中启用，私有化部署可忽略
 
- 解耦 K8s 核心逻辑与云厂商特有功能

二、节点组件（Node）

节点组件运行在每个工作节点（Worker Node）上，负责执行 Pod 任务、维护节点状态，核心组件包括：
组件名称核心功能关键特性与注意事项
kubelet 节点代理，负责与控制平面通信，管理本节点上的 Pod 生命周期（创建、启动、停止） - 验证 Pod 配置的资源需求（CPU / 内存），确保节点资源充足
 
- 执行 Pod 健康检查（存活探针、就绪探针）
 
- 不直接操作容器，通过容器运行时接口（CRI）调用容器引擎
kube-proxy 维护节点网络规则，实现 Service 的负载均衡和服务发现 - 三种工作模式：
 
1. 用户空间模式（性能差，已淘汰）
 
2. iptables 模式（默认，基于内核 iptables 转发）
 
3. IPVS 模式（高并发场景首选，性能更优）
 
- 仅处理集群内部服务通信，外部流量需通过 Ingress 或 LoadBalancer
容器运行时（CRI） 负责容器的创建、运行、销毁，需兼容 K8s 的容器运行时接口（CRI） - 主流实现：
 
1. containerd（Docker 剥离的核心组件，轻量、稳定，K8s 首选）
 
2. CRI-O（专为 K8s 设计，无 Docker 依赖）
 
3. Docker（需通过 cri-dockerd 适配，已非官方推荐）
 
- 必须支持容器网络接口（CNI）和容器存储接口（CSI）

三、核心附件（Add-ons）

附件是实现 K8s 高级功能的扩展组件，通常以 Pod 形式运行在集群中，核心包括：

1. 网络插件（CNI）

负责集群网络互联互通（Pod 间通信、Pod 与外部通信），需满足 K8s 网络模型（Pod 拥有独立 IP，集群内 Pod 可直接通信）：
  • Calico：基于 BGP 协议，性能优异，支持网络策略（NetworkPolicy），适合大规模集群。
  • Flannel：轻量级网络插件，配置简单，适合测试环境或小型集群。
  • Cilium：基于 eBPF，支持高性能网络转发和细粒度网络策略，适配云原生场景。

2. 存储插件（CSI）

实现容器存储卷的动态 provisioning（自动创建存储卷），对接各类存储系统：
  • CSI 通用插件：如 csi-driver-nfs（NFS 存储）、csi-driver-host-path（本地存储）。
  • 云厂商 CSI 插件：如阿里云 ack-csi-plugin、AWS ebs-csi-driver，对接云厂商块存储 / 文件存储。
  • 分布式存储 CSI 插件：如 GlusterFS、Ceph CSI 插件，提供高可用存储。

3. 服务发现与负载均衡

  • CoreDNS：负责集群内部 DNS 解析，将 Service 名称映射为 Pod IP，替代早期的 kube-dns。
  • Ingress Controller：管理外部流量入口，实现 HTTP/HTTPS 路由、SSL 终结、负载均衡（如 Nginx Ingress、Traefik）。

4. 监控与日志

  • Prometheus + Grafana：监控集群资源（CPU / 内存 / 磁盘）和应用指标，支持可视化和告警。
  • EFK/ELK Stack：日志收集、存储和分析（Elasticsearch + Fluentd + Kibana）。
  • kube-state-metrics：暴露 K8s 资源状态指标（如 Pod 运行状态、Deployment 副本数），供 Prometheus 采集。

5. 其他核心附件

  • Metrics Server：集群资源指标聚合器，为 HPA（Horizontal Pod Autoscaler）提供 CPU / 内存使用率数据。
  • Dashboard：K8s Web 可视化界面，支持查看集群状态、创建 / 管理资源（适合快速操作，生产环境建议关闭或限制访问）。
  • Cert-Manager：自动化管理 TLS 证书（如 Let's Encrypt 证书），为 Ingress 或 Service 提供 HTTPS 支持。

四、组件交互流程示例（Pod 创建流程）

理解组件间的协作关系，有助于排查问题：
  1. 开发者通过 kubectl run 或 API 提交 Pod 创建请求，kube-apiserver 接收并验证请求。
  2. kube-apiserver 将 Pod 配置数据写入 etcd。
  3. kube-scheduler 监听 etcd 中的未调度 Pod，根据调度策略选择最优节点，将调度结果写入 etcd。
  4. 目标节点的 kubelet 监听 etcd 中的调度结果，通过 CRI 调用容器运行时（如 containerd）创建 Pod。
  5. kube-proxy 监听 etcd 中的 Service 和 Pod 变化，更新节点网络规则（如 iptables/IPVS），实现 Service 与 Pod 的通信。
  6. 所有组件的状态变化通过 kube-apiserver 同步到 etcd，确保集群状态一致。

五、核心总结

  1. 控制平面：聚焦 “决策”，kube-apiserver 是核心入口，etcd 是数据存储，scheduler 和 controller-manager 是执行逻辑。
  2. 节点组件：聚焦 “执行”，kubelet 是节点核心，kube-proxy 负责网络，容器运行时负责容器生命周期。
  3. 附件：扩展 K8s 功能，网络（CNI）、存储（CSI）、监控、日志是生产环境必备。
  4. 高可用关键：控制平面（多节点部署）、etcd（3/5 节点集群）、网络插件（高可用模式）是集群稳定运行的核心。
对于研发人员（尤其是微服务、云原生应用开发者），掌握核心组件的功能和交互流程，能更高效地进行应用部署、故障排查和性能优化（如通过调度策略优化 Pod 部署、通过 HPA 实现弹性伸缩）。

------------------------------------------------------------------

posted @ 2025-11-27 16:08  hanease  阅读(2)  评论(0)    收藏  举报