k8s(八)

​ 基于云原生的周边工具

KubeVela

KubeVela 是一个开箱即用的现代化应用交付与管理平台，它使得应用在面向混合云环境中的交付更简单、快捷。使用 KubeVela 的软件开发团队，可以按需使用云原生能力构建应用，随着团队规模的发展、业务场景的变化扩展其功能，一次构建应用，随处运行。

云原生技术的发展趋势正在朝着利用 Kubernetes 作为公共抽象层来实现高度一致的、跨云、跨环境的的应用交付而不断迈进。然而，尽管 Kubernetes 在统一底层基础架构细节方面表现出色，它并没有在混合的分布式部署环境之上提供应用层的软件交付模型和抽象。我们已经看到，这种缺乏统一上层抽象的软件交付过程，不仅降低了生产力、影响了用户体验，甚至还会导致生产中出现错误和故障。

然而，为现代微服务应用的交付过程建模是一个高度碎片化且充满挑战的事情。到目前为止，绝大多数试图解决上述问题的技术方案，要么过于简单以致于无法覆盖实际生产使用中的问题，要么过于复杂难以落地使用。云原生带来的基础设施能力爆发式增长也决定了新一代的应用管理平台不能以硬编码的方式做能力的集成和 UI 的构建，除了满足基础的功能和场景，平台本身的扩展能力成为了新时代应用管理平台的核心诉求。这就意味着平台不仅要简单易用，还要能够随着应用交付和管理的需求复杂度提升能够不断扩张，能够让开发者自助式的接入和使用，充分享受云原生生态的红利。

这也是 KubeVela 出现的核心价值：它既能够简化面向混合环境（多集群/多云/混合云/分布式云）的应用交付过程；同时又足够灵活可以随时满足业务不断高速变化所带来的迭代压力。它本身是一个面向混合交付环境同时又高可扩展的应用交付引擎，满足平台构建者的扩展和自建需求；同时又附加了一系列开箱即用的扩展组件，能够让开发者自助式的开发、交付云原生应用。

与其他系统对比

vs ci/cd(GitHub action gitlab jenkins)

KubeVela 是一个工作在 CI 流程下游的 CD 控制平面（Continuous Delivery Control Plane）。所以 KubeVela 希望你保持现有的 CI 流程，而在需要开始制品部署时让 KubeVela 接管 CD 流程。KubeVela 会给你的 CD 流程带来大量的现代化应用交付最佳实践，比如：声明式交付工作流、可编程的工作流步骤、Pull 模型、多云/多集群交付流程、统一的云服务部署和绑定等等。

如果你已经在 CD 环节中采纳了 GitOps 实践，KubeVela 会更容易跟你的 CI/CD 系统集成，因为 KubeVela 是完全声明式的。只需要把 KubeVela 的应用部署描述文件放置在你的配置仓库当中，所有的 KubeVela 特性（包括声明式交付工作流、多云/多集群交付流程等）就会立刻在你 的 GitOps 流程中出现。

Vs gitops(argoCD fluxCD)

KubeVela 可以基于你的 GitOps 流程，并在此之上增加跨云、跨环境的能力：

• KubeVela 具有一个用户友好且可编程的工作流，可以让你集成现有的交付工具，包括通知和审批体系。
• KubeVela 可以为你提供跨环境交付能力，让你在一个应用中描述多集群的差异化配置并统一的查看状态。

Vs PaaS

传统 PaaS 提供完整的应用程序部署和管理功能，旨在提高开发人员的体验和效率。在这个场景下，KubeVela 也有着相同的目标。

不过，KubeVela 和它们最大的区别在于其可扩展性。

KubeVela 是可编程的。它的交付工作流乃至整个应用交付与管理能力集都是由独立的可插拔模块构成的，这些模块可以随时通过编写 CUE 模板的方式进行增/删/重定义且变更会即时生效。与这种机制相比，传统的 PaaS 系统的限制非常多：它们需要对应用类型和提供的能力进行各种约束来实现更好的用户体验，但随着应用交付需求的增长，用户的诉求就一定会超出 PaaS 系统的能力边界。这种情况在 KubeVela 平台中则永远不会发生。

此外，KubeVela 是一个独立于运行时集群的应用交付控制平面（这是我们认为的下一代 PaaS 系统的合理形态），而现有的 PaaS 则往往选择以插件形式部署在运行时集群当中。

