首页 > 其他分享 >kubectl命令来查看操作对应的api

kubectl命令来查看操作对应的api

时间:2024-09-09 16:05:52浏览次数:10  
标签:kubectl name 查看 client apiserver api informer k8s

Controller作为k8s的资源控制组件,必定要实时地监控对比资源的目标状态和当前状态,这其中会与apiserver产生大量的交互。在k8s中,k8s各个组件都会与apiServer交互,因此k8s在项目中封装了一个client-go公用模块,路径位于项目vendor/k8s.io/client-go,非常多的组件向ApiServer的curd操作都在client-go包中封装,client-go是k8s项目的核心包之一。它与controller的工作流程密不可分,在读controller源码理解其工作流程前,必须首先对informer有一定得了解,因此本篇专门对informer机制进行简单地介绍说明,为后面的文章铺垫。

ApiServer的连接方式

1.短连接

获取kubernetes某种资源的方式有多种,常见的如kubectl、调用apiserver restful api的接口,restful api接口详情查看官方手册。同时也可通过kubectl命令来查看操作对应的api,例如:

kubectl get pod POD_NAME -v=9
 

输出信息中会包含此操作对应的api url

但这种全量型的操作方式,在大集群规模下,开销还是比较大的,因此,k8s还提供长连接的watch接口。

2.长连接

watch接口是对list接口的一种改进,在调用watch接口后,首先会一次性返回list的数据,同时会保持会话连接,后续的接口对象的curd,都会产生事件由apiserver将变更数据推送给调用端,调用端接收数据后,再更新初始接收到的list的全量数据以及其他操作。

3.client-go

watch依然比较麻烦,毕竟list获取的数据以及后续watch到的数据,需要调用端在内部处理和更新缓存。索性,官方提供了一个client-go客户端工具包封装,里面提供多种apiserver相关操作,做到开箱即用,k8s各组件也都使用了它。

client-go工作模式

在client-go中,informer是对watch操作的一次再封装, Informer是一个带有本地缓存、索引功能的client端(list/watch),在绝大多数场景下,客户端与apiserver的交互都是读多写少的,因此,做好本地缓存(Store)和索引(Index)可以大幅减少开销提升性能。同时,informer可以注册相应的EventHandler事件触发器的,在执行资源更新后触发其他连锁操作。

工作流程图

流程图组件解释

图中有上下分层,上层逻辑由client-go内部封装,下层的逻辑由controller内部完成,对照上图分层说明:

上层:

  • Reflector:反射器,调用 Kubernetes 的 List/Watch API,实现对 apiserver 指定类型对象的监控(List/Watch),将获取的数据,反序列化成对象实例,存入delta 缓存队列中;

  • DeltaIFIFO Queue:一个增量fifo缓存队列,接收来自 Reflector 传递的反序列化对象;

  • Informer:是这个流程中的关键重要的桥梁,主要有两个工作:1.从DeltaIFIFO Queue中获取对象,更新LocalStore的cache数据 2.触发后续的eventHandler,生成工作队列对象,加入WorkQueue,供后面的controller读取进行实际的控制处理工作。(值得注意的是,每一种资源都对应一个informer,多种资源对应多个informer,但每个informer都会与apiserver建立起一个watch长连接,通常controller都会使用SharedInformerFactory这个单例工厂模式,来使所有的informer的创建全部都经过这个单例工厂,从而保证每种资源对应的informer都是唯一且可复用的,以降低开销。)

  • LocalStore:informer 的 cache缓存,这里缓存的是从 apiserver 中获取得到的对象(其中有一部分可能还在DeltaFIFO 中没来得及放入缓存里来),此时client再查询对象的时候就直接从 cache 中查找,减少了 apiserver 的压力,LocalStore 只会被 Lister 的 List/Get 读操作的方法访问;

下层:

  • ResourceEventHandler:由controller注册,由informer来触发,当resource object符合过滤规则时,触发ResourceEventHandler将其丢入WorkQueue内。

  • WorkQueue:informer更新本地的缓存后,会根据注册的相关EventHandler,生成事件放入WorkQueue内,Controller 接收 WorkQueue 中的事件,然后相应执行controller的业务逻辑,一般来说,就是保证资源对象的目标状态与实际状态达成一致的逻辑。

如果你想自定义controller,关于infomer的实践建议,参考这里:

如何用 client-go 拓展 Kubernetes 的 API

