k8s(九)

​ 基于云原生的周边工具

Kubefwd

kubectl 有自带的端口转发命令kubectl port-forward

可以将本地端口转发到指定 Pod 的端口

# Listen on ports 5000 and 6000 locally, forwarding data to/from ports 5000 and 6000 in the pod
kubectl port-forward mypod 5000 6000

# Listen on port 8888 locally, forwarding to 5000 in the pod
kubectl port-forward mypod 8888:5000

# Listen on a random port locally, forwarding to 5000 in the pod
kubectl port-forward mypod :5000

# Listen on a random port locally, forwarding to 5000 in the pod
kubectl port-forward mypod 0:5000

也可以将本地端口转发到服务、复制控制器或者部署的端口。

# Forward to deployment
kubectl port-forward deployment/redis-master 6379:6379

# Forward to replicaSet
kubectl port-forward rs/redis-master 6379:6379

# Forward to service
kubectl port-forward svc/redis-master 6379:6379

kubefwd 是一个用于端口转发Kubernetes中指定namespace下的全部或者部分pod的命令行工具。 kubefwd 使用本地的环回IP地址转发需要访问的service，并且使用与service相同的端口。 kubefwd 会临时将service的域条目添加到 /etc/hosts 文件中

安装

brew install txn2/tap/kubefwd

kubefwd 默认你已经安装了 kubectl 工具并且也已经设置好了访问Kubernetes集群的配置文件。kubefwd 使用 kubectl 的上下文运行环境. kubectl 工具并不会用到，但是它的配置文件会被用来访问Kubernetes集群。

使用前首先确保上下文运行环境

kubectl config current-context

启动kubefwd后，在本地就能像在Kubernetes集群中一样使用service名字与端口访问对应的应用程序。

sudo kubefwd services -n the project

转发namespace the-project下所有的带有label为system: wx的service\

sudo kubefwd svc -l system=wx -n the-project

Kubeshark

Kubeshark由2021年UP9公司开源的K8s API流量查看器 Mizu 发展而来，试图成为一款K8s全过程流量监控工具

Kubeshark 也被叫做 Kubernetes 的可观测性工具，可以对微服务进行动态分析，检测异常并在运行时出现某些模式时触发功能。

1. 可以将 Kubeshark 视为 Wireshark、BPF 编译器集合 (BCC) 工具等的 Kubernetes 感知组合。
2. Kubeshark 可以嗅探集群中的部分或所有 TCP 流量，将其记录到 PCAP 文件中并剖析。
3. Kubeshark 使用 eBPF 来跟踪内核空间和用户空间中的函数调用。

Kubeshark 由三个不同的软件组成，它们可以协同工作：CLI、Hub 和 Worker。

1. CLI，它是客户端的 二进制文件，通过 K8s API 与集群通信。
2. Hub，它协调 worker 部署，接收来自每个 worker 的嗅探和剖析，并收集到一个中心位置。它还提供一个Web界面，用于在浏览器上显示收集到的流量。
3. Work，作为 DaemonSet 部署到集群中，以确保集群中的每个节点都被 Kubeshark 覆盖。

在底层实现当中，Kubeshark主要使用到了Linux内核中的各种内置方法和API，隐藏了对流量数据的加解密实现，可以直接收集到K8s集群中的加密和未加密流量。对网络数据的收集主要使用了直接抓包法和基于拓展伯克利包过滤（eBPF）的数据包获取。直接抓包法涉及libpcap、AF_PACKET和PF_RING获取集群TCP流量，eBPF的方法主要使用到了加密流量 (TLS)，并挂钩到OpenSSL库和 Go 的crypto/tls包中某些函数的入口点和出口点。

Kubeshark具体功能

网络嗅探

Kubeshark 可以使用 Linux 内核中内置的各种方法和 API 嗅探集群中的加密和未加密流量。

