详解K8S apiVersion对照表

k8s更新迭代比较快，apiVersion也在不断变化中，每个版本的对应的apiVersion略有不同，推荐大家去看官方文档：https://kubernetes.io/docs/reference/。

对照表如下：

Kind apiVersion
CertificateSigningRequest certificates.k8s.io/v1beta1
ClusterRoleBinding rbac.authorization.k8s.io/v1
ClusterRole rbac.authorization.k8s.io/v1
ComponentStatus v1
ConfigMap v1
ControllerRevision apps/v1
CronJob batch/v1beta1
DaemonSet extensions/v1beta1
Deployment extensions/v1beta1
Endpoints v1
Event v1
HorizontalPodAutoscaler autoscaling/v1
Ingress extensions/v1beta1
Job batch/v1
LimitRange v1
Namespace v1
NetworkPolicy extensions/v1beta1
Node v1
PersistentVolumeClaim v1
PersistentVolume v1
PodDisruptionBudget policy/v1beta1
Pod v1
PodSecurityPolicy extensions/v1beta1
PodTemplate v1
ReplicaSet extensions/v1beta1
ReplicationController v1
ResourceQuota v1
RoleBinding rbac.authorization.k8s.io/v1
Role rbac.authorization.k8s.io/v1
Secret v1
ServiceAccount v1
Service v1
StatefulSet apps/v1

alpha

名称中带有alpha的API版本是进入Kubernetes的新功能的早期候选版本。这些可能包含错误，并且不保证将来可以使用。

beta

API版本名称中的beta表示测试已经超过了alpha级别，并且该功能最终将包含在Kubernetes中。 虽然它的工作方式可能会改变，并且对象的定义方式可能会完全改变，但该特征本身很可能以某种形式将其变为Kubernetes。

stable

稳定的apiVersion这些名称中不包含alpha或beta。 它们可以安全使用。

v1

这是Kubernetes API的第一个稳定版本。 它包含许多核心对象。

apps/v1

apps是Kubernetes中最常见的API组，其中包含许多核心对象和v1。 它包括与在Kubernetes上运行应用程序相关的功能，如Deployments，RollingUpdates和ReplicaSets。

autoscaling/v1

此API版本允许根据不同的资源使用指标自动调整容器。此稳定版本仅支持CPU扩展，但未来的alpha和beta版本将允许您根据内存使用情况和自定义指标进行扩展。

batch/v1

batchAPI组包含与批处理和类似作业的任务相关的对象（而不是像应用程序一样的任务，如无限期地运行Web服务器）。 这个apiVersion是这些API对象的第一个稳定版本。

batch/v1beta1

Kubernetes中批处理对象的新功能测试版，特别是包括允许您在特定时间或周期运行作业的CronJobs。

certificates.k8s.io/v1beta1

此API版本添加了验证网络证书的功能，以便在群集中进行安全通信。 您可以在官方文档上阅读更多内容。

extensions/v1beta1

此版本的API包含许多新的常用Kubernetes功能。 部署，DaemonSets，ReplicaSet和Ingresses都在此版本中收到了重大更改。

policy/v1beta1

此apiVersion增加了设置pod中断预算和pod安全性新规则的功能

rbac.authorization.k8s.io/v1

此apiVersion包含Kubernetes基于角色的访问控制的额外功能。这有助于您保护群集

参考文章如下：

1、https://matthewpalmer.net/kubernetes-app-developer/articles/kubernetes-apiversion-definition-guide.html

2、参考文章2：https://blog.csdn.net/oscarun/article/details/100063296

到此这篇关于详解K8S apiVersion对照表的文章就介绍到这了,更多相关K8S apiVersion内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们！

赞 (0)