vs Helm

Helm 是 Kubernetes 的包管理器，它能够以 Chart 为一个单元，提供打包、安装和升级的一组 YAML 文件的能力。

KubeVela 作为一个应用交付系统天然可以部署各种制品类型，Kustomize、Kubernetes Yaml 等，当然也包括 Chart。Helm 可以便捷的把 Chart 交付到一个集群，KubeVela 可以帮你把 Chart 交付到多个集群。

当然，KubeVela 还支持其他制品格式比如 Kustomize。

安装

安装Vela UI

$ vela addon enable ~/.vela/addons/velaux

访问

$ vela port-forward addon-velaux -n vela-system 8080:80

核心概念

每一个应用部署计划都由四个部分组成，分别是组件、运维能力、部署策略和工作流。其格式如下

这个 Application 对象会引用 component、trait、policy 以及 workflow step 的类型，这些类型背后是平台构建者（运维团队）维护的可编程模块。可以看到，这种抽象的方式是高度可扩展、可定制的

apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: <name>
spec:
  components:
    - name: <component name>
      type: <component type>
      properties:
        <parameter values>
      traits:
        - type: <trait type>
          properties:
            <traits parameter values>
    - name: <component name>
      type: <component type>
      properties:
        <parameter values>
  policies:
  - name: <policy name>
    type: <policy type>
    properties:
      <policy parameter values>
  workflow:
    - name: <step name>
      type: <step type>
      properties:
        <step parameter values>   

• 组件（Component）: 组件定义一个应用包含的待交付制品（二进制、Docker 镜像、Helm Chart...）或云服务。我们认为一个应用部署计划部署的是一个微服务单元，里面主要包含一个核心的用于频繁迭代的服务，以及一组服务所依赖的中间件集合（包含数据库、缓存、云服务等），一个应用中包含的组件数量应该控制在约 15 个以内。
• 运维特征（Trait）: 运维特征是可以随时绑定给待部署组件的、模块化、可拔插的运维能力，比如：副本数调整（手动、自动）、数据持久化、 设置网关策略、自动设置 DNS 解析等。
• 应用策略（Policy）: 应用策略负责定义指定应用交付过程中的策略，比如多集群部署的差异化配置、资源放置策略、安全组策略、防火墙规则、SLO 目标等。
• 工作流步骤（Workflow Step）: 工作流由多个步骤组成，允许用户自定义应用在某个环境的交付过程。典型的工作流步骤包括人工审核、数据传递、多集群发布、通知等。

以上这些概念的背后都是由一组称为模块定义（Definitions）的可编程模块提供具体功能。KubeVela 会像胶水一样基于 Kubernetes API 定义基础设施定义的抽象并将不同的能力组合起来

Cue

Cue是自动化配置的一种语言。Dagger也使用这种语言

Kubespray

Kubespray 是由若干 Ansible Playbook、 清单（inventory）、 制备工具和通用 OS/Kubernetes 集群配置管理任务的领域知识组成的。

Kubespray 提供：

• 高可用性集群
• 可组合属性（例如可选择网络插件）
• 支持大多数流行的 Linux 发行版
• 持续集成测试

Kubespray 能够自定义部署的许多方面：

• 选择部署模式： kubeadm 或非 kubeadm
• CNI（网络）插件
• DNS 配置
• 控制平面的选择：本机/可执行文件或容器化
• 组件版本
• Calico 路由反射器

• 组件运行时选项

  • Docker
  • containerd
  • CRI-O
• 证书生成方式

可以修改变量文件以进行 Kubespray 定制。 如果你刚刚开始使用 Kubespray，请考虑使用 Kubespray 默认设置来部署你的集群并探索 Kubernetes。

Kubespray 提供了一种使用 Netchecker 验证 Pod 间连接和 DNS 解析的方法。 Netchecker 确保 netchecker-agents Pod 可以解析 DNS 请求， 并在默认命名空间内对每个请求执行 ping 操作。 这些 Pod 模仿其他工作负载类似的行为，并用作集群运行状况指示器。

KubeKey

Kubeblocks

CAPI/LCM

云原生的核心之一是 Kubernetes，而 Kubernetes 的核心之一是集群生命周期管理（LCM）。解决了 LCM 的管理问题，可以一定程度上降低 Kubernetes 的使用成本。本文将主要探讨 LCM 相关问题。