1. 直接抓包，直接使用 libpcap、AFPACKET 和 PFRING 嗅探集群中的 TCP 流量，并将其记录到 PCAP 文件中。例如在使用服务网格的场景中，Kubeshark 会自动检测任何 Envoy Proxy并将其包含到其 TCP 数据包捕获源列表中。
2. 基于 eBPF 抓包，基于 eBPF 的数据包捕获使用 eBPF 嗅探集群中的加密流量 (TLS)，而无需实际进行解密。事实上，它挂钩到 OpenSSL 库和 Go 的 crypto/tls 包中某些函数的入口点和出口点。

查询

内核跟踪

Kubeshark 使用 🐝 eBPF（扩展伯克利数据包过滤器）提供跟踪内核空间和用户空间功能。

kubeshark tap --tls -n harbor

流量校验

服务地图

部署完成后，Kubeshark CLI 将在 http://localhost:8899 打开 UI 单击右上角名为 Service Map 的按钮打开服务依赖关系图。该图根据网络流量显示 Pod 以及它们之间的关系。

数据脱敏

Kubeshark 捕获的流量包含敏感信息。用户可以配置 Kubeshark 以隐藏某些关键字或数据片段将在 UI 中显示为 [REDACTED]。

默认的脱敏字段 “token”, “authorization”, “authentication”, “cookie”, “userid”, “password”, “username”,

“user”, “key”, “passcode”, “pass”, “auth”, “authtoken”, “jwt”, “bearer”, “clientid”,

“clientsecret”, “redirecturi”, “phonenumber”, “zip”, “zipcode”, “address”, “country”,

“firstname”, “lastname”, “middlename”, “fname”, “lname”, “birthdate”

Kubeshark Cli指南

• check：检查 Kubeshark 安装是否存在潜在问题
• clean：删除所有 kubeshark 资源
• completion：为指定的 shell 生成自动完成脚本
• config：使用默认值生成配置
• help：帮助文档
• install：安装 kubeshark 组件
• logs：创建一个包含 Github 问题或故障排除日志的 zip 文件
• tap：记录 kubernetes pod 的传入流量
• version：打印版本信息
• view：在浏览器中打开 GUI

命令

kubeshark tap catalogue-b87b45784-sxc8q: 监控指定的Pod

kubeshark tap "(catalo*|front-ent*)": 使用正则表达式监控一组Pod

kubeshark tap -n sock-shop:指定监控的Namespace

kubeshark tap -A指定所有Namespace

okteto

Odigos

K8s监控利器

https://github.com/keyval-dev/odigos

KubeVirt

管理K8s集群上的虚拟化服务，介绍：https://moelove.info/2023/09/01/%E8%80%97%E6%97%B6-7-%E5%B9%B4%E7%BB%88%E5%B0%86%E8%99%9A%E6%8B%9F%E6%9C%BA%E5%B8%A6%E5%85%A5-Kubernetes-%E4%B8%96%E7%95%8C/

随着云计算和容器技术的发展，Kubernetes 已经成为了业界的标准和领导者，为用户提供了一个强大，灵活和可扩展的平台，来部署和管理各种类型的应用。

然而，对于一些难以容器化的应用，例如传统的企业应用，遗留的系统，或者需要特殊硬件支持的应用，虚拟机仍然是一个必要和有效的解决方案。 如何在 Kubernetes 上运行和管理虚拟机，以及如何实现容器和虚拟机之间的互操作性和一致性，是一个亟待解决的问题。

这就是 KubeVirt 项目诞生的背景和目标。

KubeVirt 是一个开源项目，它使得虚拟机可以像容器一样被 Kubernetes 部署，消费和管理。它提供了一个统一的平台，让用户可以根据不同的需求，使用容器或者虚拟机来构建云原生应用。KubeVirt 项目于 2016 年启动，由 Red Hat, IBM, Google, Intel, SUSE 等多家公司和组织共同推动和贡献。经过 7 年的不懈努力，KubeVirt 于 2023 年 7 月发布了 v1.0.0 版本，标志着它已经达到了生产就绪的水平，并且有着健康的社区。(在此之前，它已经被很多公司用到了生产环境)

