k8s的api资源
|
NAME |
SHORTNAMES |
APIGROUP |
KIND |
资源用途说明 |
|
bindings |
Binding |
已弃用。用于记录一个object和另一个object的绑定关系。 实际上主要用于将pod和node关系， 所以在1.7版本后已经改为在pods.bindings中记录了 |
||
|
componentstatuses |
cs |
ComponentStatus |
是一个全局的list（即不受命名空间影响）， 记录了k8s中所有的组件的的相关信息，比如创建时间，现在状态等。 |
|
|
configmaps |
cm |
ConfigMap |
是一种用于记录pod本身或其内部配置信息的API资源， 可以认为是通过API形式存储的配置文件 |
|
|
endpoints |
ep |
Endpoints |
用于记录每个service的pod的真实物理ip和port的对应关系， 包括service是TCP还是UDP等。 |
|
|
events |
ev |
Event |
用于记录集群中的事件，可以认为类似于日志里的一条记录 |
|
|
limitranges |
limits |
LimitRange |
用于记录各个命名空间中的pod或container对每种资源的使用限制， 一般被包含在pod的定义中 |
|
|
namespaces |
ns |
Namespace |
是一个全局的list，保存集群中所有的命名空间 |
|
|
nodes |
no |
Node |
是一个全局的list，详细记录了每个节点的可分配资源， 各心跳状态（网络，内存，硬盘，PID数量，kubelet等）， kubelet的物理port，各k8s组件image信息，node环境信息 （os, CRI version, kubeProxy version, kubelet version等） |
|
|
persistentvolumeclaims |
pvc |
PersistentVolumeClaim |
记录用户对持久化存储的要求 |
|
|
persistentvolumes |
pv |
PersistentVolume |
是一个全局的object，记录了所有的持久化存储设备的信息 |
|
|
pods |
po |
Pod |
对于使用k8s的开发者而言最重要的资源 |
|
|
podtemplates |
PodTemplate |
一般是被包含在其它资源中的一部分，比如Jobs, DaemonSets, Replication Controllers |
||
|
replicationcontrollers |
rc |
ReplicationController |
是系统内建的最常用的controller，用来保证Pod的实际运行数量满足定义 |
|
|
resourcequotas |
quota |
ResourceQuota |
用于记录和限制某个namespace的中的总的资源消耗， 一般用于多用户下利用namespace对资源进行限制 |
|
|
secrets |
Secret |
实际上将文件内容通过base64编码后存在etcd中。 在Pod中container启动时可以将secretes作为文件挂载在某一路径下， 如此避免重要信息存储在image中。 |
||
|
serviceaccounts |
sa |
ServiceAccount |
用于授权集群内的pod访问apiServer |
|
|
services |
svc |
Service |
对外提供统一的Service IP和port，将流量负载均衡调整至集群中多个pod |
|
|
mutatingwebhookconfigurations |
admissionregistration.k8s.io |
MutatingWebhookConfiguration |
||
|
validatingwebhookconfiguratio |
admissionregistration.k8s.io |
ValidatingWebhookConfiguration |
||
|
customresourcedefinitions |
crd,crds |
apiextensions.k8s.io |
CustomResourceDefinition |
自定义资源也是非常重要的一种资源，是各种k8s插件能够存在的基础 |
|
apiservices |
apiregistration.k8s.io |
APIService |
定义API服务的资源。一个API请求有两种形式，
和 当一个请求到达apiServer后，必然需要有相应的代码去处理它。 每一对GROUP和VERSION确定一种API，响应每一种API请求的代码被抽象为一种服务（service）。 想象一下自定义资源的相关API请求到达apiServer后如何被处理呢？ 相关的service也是自定义的并且运行在master中，k8s正是根据APIService来正确地将请求与正确的service关联。 在这里可以定义service名称，安全设置，优先级等。 |
|
|
controllerrevisions |
apps |
ControllerRevision |
是一个beta功能，用于Controller保存自己的历史状态便于更新和回滚 |
|
|
daemonsets |
ds |
apps |
DaemonSet |
常见的Pod set种类，用于控制每种pod状态（在定义的范围内， 且在每node上最多有一个 |
|
deployments |
deploy |
apps |
Deployment |
|
|
replicasets |
rs |
apps |
ReplicaSet |
|
|
statefulsets |
sts |
apps |
StatefulSet |
|
|
tokenreviews |
authentication.k8s.io |
TokenReview |
||
|
localsubjectaccessreviews |
authorization.k8s.io |
LocalSubjectAccessReview |
||
|
selfsubjectaccessreviews |
authorization.k8s.io |
SelfSubjectAccessReview |
||
|
selfsubjectrulesreviews |
authorization.k8s.io |
SelfSubjectRulesReview |
||
|
subjectaccessreviews |
authorization.k8s.io |
SubjectAccessReview |
||
|
horizontalpodautoscalers |
hpa |
autoscaling |
HorizontalPodAutoscaler |
|
|
cronjobs |
cj |
batch |
CronJob |
|
|
jobs |
batch |
Job |
||
|
certificatesigningrequests |
csr |
certificates.k8s.io |
CertificateSigningRequest |
|
|
leases |
coordination.k8s.io |
Lease |
||
|
endpointslices |
discovery.k8s.io |
EndpointSlice |
||
|
events |
ev |
events.k8s.io |
Event |
|
|
ingresses |
ing |
extensions |
Ingress |
|
|
ingressclasses |
networking.k8s.io |
IngressClass |
||
|
ingresses |
ing |
networking.k8s.io |
Ingress |
|
|
networkpolicies |
netpol |
networking.k8s.io |
NetworkPolicy |
|
|
runtimeclasses |
node.k8s.io |
RuntimeClass |
||
|
poddisruptionbudgets |
pdb |
policy |
PodDisruptionBudget |
|
|
podsecuritypolicies |
psp |
policy |
PodSecurityPolicy |
|
|
clusterrolebindings |
rbac.authorization.k8s.io |
ClusterRoleBinding |
||
|
clusterroles |
rbac.authorization.k8s.io |
ClusterRole |
||
|
rolebindings |
rbac.authorization.k8s.io |
RoleBinding |
||
|
roles |
rbac.authorization.k8s.io |
Role |
||
|
priorityclasses |
pc |
scheduling.k8s.io |
PriorityClass |
|
|
csidrivers |
storage.k8s.io |
CSIDriver |
||
|
csinodes |
storage.k8s.io |
CSINode |
||
|
storageclasses |
sc |
storage.k8s.io |
StorageClass |
|
|
volumeattachments |
storage.k8s.io |
VolumeAttachment |
NAME：api资源名称
SHORTNAMES：api资源名称简写
APIGROUP：api分组管理
NAMESPACED：是否可使用命名空间隔离
KIND：api资源类型
- StatefulSet: 常见的Pod set种类。和Deployment的区别之处是它控制的pod不是可互换的而是在整个生命周期有不变的标签。这样，每个pod可以有自己的DNS名，存储等。即使pod被删除后这些信息也会被恢复。
- TokenReview: 不明，似乎和apiServer的Webhook的token授权相关。
- LocalSubjectAccessReview: 不明（内部object），和一个命名空间对用户/组的授权检查相关。
- SelfSubjectAccessReview: 不明（内部object），和当前用户检查自己是否有权限对一个命名空间进行操作相关。
- SelfSubjectRulesReivew: 不明（内部object），含有当前用户在一个命名空间内能进行的操作的列表。和apiServer的授权安全模式相关
- SubjectAccessReviews: 不明（内部object），和用户/组的授权检查相关，并不限定于某个命名空间。
- HorizontalPodAutoScaler: 控制Pod set（比如Deployment）的pod数量的资源。可以根据pod的CPU、内存、自定义数据动态调节pod数量。在这里可以找到相关的例子。
- CronJob: 定时运行Job pod的资源。
- Job: 常见的Pod set种类，会创建一定数量的pod，仅当特定数量的pod成功结束后这个Job才算成功结束。创建的pod在结束后不会被重启。
- CertificateSigningRequests: 可以认为是一个接口，便于Pod等资源申请获得一个X.509证书。这个证书应该被controller approve或者被手动approve，之后被合适的对象签名。具体可以参考这里。
- Lease: 是一个在1.13版本中加入的资源类型，用于Node向master通知自己的心跳信息。之前的版本中kebulet是通过更新NodeStatus通知master心跳，后来发现NodeStatus太大了而心跳信息更新频繁，导致master压力较大，于是增加了Lease这种资源。
- EndpointSlice: 是含有一个service的Endpoint的部分信息的资源。原因和Lease类似，对于含有较多信息的service（比如有很多pod分布在多个node上）一个endpoint object可能会比较大而且被频繁访问，所以这种情况下会有多个endpointSlice被创建减轻master的压力。
- Event: 描述一个集群内的事件的资源，含有message，event，reason，报告来源等详细的信息。
- Ingresses (APIGroup=extensions): 将被deprecated。
- Ingresses (APIGroup=http://networking.k8s.io): 可以简单理解为是定义loadbalancer的资源。其中含有一系列规则，定义了不同url的对应后端，SSL termination等。为什么这个新的API会取代前面那个APIGroup=extensions的Ingress API呢？我查了很多地方没有找到具体的文字解释，但是可以推测是Ingress正式成为k8s的网络模块的一部分，对应的server（代码）从extensions迁移到http://networking.k8s.io。
- NetworkPolicy: 定义了那些网络流量可以去哪些pod的资源。一个NetworkPolicy可以指定一组pods，定义只有满足了特定条件（比如源/目的IP，port，pod名等）的网络流量可以被相应的pod收发。
- RuntimeClass: 这是2019年讨论加入的新API资源。文档说明其目的是将容器运行时（Container Runtime）环境的属性暴露给k8s的控制层，便于在一个集群或节点中支持多种容器运行时环境。这样便于未来创建更具有兼容性的k8s集群。
- PodDisruptionBudget: 这一个API资源使用户可以对一组pod定义“k8s可以容忍的实际running状态的pod数量与预期的差距”。考虑这样一个情景：一集群中某个service后一共有5个相同pod处理其流量，要求至少有一半的pod是可用的，但其中3个pod由于调度运行在node A上。如果出现node A突然故障等情况导致服务不可用，暂时没有好的办法处理这种不可避免地意外情况（或者需要让调度算法知道这些pod应该被尽量均匀分布在个节点上，但目前k8s没有功能强制这种调度）。但除此之外还有很多可以避免的意外情况，比如在集群维护或者其它事件的处理过程中，集群管理员可能drain node A，导致三个pod同时被结束从而影响业务。针对这种可避免的意外，若一组pod的数量因为可避免的k8s操作将会低于可容忍程度（在PodDisruptionBudget中定义），那么这个命令会被阻止并返回失败。
- PodSecurityPolicy: 定义了一个pod在集群中被创建/运行/更新时需要满足的条件。
- ClusterRole: 定义了集群中policy rule的一些常见集合，比如
system-node等，用于控制账户权限。 - ClusterRoleBinding: 定义了某个账户/组对ClusterRole的引用，用于赋权。
- Roles: 和前面ClusterRole类似，但是顾名思义ClusterRole是和集群账户相关，Role则被用于其它的账户（比如controller使用的service account）
- RoleBindings: 定义了某个账户/组对Role的引用，用于赋权。
- PriorityClass: 定义了pod优先级名称和对应值的映射。比如
system-cluster-critical对应的优先级为2000000000。值越大代表优先级越高，那么当集群资源不足等情况发生必须终止一些pod时，优先级小的pod会先被终止。为什么不直接用数值代表优先级呢？因为这样子很容易出现确定随意性。比如开发人员A开发了一个非常重要的pod，于是在代码中将其优先级的值设置为9999。但是集群集群管理员B可能认为9999是一个小数字，他创建的随便一个pod的优先级都是999999+。于是需要PriorityClass来进行优先级的统一管理和比较。 - CSIDriver: 定义了集群中容器存储驱动的API资源。CSI代表的是Container Storage Interface，即容器存储接口。k8s应该可以利用各种各样的存储服务，各家云厂商的活开源的。k8s如何知道怎么去用这些存储服务呢？那么就是通过这个CSIDriver资源找到相应的驱动。
- CSINode: 前面CSIDriver产生的节点相关的信息便存在CSINode中。
- StorageClass: 定义了可以存在的存储类型的API资源。
- Volumeattachments: 定义了对一个node分配/回收存储空间的请求的API资源。
- NetworkSets: 接下来的都是Calico自定义API资源，就不一一分析了，都与网络协议/安全/管理相关。
- NetworkPolicies: Calico自定义API资源
- IPPools: Calico自定义API资源
- IPAMHandles: Calico自定义API资源
- IPAMConfigs: Calico自定义API资源
- IPAMBlocks: Calico自定义API资源
- HostEndpoints: Calico自定义API资源
- GlobalNetworkSets: Calico自定义API资源
- GlobalNetworkPolicies: Calico自定义API资源
- FelixConfiguration: Calico自定义API资源
- ClusterInformation: Calico自定义API资源
- BlockAffinity: Calico自定义API资源
- BGPPeer: Calico自定义API资源
- BGPConfiguration: Calico自定义API资源
posted on 2022-05-24 17:30 hopeless-dream 阅读(254) 评论(0) 编辑 收藏 举报