LCM 包括但不局限于：

• 集群创建
• 集群删除
• 集群扩缩容，增加或减少节点数
• 集群升级，集群从低版本升级到更高的版本
• 集群故障恢复，集群出现故障，例如某节点故障，修复节点故障恢复正常工作

社区目前常用 kubeadm、kOps、kubespray、RKE、kubekey 等工具创建、扩容和升级集群。公有云和私有云则有自己的 Kubernetes 服务，但这些服务一般仅限本平台，对跨平台支持不友好。此外还有 Rancher、KubeSphere 等开源或商业化的容器平台，但它们没有通用的多平台支持，LCM 功能不丰富或是不够自动化。

以上 LCM 方案可能存在的问题：

• 需要掌握一定的 Kubernetes 相关知识和经验
• 不够自动化，手工管理，命令行工具或没有 UI，效率低，容易出错
• 没有形成统一的技术标准，各自有自己的技术方案，可扩展性不强
• 跨平台支持不够好

Cluster API（CAPI）是一个 Kubernetes 声明式 API 风格的多 Kubernetes 集群生命周期管理项目。CAPI 的目标是简化 Kubernetes LCM，使得 LCM 自动化，并支持不同的 IaaS（AWS、VMware 等）。

Kubernetes 声明式 API 通过 Resource + Controller 的模式实现。Resource 包括 Kubernetes 原生资源（Pod 等）和自定义资源（CRD）。每个资源对象包含 Spec 表示资源对象预期是什么样的，Status 表示预期资源对象当前的实际状态，Controller 则负责把资源达到预期的 Spec 状态。

在此基础上，Kubernetes 社区发展出了 Operator 模式，用来管理应用和基础设施资源（例如 prometheus-operator）

Kubernetes 声明式 API 具有组合的特点，不同的 API 可以组合使用，达到功能扩展的目的。例如 Deployment + ReplicaSet + Pod 组合实现多版本应用部署管理。

目前常见通过声明式的方式管理分布式系统，而 Kubernetes 本身也是分布式系统，所以通过声明式管理 Kubernetes 集群是合适的。

CAPI 属于 Kubernetes Cluster Lifecycle 生态中的子项目，使用 Kubernetes 声明式风格也是比较天然的（Kube-On-Kube）。可以借用 Kubernetes 生态的优势，同时社区用户也更容易理解和使用。

声明式可以带来以下好处：

• 使用配置文件描述最终状态，不需要考虑流程和目标环境的细节
• 重复操作不会产生不一致的效果
• 天然符合不可变基础设施的理念
• 声明式自愈保证高可用

根据 Kubernetes 声明式 API 的特点，当我们需要一个 Kubernetes 集群的时候，可以通过一个 CRD 定义并描述我们的需求。CAPI 定义了 Cluster 用来描述 Kubernetes 集群

apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:  
	name: mycluster  
	namespace: default
spec: # 需要一个什么样的集群
status: # 当前集群的状态

CAPI controllers 根据 Cluster 创建并管理集群。

CAPI 部署所在的 Kubernetes 集群称为管控集群（Management Cluster），基于 CAPI 创建的 Kubernetes 集群称为工作负载集群（Workload Cluster）

管控集群主要由 CAPI 和 CAPI Providers 组成。

• CAPI：集群的基础管理工作、Worker 节点的生命周期管理、协调 Providers 完成集群 LCM 工作；
• Infrastructure Provider：管理集群所需要的基础设施资源
• ControlPlane Provider：Control Plane 节点的生命周期管理
• Bootstrap Provider：部署节点

节点是集群的核心，节点的管理也是集群管理的重要部分。节点分为 Control Plane 和 Worker 节点，两者的角色和功能不一样，管理起来也有差异。

一个 Worker 节点包含多个 Kubernetes 组件程序（kubelet 等），集群升级过程会存在多个版本的节点同时存在的情况。这些特点和 Pod 有些相似之处，因此 CAPI 借鉴了 Deployment 的设计理念：MachineDeployment (MD) + MachineSet (MS) + Machine (Pod)，每个 MachineSet 管理同一个版本的节点

Control Plane 节点是集群的控制面，业务逻辑和 Worker 节点不一样，除了有 kubelet 还有 APIServer、Etcd 等不同的组件。

