【K8s源码品读】004:Phase 1 - kubectl - 发送创建Pod请求的实现细节

本文涉及的产品
容器服务 Serverless 版 ACK Serverless,952元额度 多规格
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
简介: 理解kubectl是怎么向kube-apiserver发送请求的

聚焦目标

理解kubectl是怎么向kube-apiserver发送请求的

目录

  1. 向kube-apiserver发送请求
  2. RESTful客户端是怎么创建的
  3. Object是怎么生成的
  4. 发送post请求
  5. kubectl第一阶段源码阅读总结

send request

// 在RunCreate函数中,关键的发送函数
obj, err := resource.
                NewHelper(info.Client, info.Mapping).
                DryRun(o.DryRunStrategy == cmdutil.DryRunServer).
                WithFieldManager(o.fieldManager).
                Create(info.Namespace, true, info.Object)

// 进入create函数,查看到
m.createResource(m.RESTClient, m.Resource, namespace, obj, options)

// 对应的实现为
func (m *Helper) createResource(c RESTClient, resource, namespace string, obj runtime.Object, options *metav1.CreateOptions) (runtime.Object, error) {
   
    return c.Post().
        NamespaceIfScoped(namespace, m.NamespaceScoped).
        Resource(resource).
        VersionedParams(options, metav1.ParameterCodec).
        Body(obj).
        Do(context.TODO()).
        Get()
}

/*

到这里,我们发现了2个关键性的定义:
1. RESTClient 与kube-apiserver交互的RESTful风格的客户端
2. runtime.Object 资源对象的抽象,包括Pod/Deployment/Service等各类资源

*/

RESTful Client

我们先来看看,与kube-apiserver交互的Client是怎么创建的

// 从传入参数来看,数据来源于Info这个结构
r.Visit(func(info *resource.Info, err error) error{
   })

// 而info来源于前面的Builder,前面部分都是将Builder参数化,核心的生成为Do函数
r := f.NewBuilder().
        Unstructured().
        Schema(schema).
        ContinueOnError().
        NamespaceParam(cmdNamespace).DefaultNamespace().
        FilenameParam(enforceNamespace, &o.FilenameOptions).
        LabelSelectorParam(o.Selector).
        Flatten().
        Do()

// 大致看一下这些函数,我们可以在Unstructured()中看到getClient函数,其实这就是我们要找的函数
func (b *Builder) getClient(gv schema.GroupVersion) (RESTClient, error) 

// 从返回值来看,client包括默认的REST client和配置选项
NewClientWithOptions(client, b.requestTransforms...)

// 这个Client会在kubernetes项目中大量出现,它是与kube-apiserver交互的核心组件,以后再深入。

Object

Object这个对象是怎么获取到的呢?因为我们的数据源是来自文件的,那么我们最直观的想法就是FileVisitor

func (v *FileVisitor) Visit(fn VisitorFunc) error {
   
    // 省略读取这块的代码,底层调用的是StreamVisitor的逻辑
    return v.StreamVisitor.Visit(fn)
}

func (v *StreamVisitor) Visit(fn VisitorFunc) error {
   
    d := yaml.NewYAMLOrJSONDecoder(v.Reader, 4096)
    for {
   
        // 这里就是返回info的地方
        info, err := v.infoForData(ext.Raw, v.Source)
  }
}

// 再往下一层看,来到mapper层,也就是kubernetes的资源对象映射关系
func (m *mapper) infoForData(data []byte, source string) (*Info, error){
   
  // 这里就是我们返回Object的地方,其中GVK是Group/Version/Kind的缩写,后续我们会涉及
  obj, gvk, err := m.decoder.Decode(data, nil, nil)
}

这时,我们想回头去看,这个mapper是在什么时候被定义的?

// 在Builder初始化中,我们就找到了
func (b *Builder) Unstructured() *Builder {
   
    b.mapper = &mapper{
   
        localFn:      b.isLocal,
        restMapperFn: b.restMapperFn,
        clientFn:     b.getClient,
    // 我们查找资源用到的是这个decoder
        decoder:      &metadataValidatingDecoder{
   unstructured.UnstructuredJSONScheme},
    }
    return b
}

// 逐层往下找,对应的Decode方法的实现,就是对应的数据解析成data:
func (s unstructuredJSONScheme) decode(data []byte) (runtime.Object, error) {
   
    // 细节暂时忽略
}

Post

了解了REST ClientObject的大致产生逻辑后,我们再回过头来看发送的方法