相关推荐

  • K8S 中 kubectl 命令详解

    K8S 中 kubectl 命令详解

    目录 一.资源管理办法 1.1 陈述式资源管理方法 查看版本信息 查看资源对象简写 查看集群信息 配置kubectl自动补全 node 节点查看日志 1.2基本信息查看 查看master 节点状态 查看命令空间 查看default命名空间的所有资源 create 创建命名空间 (app) delete 删除命名空间(app) 在命名空间创建副本控制器启动Pod 查看命名空间kube-public中的pod信息 kubectl exec 登录容器 重启(删除)pod资源 扩容缩容 删除副本控制器

  • K8s实战教程之容器和 Pods资源分配问题

    K8s实战教程之容器和 Pods资源分配问题

    目录 目标 一.启动服务 二.创建命名空间 2.1.查看名字空间 2.2.创建名字空间 2.3.删除名字空间 三.指定 CPU 请求和 CPU 限制 3.1.CPU 单位 3.2.设置超过节点能力的 CPU 请求 3.2.1.创建 Pod 3.2.2.Pod 的状态 3.2.3.Pod 详情 3.2.4.删除 Pod 四.不限制CPU 总结 目标 本篇文章我们将学习,如何为容器设置 CPU request(请求) 和 CPU limit(限制). 容器使用的 CPU 不能超过所配置的限制. 如果

  • K8s-helm简介及基本概念详解

    K8s-helm简介及基本概念详解

    目录 Helm简介 一.什么是 Helm(官网:https://helm.sh/) 二.Helm中的基本概念Chart 三.从Helm2到Helm3的变化 四.Helm版本支持策略 Helm简介 一.什么是 Helm(官网:https://helm.sh/) ​在没使用 helm 之前,向 kubernetes 部署应用,我们要依次部署 deployment.svc 等,步骤较繁琐.况且随着很多项目微服务化,复杂的应用在容器中部署以及管理显得较为复杂,helm 通过打包的方式,支持发布的版本管理

  • k8s部署redis哨兵的实现

    k8s部署redis哨兵的实现

    目录 一.准备redis镜像 二.准备k8s yml—redis-sentinel.yml 三.查看redis哨兵信息 四.连接redis哨兵 一.准备redis镜像 Dockerfile FROM redis:6.0 MAINTAINER 运维@小兵 COPY *.conf /opt/conf/ COPY run.sh /opt/run.sh RUN apt update -y;apt-get install vim net-tools -y;apt-get clean && \ chm

  • 详解K8S apiVersion对照表

    k8s更新迭代比较快,apiVersion也在不断变化中,每个版本的对应的apiVersion略有不同,推荐大家去看官方文档:https://kubernetes.io/docs/reference/. 对照表如下: Kind apiVersion CertificateSigningRequest certificates.k8s.io/v1beta1 ClusterRoleBinding rbac.authorization.k8s.io/v1 ClusterRole rbac.author

  • PHP详解ASCII码对照表与字符转换

    PHP详解ASCII码对照表与字符转换

    一,通用的ASCII码对照表 图解ASCII码对照表图,以字符A为例Dec表示十进制,如65Hx表示十六进制,如41Oct表示八进制,如101Char表示显示字符,如A ASCII码对照表图分为两个单元1,控制字符 0-31和1272,可显示字符 32-126(1)48-57为0到9十个阿拉伯数字:(2)65-90为26个大写英文字母:(3)97-122号为26个小写英文字母:(4)其它标点符号.运算符号等: 二,ASCII扩展码对照表 三,PHP字符转换函数说明 具体字符转换函数说明请参考[P

  • 关于k8s中subpath的使用详解

    目录 有两种情况: 1.做为volumes使用时,subPath代表存储卷的子路径: 2.作为configmap/secret使用时,subPath代表configmap/secret的子路径: 有两种情况: 1.做为volumes使用时,subPath代表存储卷的子路径: apiVersion: v1 kind: Pod metadata: name: testpod0 spec: containers: - name: testc image: busybox command: ["/bin

  • K8S之StatefulSet有状态服务详解

    K8S之StatefulSet有状态服务详解

    目录 一.概念 二.实例 一.概念 1.1.无状态和有状态的区别 主要从网络和存储来对比 无状态不考虑存储和网络,可以任意漂移,每个副本是一样的,如Nginx 有状态应用需要考虑存储和网络,每个副本是不对等的,具有唯一的ID,如etcd.mysql 1.2.StatefulSet的特点 专为部署有状态服务而生 解决Pod独立生命周期,保持Pod启动顺序和唯一性 应用场景:分布式应用.数据库集群 稳定,唯一的网络标识符,持久存储有序,优雅的部署和扩展.删除.终止有序,滚动更新 1.3.Headle

  • k8s之ingress-nginx详解和部署方案

    k8s之ingress-nginx详解和部署方案

    目录 1.ingress介绍 2.ingress的工作原理 3.ingress可以解决的问题 1)动态配置服务 2)减少不必要的端口暴露 4.部署ingress(deployment的方式) 1)配置文件准备(粘贴下面网址的yanl文件) 2)配置文件介绍和设置ingress的网络模式 3)修改配置文件 4)拉取镜像(通过查看ingress的yaml文件可以看出)和创建svc文件 5)指定运行节点(需要打标签) 5.部署ingress(DaemonSet的方式) 1)添加hostNetwork

  • k8s中job与cronjob使用实例详解

    目录 一.前言 二.k8s中job特点 三.Job模板配置文件核心配置参数 3.1 ttlSecondsAfterFinished 3.2 activeDeadlineSeconds 3.3 backoffLimit 3.4 parallelism 3.5 completions 四.job案例操作演示 五.cronjob 理论 六.cronjob 模板配置文件核心配置参数 七.cronjob 案例操作演示 cronjob的运行状态 job的运行状态 pod的运行状态 cronjob使用场景 一

  • k8s应用监控探针详解

    目录 应用监控 pod状态转换 pod的启动流程? Pod支持的监测类型(健康探针) 监测机制 配置参数 示例 image pull policy 镜像管理策略 应用监控 参考 https://www.jb51.net/article/241418.htm 在pod之上 添加一个探针, kubelet通过探针去检查应用 pod状态转换 pod的启动流程? schduler环节 先绑定节点 kubelet接管 准备CNI CSI CRI 启动pod中的container 启动探针 存活探针 监测p

  • k8s编排之Deployment知识点详解

    目录 Pod 复杂的API对象 nginx-deployment Deployment 及类似控制器总结 Deployment 所控制的 ReplicaSet查看 Pod 复杂的API对象 Pod 这个看似复杂的 API 对象,实际上就是对容器的进一步抽象和封装而已. 说得更形象些,“容器”镜像虽然好用,但是容器这样一个“沙盒”的概念,对于描述应用来说,还是太过简单了.这就好比,集装箱固然好用,但是如果它四面都光秃秃的,吊车还怎么把这个集装箱吊起来并摆放好呢? 所以,Pod 对象,其实就是容器的

  • k8s编排之StatefulSet知识点详解二

    目录 StatefulSet 对存储状态的管理机制 第一步:定义一个 PVC,声明想要的 Volume 的属性 第二步:在应用的 Pod 中,声明使用这个 PVC 常见的 PV 对象的 YAML 文件 StatefulSet 对存储状态的管理机制 这个机制,主要使用的是一个叫作 Persistent Volume Claim 的功能. 要在一个 Pod 里声明 Volume,只要在 Pod 里加上 spec.volumes 字段即可.然后,你就可以在这个字段里定义一个具体类型的 Volume 了

  • k8s编排之StatefulSet知识点详解一

    目录 正文 StatefulSet 的设计理解 Service 如何被访问 Headless Service 对应的 YAML文件 StatefulSet 的 YAML 文件 解析一下 Pod 对应的 Headless Service 正文 Deployment认为,一个应用的所有 Pod,是完全一样的.所以,它们互相之间没有顺序,也无所谓运行在哪台宿主机上.需要的时候,Deployment 就可以通过 Pod 模板创建新的 Pod:不需要的时候,Deployment 就可以“杀掉”任意一个 P

随机推荐