KubeVirt 的想法最早可以追溯到 2015 年，在第一届 KubeCon 上 Red Hat 的工程师 Fabian Deutsch 提出了一个问题：能否在 Kubernetes 上运行虚拟机？当时的回答是不确定的，但是这个问题引起了很多人的兴趣和讨论。在接下来的一年里，Fabian Deutsch 和他的同事开始了一些原型和实验性的工作，探索了不同的方案和技术。最终，他们选择了使用 libvirt 和 QEMU 来实现虚拟机在 Kubernetes 上的运行和管理。

在 2016 年底，KubeVirt 项目正式启动，并在 GitHub 上开源。项目的主要目标是提供一个 Kubernetes 原生的虚拟化 API 和运行时，让用户可以像使用 Pod 和 Deployment 一样使用 VirtualMachine 和 VirtualMachineInstance 来定义和管理虚拟机。项目的主要挑战是如何将虚拟机与 Kubernetes 的资源模型，调度器，网络，存储等组件进行集成和协调。

在接下来的几年里，KubeVirt 项目经历了多个阶段和版本的迭代和改进。其中一些重要的里程碑包括：

• 2017 年底，KubeVirt 实现了基本的虚拟机创建和删除功能，并发布了 v0.1.0 版本。
• 2018 年初，KubeVirt 重新设计了 VirtualMachine 的 API，并发布了 v0.2.0 版本。
• 2018 年中，KubeVirt 兼容了 Kubernetes 的网络，以及离线虚拟机支持，并发布了 v0.3.0 版本。
• 2018 年底，KubeVirt 支持了初始化空 PV，以及 liveness 和 readiness，并发布了 v0.9.0 ~ v0.11.0 版本。
• 2019 年中，KubeVirt 支持了 virtctl migrate，并发布了 v0.21.0 版本。
• 2022 年初，KubeVirt 移除了旧的对 GPU 设备的支持，可以通过统一的方式进行定义，并发布了 v0.50.0 版本。
• 2023 年中，KubeVirt 发布了 v1.0.0 版本。

其实可以看到 KubeVirt 虽然一直没有发布 v1.0 版本，但是却一直保持着比较频繁的发布频率。 在这个过程中，KubeVirt 的社区也不断地壮大和活跃。截至目前，KubeVirt 的 GitHub 仓库已经有超过 270 个贡献者，超过 17k 提交，超过 4.5k star。

KubeVirt 的用户和合作伙伴也在不断地增加，包括 IBM, Google, Intel, SUSE, Red Hat, Huawei, VMware, Canonical, Rancher 等多家知名公司和组织

KubeVirt 的核心功能是在 Kubernetes 上运行和管理虚拟机。为了实现这个功能，KubeVirt 提供了以下几个方面的解决方案

KubeVirt 定义了一套 Kubernetes 原生的虚拟化 API，让用户可以像使用 Pod 和 Deployment 一样使用 VirtualMachine 和 VirtualMachineInstance 来定义和管理虚拟机。VirtualMachine 是一种声明式的资源类型，表示一个期望的虚拟机状态。VirtualMachineInstance 是一种实时的资源类型，表示一个正在运行的虚拟机实例。用户可以通过 YAML 文件或者 kubectl 命令来创建，更新，删除或者查询这些资源。

KubeVirt 实现了一套虚拟化运行时，让用户可以在 Kubernetes 集群中的任何节点上运行和管理虚拟机。KubeVirt 的运行时主要由以下几个组件构成：

• virt-controller：负责监控和调谐虚拟机的状态，以及处理虚拟机的生命周期事件，如创建，删除，启动，停止，迁移等。
• virt-handler：负责在每个节点上执行虚拟机的操作，如启动，停止，暂停，恢复等。它也负责与 libvirt 和 QEMU 进行通信，以及收集和报告虚拟机的性能指标。
• virt-operator：负责在每个节点上启动和管理 libvirt 和 QEMU 进程。
• virt-api：负责提供虚拟化 API 的服务端点，以及验证和转换用户的请求

KubeVirt 支持多种网络插件和方案，让用户可以根据不同的需求，为虚拟机提供合适的网络连接和配置。KubeVirt 的网络解决方案主要包括以下几种：