Control Plane 节点目前常见以下几种管理方式：

• 集群自身管理，例如 kubeadm 通过 static pods 运行 Control Plane 节点
• 额外的 Kubernetes 集群部署，使用 Deployment 和 StatefulSet 的形式部署 Control Plane 节点
• 第三方托管，例如 GKE、AKS、EKS 等

CAPI 提供了 ControlPlane Provider 的概念，我们可以根据不同的 Control Plane 节点

管理方式而选择不同的 Provider。CAPI 默认提供了 KubeadmControlPlane（KCP）管理 Control Plane 节点。

多平台

不同的 IaaS 管理 Kubernetes 集群会有差异。CAPI 封装了每个 IaaS 通用的 LCM 数据和逻辑，每个 IaaS 只需要处理自己特有的相关逻辑。为此 CAPI 提出了 Infrastructure Provider 的概念，每个 IaaS 按照规范实现即可（参考 Provider Implementers）。Provider 体现了 CAPI 利用 Kubernetes 声明式 API 抽象和组合的作用，带来了可以支持不同 IaaS 集群管理的可扩展性

CRI、OCI、CRI-O、RUNC和containerd

CRI（Container Runtime Interface，容器运行时接口）是kubernetes定义的接口，定义了如何操作容器和镜像的统一规范，它主要包含ImageService和ContainerService。因为它已经是一个标准，所以你可以选择任何一个CRI的实现（ containerd和CRI-O）来使用。

CRI-O也是一个CRI的实现，它来自于Red Hat/IBM等

OCI（Open Container Initialtive）提供了容器镜像和运行容器的规范。runc是OCI的一个实现，它是一个创建和运行容器进程的工具。

RUNC 实际上是从libcontainer演化过来的，并且是docker贡献给社区的第一个OCI参考实现，它就是用来创建和运行容器进行的工具。

containerd是容器虚拟化技术，从docker中剥离出来，形成开放容器接口（OCI）标准的一部分。

docker对容器的管理和操作基本都是通过containerd完成的。Containerd 是一个工业级标准的容器运行时，它强调简单性、健壮性和可移植性。Containerd 可以在宿主机中管理完整的容器生命周期：容器镜像的传输和存储、容器的执行和管理、存储和网络等。详细点说，Containerd 负责干下面这些事情

管理容器的生命周期(从创建容器到销毁容器) 拉取/推送容器镜像 存储管理(管理镜像及容器数据的存储) 调用 runC 运行容器(与 runC 等容器运行时交互) 管理容器网络接口及网络

Podman

管理节点oci

https://github.com/containers/podman

Rook

rook是面向k8s的分布式存储框架

https://github.com/rook/rook

Ansible

Ansible 是使用 Python 开发的自动化运维工具，如果这么说比较抽象的话，那么可以说 Ansible 可以让服务器管理人员使用文本来管理服务器，编写一段配置文件，在不同的机器上执行。

Ansible 使用 YAML 作为配置文件，YAML 是一个非常节省空间，并且没有丧失可读性的文件格式，其设计参考了很多语言和文件格式，包括 XML，JSON，C 语言，Python，Perl 以及电子邮件格式 RFC2822 等等。

Ansible 解决的问题正是在运维过程中多机器管理的问题。当有一台机器时运维比较简单，当如果要去管理 100 台机器，复杂度就上升了。使用 Ansible 可以让运维人员通过简单直观的文本配置来对所有纳入管理的机器统一进行管理。如果再用简单的话来概述 Ansible 的话，就是定义一次，无数次执行。

Ansible的主要工作

• 定义目标机器列表，也就是需要管理的机器
• 定义配置，使用 YAML 文件配置任务
• 执行具体任务

Ansible的特性

• 低学习成本
• 无需在服务器中安装客户端，基于 SSH 工作，可并行执行
• 无需服务端，直接终端命令即可
• 管理的对象可以包括物理机，虚拟机，容器等等
• 使用 YAML 格式文件编排 playbook

基本概念

Ansible 中的一些概念。

• control node: 控制节点，可以在任何安装了 Python 环境的机器中使用 ansible，两个重要的可执行文件在 /usr/bin/ansible 和 /usr/bin/ansible-playbook
• managed node: 被控制的节点
• inventory: 需要管理的节点，通常配置成 hostfile 文件 1
• modules: ansible 进行自动化任务时调用的模块，社区提供了非常多 modules
• Task: Ansible 的执行单元
• playbook: 编排多个任务
• roles: roles 是将 playbook 划分多个部分的机制
• plugins: ansible 插件