// RESTful接口风格中,POST请求对应的就是CREATE方法
c.Post().
        NamespaceIfScoped(namespace, m.NamespaceScoped).
        Resource(resource).
        VersionedParams(options, metav1.ParameterCodec).
        Body(obj).
        Do(context.TODO()). 
        Get() 

// Do方法,发送请求
err := r.request(ctx, func(req *http.Request, resp *http.Response) {
   
        result = r.transformResponse(resp, req)
    })

// Get方法,获取请求的返回结果,用来打印状态
switch t := out.(type) {
   
    case *metav1.Status:
        if t.Status != metav1.StatusSuccess {
   
            return nil, errors.FromObject(t)
        }
    }

Summary

到这里我们对kubectl的功能有了初步的了解,希望大家对以下的关键内容有所掌握:

  1. 命令行采用了cobra库,主要支持7个大类的命令;
  2. 掌握Visitor设计模式,这个是kubectl实现各类资源对象的解析和校验的核心;
  3. 初步了解RESTClientObject这两个对象,它们是贯穿kubernetes的核心概念;
  4. 调用逻辑
    1. cobra匹配子命令
    2. 用Visitor模式构建Builder
    3. 用RESTClient将Object发送到kube-apiserver
相关实践学习
容器服务Serverless版ACK Serverless 快速入门:在线魔方应用部署和监控
通过本实验,您将了解到容器服务Serverless版ACK Serverless 的基本产品能力,即可以实现快速部署一个在线魔方应用,并借助阿里云容器服务成熟的产品生态,实现在线应用的企业级监控,提升应用稳定性。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
目录
相关文章
|
21小时前
|
Kubernetes Java 应用服务中间件
Kubernetes 上搭建一个 Nginx 的 Pod,并确保传入的 API 请求被均匀地分发到两个 Java 业务 Pod 上
Kubernetes 上搭建一个 Nginx 的 Pod,并确保传入的 API 请求被均匀地分发到两个 Java 业务 Pod 上
5 0
|
4天前
|
Kubernetes Shell API
技术笔记:K8s中大量Pod是Evicted状态,这是咋回事?
技术笔记:K8s中大量Pod是Evicted状态,这是咋回事?
|
13天前
|
Kubernetes API 调度
Pod无法调度到可用的节点上(K8s)
完成k8s单节点部署后,创建了一个pod进行测试,后续该pod出现以下报错: Warning FailedScheduling 3h7m (x3 over 3h18m) default-scheduler 0/1 nodes are available: 1 node(s) had untolerated taint {node-role.kubernetes.io/control-plane: }. preemption: 0/1 nodes are available: 1 Preemption is not helpful for scheduling..
50 0
|
2月前
|
Kubernetes 算法 调度
k8s群集调度之 pod亲和 node亲和 标签指定
k8s群集调度之 pod亲和 node亲和 标签指定
|
2月前
|
运维 Kubernetes 监控
Kubernetes详解(十九)——Kubernetes Pod控制器
Kubernetes详解(十九)——Kubernetes Pod控制器
48 3
|
3天前
|
前端开发 Devops 测试技术
阿里云云效产品使用问题之更换所部署的环境关联的ACK集群该如何实现
云效作为一款全面覆盖研发全生命周期管理的云端效能平台,致力于帮助企业实现高效协同、敏捷研发和持续交付。本合集收集整理了用户在使用云效过程中遇到的常见问题,问题涉及项目创建与管理、需求规划与迭代、代码托管与版本控制、自动化测试、持续集成与发布等方面。
|
3天前
|
Kubernetes Ubuntu jenkins
超详细实操教程!在现有K8S集群上安装JenkinsX,极速提升CI/CD体验!
超详细实操教程!在现有K8S集群上安装JenkinsX,极速提升CI/CD体验!
|
3天前
|
Kubernetes 网络协议 Docker
k8s 开船记-故障公告:自建 k8s 集群在阿里云上大翻船
k8s 开船记-故障公告:自建 k8s 集群在阿里云上大翻船
|
4天前
|
Kubernetes 应用服务中间件 nginx
K8s高可用集群二进制部署-V1.20
2.4 部署Etcd集群 以下在节点1上操作,为简化操作,待会将节点1生成的所有文件拷贝到节点2和节点3. 1. 创建工作目录并解压二进制包 mkdir /opt/etcd/{bin,cfg,ssl} -p tar zxvf etcd-v3.4.9-linux-amd64.tar.gz mv etcd-v3.4.9-linux-amd64/{etcd,etcdctl} /opt/etcd/bin/
|
9天前
|
Kubernetes 算法 API
K8S 集群认证管理
【6月更文挑战第22天】Kubernetes API Server通过REST API管理集群资源,关键在于客户端身份认证和授权。