• Pod 网络：这是最简单和最常用的网络方案，它让虚拟机共享 Pod 的网络命名空间和接口。这样，虚拟机就可以像 Pod 一样访问集群内外的网络资源，并且可以被集群内外的网络资源访问。
• 多网络：这是一种更灵活和更高级的网络方案，它让虚拟机可以有多个网络接口，并且可以连接到不同的网络平面。这样，虚拟机就可以根据不同的用途和场景，使用不同的网络策略和配置。例如，一个虚拟机可以有一个用于管理的网络接口，一个用于数据传输的网络接口，和一个用于公网访问的网络接口。
• 桥接网络：这是一种更接近传统虚拟化的网络方案，它让虚拟机可以直接使用节点上的物理网络接口和地址。这样，虚拟机就可以像物理机一样，与节点上的其他设备进行通信，并且可以使用节点上的网络安全和监控工具。
• SR-IOV 网络：这是一种更高性能和更低延迟的网络方案，它让虚拟机可以直接使用节点上的物理网卡的虚拟功能。这样，虚拟机就可以绕过软件层的开销，直接访问硬件层的资源，并且可以享受硬件层的加速和优化。

KubeVirt 支持多种存储插件和方案，让用户可以根据不同的需求，为虚拟机提供合适的存储空间和配置。KubeVirt 的存储解决方案主要包括以下几种：

• 容器磁盘：这是一种基于容器镜像的存储方案，它让虚拟机可以使用容器镜像作为其根磁盘。这样，虚拟机就可以像容器一样，快速地启动和停止，并且可以享受容器镜像的便利和安全性。
• 持久卷：这是一种基于 Kubernetes 的存储方案，它让虚拟机可以使用 Kubernetes 的持久卷（PV）和持久卷声明（PVC）作为其数据磁盘。这样，虚拟机就可以像 Pod 一样，使用 Kubernetes 的存储类（StorageClass）来动态地申请和释放存储空间，并且可以使用 Kubernetes 的存储插件来连接到不同的存储后端。
• 主机磁盘：这是一种基于节点的存储方案，它让虚拟机可以使用节点上的本地磁盘或者目录作为其数据磁盘。这样，虚拟机就可以利用节点上的存储性能和容量，并且可以避免网络层的开销和延迟。
• CDI 磁盘：这是一种基于 CDI（Containerized Data Importer）项目的存储方案，它让用户可以从不同的来源（如 HTTP, S3, Registry 等）导入或者克隆数据到 Kubernetes 的持久卷中，并且可以自动地转换数据的格式（如 qcow2, raw, vmdk 等）。这样，用户就可以方便地将现有的虚拟机镜像或者数据迁移或者复制到 Kubernetes 中，并且可以使用 KubeVirt 来运行和管理它们。

KubeVirt 支持多种镜像插件和方案，让用户可以根据不同的需求，为虚拟机提供合适的镜像源和配置。KubeVirt 的镜像解决方案主要包括以下几种：

• 容器镜像：这是一种基于容器技术的镜像方案，它让用户可以使用容器镜像作为虚拟机的根磁盘或者 CD-ROM。这样，用户就可以利用容器技术的优势，如轻量级，快速启动，易于分发，安全隔离等。
• 虚拟机镜像：这是一种基于传统虚拟化技术的镜像方案，它让用户可以使用虚拟机镜像作为虚拟机的初始化配置

Kail

K8s日志工具

安装

$ brew tap boz/repo
$ brew install boz/repo/kail

使用

# match pods belonging to a replicaset named 'workers' in any namespace.
$ kail --rs workers

# match pods belonging to the replicaset named 'workers' only in the 'staging' namespace
$ kail --rs staging/workers

# match pods belonging to both the service "frontend" and the deployment "webapp"
$ kail --svc frontend --deploy webapp

Rainbond