APIVersion的说明

在每一个资源的申明yaml文件中,有一个必须存在的一个键apiVersion,这代表了apiserver对相应资源的rest操作,所绑定的group和version,常见的值例如:"apps/v1",斜杠前一位代表的是api的group,斜杠后的值则代表的是version。每一种资源的rest操作,都必须绑定正确的group和version。

在informer的代码中,因为与apiserver直接交互,因此api的group和version相关的结构体会反复出现,且结构体命名非常容易混淆。因此,这里列出进行说明,对阅读informer的源码有一定额外的帮助。

  • APIGroup : api所属组别的信息,其中包含的groupVersion字段,即我们每个yaml文件中apiVersion所指定的
  • APIResource:所有使用到的resouce资源类型,包含pod/deployment/svc等等

APIGroup结构体:

type APIGroup struct {
	TypeMeta `json:",inline"`
	Name string `json:"name" protobuf:"bytes,1,opt,name=name"`
	Versions []GroupVersionForDiscovery `json:"versions" protobuf:"bytes,2,rep,name=versions"`
	PreferredVersion GroupVersionForDiscovery `json:"preferredVersion,omitempty" protobuf:"bytes,3,opt,name=preferredVersion"`
	ServerAddressByClientCIDRs []ServerAddressByClientCIDR `json:"serverAddressByClientCIDRs,omitempty" protobuf:"bytes,4,rep,name=serverAddressByClientCIDRs"`
}
 

APIGroup实例:

通过如下方式快速访问的apiserver的rest api:

# 节点上运行kubectl proxy代理,免去认证步骤,这不太安全,只建议测试使用,使用完毕后及时关闭 
~# kubectl proxy --port=8001 & 

