pipeline-frameworks-k8s-02.集群与运行环境

本篇回答一个实操问题:**我想学 Kubernetes / 跑 Argo ** ,怎么实现人生第一个属于argo的 hello world
图 5 Kubernetes 控制面与数据面、主要组件及信息流(示意)

系列导航

篇目 链接
上一篇 pipeline-frameworks-k8s-01.框架概述
下一篇 pipeline-frameworks-k8s-03.kubectl与日常观测

1. 「集群」在动手层面指什么

在概述篇里,集群被粗说成「一组节点 + 控制面,对外像一个资源池」。落到动手,你需要同时具备三件事:

  1. 能连上的 API 端点:通常是 https://<apiserver>:6443,你的 kubectl 或 CI 通过它提交 YAML(对应 图 5 步骤 1)。
  2. 合法身份:证书、kubeconfig 里的用户/上下文,或云厂商 IAM 与集群凭证的绑定(认证/授权在 apiserver 侧完成)。
  3. 至少一个可调度的工作节点:上面跑 kubelet,真正执行 步骤 5(拉镜像、起容器)。

「我本地没有服务器」也可以:在笔记本上起一个单节点小型集群(如 minikube、kind),它仍然是一个完整的 Kubernetes 语义环境,只是规模小、与生产网络/存储差异大。学概念、跑 Argo 入门、写 YAML 往往够用;要练性能、多可用区、真实存储类型,再换实验室或云。


2. 获得集群的常见路径(概念级)

下面三条路径不是互斥的,很多人本地一条 + 公司/云一条并行使用。
图 1 路径 A:本机单节点(kind、minikube 等);路径 B:自有机器上 kubeadm 等自建;路径 C:云托管控制面 + 工作节点

路径 典型场景 你主要关心什么
本地最小集群 学习、kubectl 练习、CI 里快速起集群测 YAML 安装简单、与笔记本资源占用;代表生产拓扑
自建(机房/虚拟机) 数据不出网、已有运维、要完全可控 控制面高可用、etcd 备份、升级节奏、CNI/存储选型
托管 Kubernetes 快速有可用集群、与云 VPC/负载均衡/磁盘集成 控制面由谁运维、节点池与版本、网络与 IAM 与集群的衔接

kindminikube 都属于路径 A,差异主要在实现:

  • kind 多在 Docker 容器里跑节点(适合 CI);
  • minikube 常见是 单 VM 或容器驱动 的一体化环境。

    对初学者,任选其一跑通「kubectl get nodes 看到 Ready」即可,不必先比较所有驱动。

aliCloud 开通

alt text
后续的开通基本都是UI 界面的点点点,在这就不赘述了。开通后,就可以获得对应的配置信息(用于kubetal 和 Apiserver 握手认证和通信)
根据你的实际需求,选择公网/内网的配置信息,复制后粘贴到你准备进行任务投递的机器上(服务器,PC都可以)
k8s config
~/.kube/config 没有后缀!!! windows配置的时候,自动隐藏了文件后缀,让我额外折腾了俩小时(lll¬ω¬)。
配置正常的话,我们就可以直接调用 kubetal 来测试联通情况。
k8s contect
至此,我们已经完成了 k8s server 端的创建,和本地和服务端的通信打通。接下来就可以撰写我们的 argo 任务,进行任务投递拉。

3. 托管 Kubernetes:责任划到哪里为止

通常可以简单的理解为 云厂商运维服务端 **控制面(apiserver、scheduler、etcd 等),保证「Kubernetes API 可用,供应对应的算力(节点)、网络、存储、认证资源」;

用户负责进行任务的定制 工作负载长什么样、镜像、网络策略、RBAC、存储类等等(当然你需要的资源,需要在服务端可以获取的资源池中)。根据业务需求,和资源池(cpu/gpu/images等等),构建满足业务需求的yaml 流程。

图 2 托管模式下的责任分界(示意)

图 2 托管 K8s:云侧常包控制面与高可用;用户侧仍配置工作负载、网络策略、身份与存储类等

整体的业务逻辑沿用k8s本身的框架逻辑,我们通过yaml配置,来进行资源、镜像、和任务的声明。

投递第一个argo

4. 与单机 Docker、与生信 / Argo 的边界

  • 单机 docker run:你直接触达本机上的容器进程;没有集群级的调度、多副本控制器、跨节点 Service。
  • 有集群之后:你向 apiserver 声明 Deployment、Job 等对象(图 5 步骤 1~3),由调度器与 kubelet 落到具体节点(步骤 4~5)。
  • Argo Workflows:在 Kubernetes 之上用 CRD 描述 DAG;底层仍是 Pod/Job。因此 Argo 文档里反复出现 kubectl、命名空间、Pod——它们不是 Argo 私有的,而是集群通用语言。

5. 小结

  • 集群在动手层面 = 可访问的 API + 凭证 + 可调度节点;本地单节点也是「真」集群,只是规模小。
  • 路径 A/B/C(图 1)帮助你在「笔记本 / 机房 / 云」之间做方向选择,细节留在各环境自己的安装文档。
  • 托管(图 2)减轻控制面运维,减轻你对工作负载、网络、权限、存储策略的责任。
  • 下一步:在任意一条路径上把集群跑起来后,用 k8s-03kubectl 与命名空间完成日常观测闭环。
-------------本文结束感谢您的阅读-------------