Rainbond 遵循 以应用为中心 的设计理念，统一封装容器、Kubernetes和底层基础设施相关技术，让使用者专注于业务本身, 避免在业务以外技术上花费大量学习和管理精力。同时，Rainbond 深度整合应用开发、微服务架构、应用交付、应用运维、资源管理，管理高度自动化，实现统一管理所有应用、所有基础设施和所有IT流程。

Rainbond 通过“无侵入”技术，让传统应用不需要改动或少量改动就能快速变成云原生应用。 传统应用转成成云原生应用的方式：

• 有源代码和软件包的应用，平台自动识别开发语言类型和包类型，不改变开发者习惯，代码直接编译、构建成支持云原生特性的应用。
• 对于想实现微服务架构的传统应用，Rainbond提供Service Mesh 微服务架构，应用不改代码就能变成微服务架构。
• 传统应用想要扩展运维和治理功能，Rainbond提供“无侵入”的插件，按需加载插件，开启运维和服务治理能力。

Rainbond能将企业内部各种数字化能力一键发布成组件，并具备组件安装使用、组件编排、组件版本管理、组件升级和持续迭代等完整的管理流程，将企业内部可复用的能力积累到组件库，既避免重复建设，还能将这些组件变成数字资产，为企业创新提供动力。

Rainbond提供企业应用的业务集成、多云交付、私有交付、SaaS交付、离线交付、个性化交付、应用市场等能力，将交付过程最大限度自动化，提高企业应用交付效率，降低交付成本

https://www.rainbond.com/docs/

Kube-rs

rust的kubernetes客户端

https://liangyuanpeng.com/post/fundation-rust/quick-start-kubernetes-client-rust/

KubeSphere

KubeSphere 是在 Kubernetes 之上构建的面向云原生应用的分布式操作系统，完全开源，支持多云与多集群管理，提供全栈的 IT 自动化运维能力，简化企业的 DevOps 工作流。它的架构可以非常方便地使第三方应用与云原生生态组件进行即插即用 (plug-and-play) 的集成。

作为全栈的多租户容器平台，KubeSphere 提供了运维友好的向导式操作界面，帮助企业快速构建一个强大和功能丰富的容器云平台。KubeSphere 为用户提供构建企业级 Kubernetes 环境所需的多项功能，例如多云与多集群管理、Kubernetes 资源管理、DevOps、应用生命周期管理、微服务治理（服务网格）、日志查询与收集、服务与网络、多租户管理、监控告警、事件与审计查询、存储管理、访问权限控制、GPU 支持、网络策略、镜像仓库管理以及安全管理等。

KubeSphere 还开源了 KubeKey 帮助企业一键在公有云或数据中心快速搭建 Kubernetes 集群，提供单节点、多节点、集群插件安装，以及集群升级与运维。

KubeSphere 为用户屏蔽了基础设施底层复杂的技术细节，帮助企业在各类基础设施之上无缝地部署、更新、迁移和管理现有的容器化应用。通过这种方式，KubeSphere 使开发人员能够专注于应用程序开发，使运维团队能够通过企业级可观测性功能和故障排除机制、统一监控和日志查询、存储和网络管理，以及易用的 CI/CD 流水线等来加快 DevOps 自动化工作流程和交付流程等。

KubeSphere 作为开源的企业级全栈化容器平台，为用户提供了一个健壮、安全、功能丰富、具备极致体验的 Web 控制台。拥有企业级 Kubernetes 所需的最常见的功能，如工作负载管理，网络策略配置，微服务治理（基于 Istio），DevOps 项目 (CI/CD) ，安全管理，Source to Image/Binary to Image，多租户管理，多维度监控，日志查询和收集，告警通知，审计，应用程序管理和镜像管理、应用配置密钥管理等功能模块。

它还支持各种开源存储和网络解决方案以及云存储服务。例如，KubeSphere 为用户提供了功能强大的云原生工具负载均衡器插件 OpenELB，这是为 Kubernetes 集群开发的 CNCF 认证的负载均衡插件。

生态：https://kubesphere.io/zh/docs/v3.3/pluggable-components/app-store/

Kubekey