工作流程：

• 读取配置
• 获取机器列表及分组配置
• 确定执行模块和配置，modules 目录动态读取
• Runner 执行
• 输出

ubuntu安装

sudo apt update
sudo apt install software-properties-common
sudo apt-add-repository --yes --update ppa:ansible/ansible
sudo apt install ansible

配置

ansible.cfg 文件是 Ansible 中最主要的配置文件，ansible 寻找配置文件按照如下的优先级进行：

• 由环境变量 ANSIBLE_CONFIG 指定的文件
• ./ansible.cfg (ansible.cfg in the current directory)
• ~/.ansible.cfg (.ansible.cfg in your home directory)
• /etc/ansible/ansible.cfg

最简单的 ansible.cfg 配置示例：

[defaults]
hostfile = hosts
remote_user = root
remote_port = 22
host_key_checking = False

• Hostfile

  文件指定了当前文件夹下的 hosts 文件。hosts 文件中会配置需要管理的机器 host

  • 配置 SSH 免密登录的文章可以参考之前的文章.
• remote_user 配置默认操作的用户，如果没有配置，默认会使用当前用户
• host_key_checking: 禁用 SSH key host checking

Host Inventory 主机清单

Host Inventory 是配置文件，用来告诉 Ansible 需要管理哪些主机。并且把这些主机根据按需分类。

可以根据用途分类：数据库节点，服务节点，nginx 节点、构建机器节点

默认的配置文件在：/etc/ansible/hosts，可以通过 -i 参数指定配置文件的

playbook

Playbook 是由一个或多个 play 组成的列表，针对每一组 server 的所有操作就组成一个 play。Playbook 的主要功能在于将事先归并为一组的主机装扮成事先通过 ansible 中的 task 定义好的角色。从根本上来讲，所谓 task 无非是调用 ansible 的一个 module。在写 Playbook 的时候，一定要记住在 hosts、模块名等后面带空格，否则会报错。 执行 Playbook

ansible-playbook deploy.yml

在运行 Playbook 的时候也可以传递一些变量供 Playbook 使用

ansible-playbook test.yml --extra-vars "hosts=mysql user=jaydenz"

playbook关键字

hosts 、remote_users、tasks

- hosts: mysql       #指明执行任务的主机，可以是一个或多个由冒号分隔主机组
  remote_user: root  #指定远程主机上执行任务的用户
  tasks:             #建立一个任务列表
    - name: Test To Connect MySQL Server #任务名
      ping:
      remote_user: root                  #在tasks中也可以定义执行的用户身份
      sudo: yes                          #指定使用sudo方式运行
      sudo_user: jaydenz                 #指定sudo时切换的用户

Playbook 的核心，定义按顺序执行的动作 action，每个 action 调用一个 ansbile module，如果中途发生错误所有任务将会回滚。每个 Task 都需要使用 - name 指定一个名用于 Playbook 的执行结果输出，如果未提供 name，则 Action 的结果将用于输出。

roles: ansilbe 自 1.2 版本引入的新特性，用于层次性、结构化地组织 playbook。roles 能够根据层次型结构自动装载变量文件、tasks 以及 handlers 等。要使用 roles 只需要在 playbook 中使用 include 指令即可。简单来讲，roles 就是通过分别将变量、文件、任务、模块及处理器放置于单独的目录中，并可以便捷地 include 它们的一种机制。角色一般用于基于主机构建服务的场景中，但也可以是用于构建守护进程等场景中

https://einverne.github.io/post/2020/05/ansible-introduction.html#%E5%B0%8F%E7%BB%93

https://www.cnblogs.com/michael-xiang/p/10426159.html

https://ansible-tran.readthedocs.io/en/latest/docs/playbooks.html

karpenter

https://github.com/aws/karpenter

gitkube

使用git push在k8s中发布镜像

安装gitkube

kubectl create -f https://raw.githubusercontent.com/hasura/gitkube/master/manifests/gitkube-setup.yaml

#expose gitkubed service
kubectl --namespace kube-system expose deployment gitkubed --type=LoadBalancer --name=gitkubed

https://github.com/hasura/gitkube