# 查看所有的APIGroup,groups 数组内的每一个成员都是一个APIGroup实例
~#curl 127.0.0.1:8001/apis/
{
  "kind": "APIGroupList",
  "apiVersion": "v1",
  "groups": [
    {
      "name": "apiregistration.k8s.io",
      "versions": [
        {
          "groupVersion": "apiregistration.k8s.io/v1",
          "version": "v1"
        },
        {
          "groupVersion": "apiregistration.k8s.io/v1beta1",
          "version": "v1beta1"
        }
      ],
      "preferredVersion": {
        "groupVersion": "apiregistration.k8s.io/v1",
        "version": "v1"
      }
    },
    {
      "name": "extensions",
      "versions": [
        {
          "groupVersion": "extensions/v1beta1",
          "version": "v1beta1"
        }
      ],
      "preferredVersion": {
        "groupVersion": "extensions/v1beta1",
        "version": "v1beta1"
      }
    },
    ...
}
 

APIResource结构体

type APIResourceList struct {
	TypeMeta `json:",inline"`
	GroupVersion string `json:"groupVersion" protobuf:"bytes,1,opt,name=groupVersion"`
	APIResources []APIResource `json:"resources" protobuf:"bytes,2,rep,name=resources"`
}
 

APIResource实例

Resource分为多个groupVersion

~# curl 127.0.0.1:8001/api/v1 #默认资源
~# curl 127.0.0.1:8001/apis/apps/v1/  # 扩展资源
 

具体参考官方api说明:

https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.14/

下面是一个APIResourceList实例:

~# curl 127.0.0.1:8001/api/v1
{
  "kind": "APIResourceList",
  "groupVersion": "v1",
  "resources": [
    {
      "name": "pods",
      "singularName": "",
      "namespaced": true,
      "kind": "Pod",
      "verbs": [
        "create",
        "delete",
        "deletecollection",
        "get",
        "list",
        "patch",
        "update",
        "watch"
      ],
      "shortNames": [
        "po"
      ],
      "categories": [
        "all"
      ]
    },
    {
      "name": "configmaps",
      "singularName": "",
      "namespaced": true,
      "kind": "ConfigMap",
      "verbs": [
        "create",
        "delete",
        "deletecollection",
        "get",
        "list",
        "patch",
        "update",
        "watch"
      ],
      "shortNames": [
        "cm"
      ]
    },
    {
      "name": "endpoints",
      "singularName": "",
      "namespaced": true,
      "kind": "Endpoints",
      "verbs": [
        "create",
        "delete",
        "deletecollection",
        "get",
        "list",
        "patch",
        "update",
        "watch"
      ],
      "shortNames": [
        "ep"
      ]
    },
    ...
  ]
}
 

总结

本篇先简单介绍一下informer和apiGroup的相关信息,以及和controller组件结合的工作流程,为后面的几篇(deploymentCrontroller、replicaSet controller 、statefulSetController等)分析作铺垫,后面的文章中会反复提到本篇上方的informer与controller结合工作的流程描述和图解。

标签:kubectl,name,查看,client,apiserver,api,informer,k8s
From: https://www.cnblogs.com/cheyunhua/p/18404735

相关文章

  • kubectl top输出与Linux free命令不一致原因
    kubectltop命令和Linux的free命令都用于查看系统资源的使用情况,但它们的输出可能不一致,原因主要包括以下几点:1.数据来源不同kubectltop:该命令从Kubernetes的MetricsServer收集节点和Pod的资源使用情况。MetricsServer会定期收集容器的CPU和内存使用数据,并......
  • 商城上货过程如何选择API接口提高工作效率至关重要!!
    商城上货过程中选择合适的API接口对于提高工作效率至关重要。以下是一些关键步骤和考虑因素,以帮助商城做出明智的选择:一、明确需求业务需求识别:确定商城需要哪些具体的功能和数据,如商品信息、库存管理、订单处理、支付接口、物流跟踪等。分析商城的业务流程,明确API接口在......
  • 分享一波好用的API开发工具
    API开发工具是设计、构建、测试和管理应用程序编程接口(API)的重要辅助工具。以下是一些具体的API开发工具推荐:1.Postman功能描述:Postman是一款支持HTTP协议的接口调试与测试工具,功能强大且使用简单。它可以模拟各种HTTP请求(如GET、POST、PUT、DELETE等),并支持多种格式的参数和......
  • oem 如何查看告警去向
    一:页面查看找到OEM监控对象的home目录监视>预警历史记录点击:历史记录点击报错消息 看通知二:命令查看selectTARGET_NAME,MESSAGE,ALERT_STATE,COLLECTION_TIMESTAMP,DELIVERY_MESSAGEfromMGMT$ALERT_NOTIF_LOGwhereCOLLECTION_TIMESTAMP>sysdate-1......
  • Redis分布式锁查看机制与实现解析
    分布式系统中,锁的使用是保证资源一致性与并发控制的重要手段。Redis作为一个高效的内存存储工具,通过其简单的命令操作和快速响应机制,被广泛用于实现分布式锁。本文将深入探讨Redis中查看分布式锁的机制,包括如何查询锁的状态、使用何种命令进行锁操作,以及如何确保锁的有效性和正确性......
  • pmap: 命令查看 Linux 中进程的内存使用情况
    在Linux系统中,了解进程的内存使用情况对于调试和优化程序非常重要。pmap命令是一个强大的工具,可以帮助你查看进程的内存映射和使用情况。本文将介绍如何使用pmap命令来获取这些信息,并解释输出结果的含义。什么是pmap命令?pmap是一个Linux命令行工具,用于报告进程的内存......
  • Javaweb-JDBC-API详解
    packageDUIXIANG;publicclassAccount{privateintid;privateStringname;privateDoublemoney;publicintgetId(){returnthis.id;}publicvoidsetId(intid){this.id=id;}publicStringgetName(){returnthis.name;}publicvoidsetName(String......
  • RESTful api 与远程接口调用
       RPC( Remote Process Call) 远程接口调用的准确应用是程序与程序之间的通信 。程序 是在计算机中运行中的可用进程。进程之间的通信可以通过管道或者是消息。随着时代的发 展,应用程序的架构模式不断地简化。浏览器作为操作系统客户端和其他数据服务端连接的 可视......
  • 实例:使用 gdb 查看进程内存中的数据结构
    代码示例首先,创建一个简单的链表程序linked_list.c,以演示如何使用gdb查看内存中的数据结构。#include<stdio.h>#include<stdlib.h>//定义链表节点结构体typedefstructNode{intdata;structNode*next;}Node;//添加新节点到链表的尾部voidappen......
  • 如何使用API接口获取 TaoBao 商品数据详情
    在电子商务的快速发展中,淘宝作为中国最大的电商平台之一,提供了丰富的API接口,使得开发者能够高效地获取淘宝商品的详细信息。这些信息包括商品的基本属性、价格、库存状态、销售策略、卖家信息等,对于电商分析、市场研究或者商品信息管理等场景非常有用。什么是淘宝API接口?淘......