KubeKey 允许用户直接在基础架构上部署 Kubernetes，为 Kubernetes 集群提供高可用性。建议在生产环境至少配置三个主节点。

KubeKey 提供了一种简单的安装，管理和维护方式。它支持 Kubernetes 集群的滚动升级，以便集群服务在升级时始终可用。另外，也可以使用 KubeKey 将新节点添加到 Kubernetes 集群中以使用更多工作负载。

Pg for K8s

https://portworx.com/blog/choosing-a-kubernetes-operator-for-postgresql/

https://github.com/CrunchyData/postgres-operator/

https://github.com/zalando/postgres-operator

https://github.com/ankane/pgsync

Google K8s Engine

Kube-monkey

Kube-cube

KubeCube (https://kubecube.io) 是一个轻量化的企业级容器平台，为企业提供 kubernetes 资源可视化管理以及统一的多集群多租户管理功能，具有简化应用部署、管理应用的生命周期和丰富的监控和日志审计能力。Cube 有魔方之意，寓意通过 KubeCube 的能力组合，企业可以快速构建一个强大和功能丰富的云原生底座，并增强 DevOps 团队的能力。下面我们具体来看 KubeCube 这个魔方的六面，都提供了哪些能力

KubeCube 针对用户的使用场景提供了多种部署方式：适用于 POC 环境的 All In One 部署，适用于生产环境的多节点高可用部署。仅需要一条命令即可完成 Kubernetes+KubeCube 的部署，同时提供了开箱即用的多集群管理、多租户、可观测功能。

同时考虑到企业可能已有部分能力建设，如日志平台等，KubeCube 可以只部署核心服务，提供多集群多租户能力，可观测等组件可以通过热插拔的方式开启或关闭，同时通过热插拔配置完成用户已有系统对接，用户可以根据实际场景灵活选择。

Vault

Vault提供令牌管理，基于K8s的令牌管理系统

https://github.com/hashicorp/vault

Packer

自动构建镜像

kube-state-metrics

k8s监控库

https://github.com/kubernetes/kube-state-metrics#kubernetes-version

kube-metrics-server

https://github.com/kubernetes-sigs/metrics-server

kyverno

https://github.com/kyverno/kyverno

gate-keeper

https://github.com/open-policy-agent/gatekeeper

Cosign

Kubernetes 的供应链安全需求中，有一个重要的镜像签署和校验的环节

https://www.sigstore.dev/

这个工具的最基础功能有三个，分别是生成密钥对、镜像签名和校验签名。

生成密钥对

cosign generate-key-pair
Enter password for private key:
Enter again:
Private key written to cosign.key
Public key written to cosign.pub

执行命令之后，输入密码，就会生成密钥对文件，私钥和公钥分别是 consign.key 和 cosign.pub

签名

可以使用前边生成的密钥对进行签名，例如我的工具镜像

cosign sign -key cosign.key dustise/sleep:v0.9.6
Enter password for private key:
Pushing signature to: index.docker.io/dustise/sleep:sha256-92dad62e00d08157a3921b7d7b568a247a8b24e8a067ad5dc20b210d7b1c2ad1.cosign

这个功能是对仓库中镜像的哈希码生效的，因此签署过程无需本地镜像的参与，cosign 会直接在镜像仓库中获取对应 tag 的 sha256 内容，签署之后生成一个 OCI 镜像推送到该镜像的原有仓库之中，例如前面为 dustise/sleep:v0.9.6 进行签名，就生成了一个 dustise/sleep:sha256-92da.....1c2ad1.cosign 的镜像。如果被签名镜像在本地不存在，在完成操作之后，使用 docker images 命令查看，会发现被签署镜像和签署生成的镜像都不存在于本地。

另外一个就是，因为这里有 Push 操作，因此这个签署过程通常是有登录镜像库的需求的

校验过程很简单，使用 verify 指令，指定公钥即可

cosign verify  -key cosign.pub dustise/sleep:v0.9.6
The following checks were performed on each of these signatures:
- The cosign claims were validated
- The signatures were verified against the specified public key
- Any certificates were verified against the Fulcio roots.
...

如果使用 cosign 来进行签署，过程基本上来说还算是愉快的，私钥放置在 CI 之中，而公钥则可以保存在集群里，入门方式可以使用客户端定期扫描；复杂的方式则可以实现一个简单的 admission controller 来根据 Selector 对负载进行校验，同样需要注意的是，cosign 只针对远程（镜像库）进行操作，对本地的同 Tag 替换是没什么防御力的，因此这里还要使用 Always Pull 的策略进行弥补（可以使用 Kyverno 或者 Gatekeeper 来强制实施）

Notary

https://mp.weixin.qq.com/s?__biz=MzIxMDY5ODM1OA==&mid=2247485203&idx=1&sn=81cb242d05d6ee38f4a95eb487e20291&chksm=9761ee0aa016671c41df29d0d17e49d0db659d71eb889b4089035456358d77862f5ef715bd3b&scene=21#wechat_redirect

将代码、可执行文件或者脚本进行签名，保障仅有受信内容才可运行，这是一个已知的最佳实践。软件签名不是什么新概念，有很多相关的供应商和方案，每个组织都有自己的方式来处理制品的签署和信任。然而如果把目光投向容器领域，可能会发现并没有那么多选择

Notary是一个基于 TUF 项目的用于软件制品签名的开源软件。

Notary 使用角色和元数据文件对受信集合内容进行签署，这些内容被称为全局唯一名称（GUN——Global Unique Name）

以 Docker 镜像为例，GUN 相当于 [registry]/[repository name]:[tag]。

[registry] 是镜像的源仓库，[repository name] 是镜像的名称。[tag] 对镜像进行标记（通常代表版本）。

Notary 借助 TUF 的角色和密钥层级关系对镜像进行签名。有五种密钥类型用于对元数据文件进行签署，并用 .json 的方式保存到 Notary 数据库

autoscaler

Cluster AutoScaler 是一个自动扩展和收缩 Kubernetes 集群 Node 的扩展。当集群容量不足时，它会自动去 Cloud Provider （支持 GCE、GKE、Azure、AKS、AWS 等）创建新的 Node，而在 Node 长时间（超过 10 分钟）资源利用率很低时（低于 50%）自动将其删除以节省开支。

Cluster AutoScaler 定期（默认间隔 10s）检测是否有充足的资源来调度新创建的 Pod，当资源不足时会调用 Cloud Provider 创建新的 Node。

为了自动创建和初始化 Node，Cluster Autoscaler 要求 Node 必须属于某个 Node Group，比如

• GCE/GKE 中的 Managed instance groups（MIG）
• AWS 中的 Autoscaling Groups
• Azure 中的 Scale Sets 和 Availability Sets

当集群中有多个 Node Group 时，可以通过 --expander=<option> 选项配置选择 Node Group 的策咯，支持如下四种方式

• random：随机选择
• most-pods：选择容量最大（可以创建最多 Pod）的 Node Group
• least-waste：以最小浪费原则选择，即选择有最少可用资源的 Node Group
• price：选择最便宜的 Node Group（仅支持 GCE 和 GKE）

目前，Cluster Autoscaler 可以保证

• 小集群（小于 100 个 Node）可以在不超过 30 秒内完成扩展（平均 5 秒）
• 大集群（100-1000 个 Node）可以在不超过 60 秒内完成扩展（平均 15 秒）

Cluster AutoScaler 也会定期（默认间隔 10s）自动监测 Node 的资源使用情况，当一个 Node 长时间（超过 10 分钟其期间没有执行任何扩展操作）资源利用率都很低时（低于 50%）自动将其所在虚拟机从云服务商中删除（注意删除时会有 1 分钟的 graceful termination 时间）。此时，原来的 Pod 会自动调度到其他 Node 上面（通过 Deployment、StatefulSet 等控制器）。

配合hpa使用：https://blog.tienyulin.com/kubernetes-5_horizontal-pod-autoscaler-hpa/

https://kubernetes.feisky.xyz/setup/addon-list/cluster-autoscaler

https://github.com/kubernetes/autoscaler