kubernetes

只要读k8s源代码一定会读informer的代码的，因为informer相当优秀，大多数分布式项目(比如OpenStack)在解决组件间通信的问题时都会选择如kafka,rabbitmaq之类的消息队列，但是k8s不走寻常路，选择了自己解决，解决的方案是informer。

client-go提供了许多有用的工具，其中就包括选举，通过选举的功能，我们可以同时运行多个业务实例，多个实例之间互为备份，并且同一时刻只有一个实例运行。

虽然k8s的发现客户端可以实时的获取k8s集群的所有资源，但是并不是直接面向用户的接口，因为解析这些资源组版本是一个乏味和无趣的过程，所以在此基础上client-go提供了RESTMapper来帮助用户映射和发现要找的资源。

之前介绍了client-go的静态客户端，动态客户端，本文主要讲解一下发现客户端的源代码，发现客户端用于发现k8s集群现有的资源，包括但不限于内置资源，可以获取当时k8s集群中的所有资源，通过发现客户端我们可以确定当前器群存在哪些资源及其对应的版本。

本文主要讲解k8s源码中基于Scheme的编解码机制, Scheme就像一个类型大管家，内部注册了各种GVK, 所以使用静态客户端的时候，我们才能无感的直接得到静态类型的指定对象，而不是像动态客户端得到一个Unstructured。

之前无论是讲解静态客户端还是动态客户端都可以略过了client-go底层的RESTClient的构造过程，这篇文章主要分析RESTClient的构造和请求过程，k8s的API都遵循RESTFul规范，所以客户端自然可以以对应的约定形式构造，所以叫做RESTClient。

与client-go静态客户端相对应的自然就是动态客户端了，动态客户端的价值在于灵活，不用重新生成客户端代码就能访问k8s集群中的所有资源，即使是非内置资源。

client-go的客户端可以分为两类，一类称为静态客户端，另一类称为动态客户端，前者的好处在接口已经固定，在写代码的时候有很好的提示，坏处是无法访问非k8s内置资源，后者的好处是够灵活，但是需要使用者知道GVK/GVR等前置知识。两者各有好处，需要根据自己需要选择。

从上一篇文章，我们知道使用client-go操作k8s的资源基本分为三步，1. 配置加载，2. 创建客户端，3. 使用接口，这一篇文章主要专注于使用client-go时的配置加载, 而配置加载，主要是加载认证和连接信息。

client-go是kubernetes官方维护的一个go语言客户端，用于与k8s集群交互，使用client-go可以很方便的完成k8s的二次开发(似乎也必不可少)，无论是稳定性还是健壮性都有充分的保障。