double12gzh - Posts in Kubernetes

如何使用client-go访问k8s crd

2020-09-26T00:00:00+00:00

摘要：介绍如何使用clinet-go手动编写程序来访问k8s中的crd。

1. 写在前面

微信公众号：[double12gzh]

个人主页: https://gzh.readthedocs.io

关注容器技术、关注Kubernetes。问题或建议，请公众号留言。

Kubernetes架构的设计模式，我们可以很方便的使用CRD(Custom Resource Definitions)对k8s API进行扩展。但是问题，通过client-go来获取这些CRD或开发用户自定义控制器，那是比较麻烦的一件事情，除此之外，市面上对于client-go的介绍并不是很多。

本文将会通过一个示例，简单介绍一下如何通过client-go获取CRD。

2. 写作动机

我在PaaS平台的日常开发工作中，想要将第三方存储厂商集成到Kubernetes集群中时，遇到了这个挑战。计划是使用自定义资源定义来定义诸如文件系统池和文件系统。然后，一个自定义的Operator可以监听这些资源的创建和删除，并负责这些资源的生命周期的管理。

3. 定义CR(Custom Resource)

在本文中，我们将以一个简单的例子来进行演示。使用kubectl可以很容易地创建自定义资源定义，对于这个例子，我们将从一个简单的资源定义开始做起：

test.yaml

 apiVersion: "apiextensions.k8s.io/v1beta1"
 kind: "CustomResourceDefinition"
 metadata:
     name: "projects.examples-gzh.com"
 spec:
     group: "examples-gzh.com"
     version: "v1alpha1"
     scope: "Namespaced"
     names:
     plural: "projects"
     singular: "project"
     kind: "Project"
     validation:
     openAPIV3Schema:
         required: ["spec"]
         properties:
         replicas:
             type: "integer"
             minimum: 1

确定Group的名字。

在定义CRD时，我们首先需要定义它所在的Group(在上面的代码中，其``Group``为：examples-gzh.com)。对于Group的定义，为了避免命名冲突，通常会使用一些比较特别的字符串(如：你的个人主页的地址、你公司的域名等)，Group名

System Message: WARNING/2 (/home/docs/checkouts/readthedocs.org/user_builds/gzh/checkouts/latest/blogs/Kubernetes/2020-09-26-使用client-go访问k8s集群中的CRD.rst, line 70)

Bullet list ends without a blank line; unexpected unindent.

字确定了之后，由于CRD的名字是按<plural-resource-name>.<api-group-name>这个格式进行命名的，所以这里我们的CRD的名字为projects.example-gzh.com。

确定version。

这里的version，即spec.version。如果你的代码没有开发完成，或者还在快速迭代中，那么，建议你使用alpha这样的命名规则。这样的好处是，如果别人想使用你的代码去使用，那么，他单从版本号上就可以很方便的快速知道，你这

System Message: WARNING/2 (/home/docs/checkouts/readthedocs.org/user_builds/gzh/checkouts/latest/blogs/Kubernetes/2020-09-26-使用client-go访问k8s集群中的CRD.rst, line 75)

Bullet list ends without a blank line; unexpected unindent.

是一个不稳定的版本。

schema校验

在上面我们的CRD中，我们引入了spec.validation.openAPIV3Schema，它的作用是对其中的字段进行校验，如果用户在使用我们的CRD时，提供了一个不符合要求的字段后，validation可以很方便的对其进行校验。除了在这里引用validation之外，我们还

System Message: WARNING/2 (/home/docs/checkouts/readthedocs.org/user_builds/gzh/checkouts/latest/blogs/Kubernetes/2020-09-26-使用client-go访问k8s集群中的CRD.rst, line 80)

Bullet list ends without a blank line; unexpected unindent.

可以选择在admintion: controller中通过Validate阶段进行验证，不过样是需要开启admission webhook的。

将上面的代码保存到一个文件中之后，我们就可以通过kubectl apply -f demo.yaml进行部署了。我在本机通过minikue启动了一个K8S集群：

PS C:\Users\guanzenghui> kubectl get po -A
NAMESPACE              NAME                                        READY   STATUS    RESTARTS   AGE
kube-system            coredns-f9fd979d6-7h2b7                     1/1     Running   1          9h
kube-system            etcd-minikube                               0/1     Running   2          9h
kube-system            kube-apiserver-minikube                     1/1     Running   2          9h
kube-system            kube-controller-manager-minikube            0/1     Running   2          9h
kube-system            kube-proxy-p8zb7                            1/1     Running   1          9h
kube-system            kube-scheduler-minikube                     0/1     Running   2          9h
kube-system            storage-provisioner                         1/1     Running   1          9h
kubernetes-dashboard   dashboard-metrics-scraper-c95fcf479-gvhpd   1/1     Running   1          9h
kubernetes-dashboard   kubernetes-dashboard-5c448bc4bf-lpwqh       1/1     Running   1          9h

PS C:\Users\guanzenghui> kubectl version
Client Version: version.Info{Major:"1", Minor:"16+", GitVersion:"v1.16.6-beta.0", GitCommit:"e7f962ba86f4ce7033828210ca3556393c377bcc", GitTreeState:"clean", BuildDate:"2020-01-15T08:26:26Z", GoVersion:"go1.13.5", Compiler:"gc", Platform:"windows/amd64"}
Server Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.2", GitCommit:"f5743093fd1c663cb0cbc89748f730662345d44d", GitTreeState:"clean", BuildDate:"2020-09-16T13:32:58Z", GoVersion:"go1.15", Compiler:"gc", Platform:"linux/amd64"}

部署我们的CRD:

PS C:\Users\guanzenghui\Documents> kubectl apply -f .\Untitled-2.yaml
customresourcedefinition.apiextensions.k8s.io/projects.examples-gzh.com created

PS C:\Users\guanzenghui\Documents> kubectl get crd
NAME                        CREATED AT
projects.examples-gzh.com   2020-09-25T10:40:01Z

如果需要查看其详情，可以使用命令: kubectl describe crd projects.examples-gzh.com

既然CRD已经创建完成了，接下来我们看一下如何使用这个CRD来创建与之相对应的CR。CR相关的文件内容如下：

apiVersion: "examples-gzh.com/v1alpha1"
kind: Project
metadata:
  name: gzh-cr
  namespace: default
spec:
  replica: 2

创建CR

PS C:\Users\guanzenghui\Documents> kubectl apply -f cr.yaml
project.examples-gzh.com/gzh-cr created

PS C:\Users\guanzenghui\Documents> kubectl get Project
NAME     AGE
gzh-cr   39s

接下来，我们将使用client-go来获取这个CR。

4. 创建golang client

在进行本节前，我假设您已经对client-go、k8s控制器机制有所理解，并且有一定的GoLang的开发经验。

另外，与其它一些讲解Operator的文章不同的是，这些使用CRD的文档会假设你正在使用某种代码生成器来自动生成客户端库。然而，对于这个过程的文档很少，而且从阅读Github上的一些激烈的讨论中，我们可以看出，它仍然是一个正在进行中的工作。

本文中，我将坚持使用（大部分）手动实现的客户端的方式给大家展示。

首先，您可以创建一个自己的项目路径，并安装依赖:

mkdir github.com/double12gzh/k8s-crd-demo
go get k8s.io/client-go@v0.17.0
go get k8s.io/apimachinery@v0.17.0

4.1 定义类型

example.go

 package v1alpha1

 import metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"

 type ProjectSpec struct {
   Replicas int `json:"replicas"`
 }

 type Project struct {
   metav1.TypeMeta   `json:",inline"`
   metav1.ObjectMeta `json:"metadata,omitempty"`
   Spec ProjectSpec `json:"spec"`
 }

 type ProjectList struct {
     metav1.TypeMeta `json:",inline"`
     metav1.ListMeta `json:"metadata,omitempty"`
     Items []Project `json:"items"`
 }

metav1.ObjectMeta中包含了一个比较重要的类型metadata，k8s中所有的资源有都这个属性，这里面可以定义诸如：name，namespace，label等的属性。

4.2 定义DeepCopy方法

Kubernetes API 所服务的每个类型（在本例中，Project 和 ProjectList）都需要实现 k8s.io/apimachinery/pkg/runtime.Object 接口。这个接口定义了两个方法GetObjectKind()和DeepCopyObject()。第一个方法已经由内嵌的metav1.TypeMeta结构提供了；第二个方法你必须自己实现。

DeepCopyObject方法的目的是生成一个对象的深度拷贝。由于这涉及到大量的模板代码，所以这些方法通常是自动生成的。在本文中，我们将手动进行。继续在同一个包中添加第二个文件 deepcopy.go。

deepcopy.go

 package v1alpha1

 import "k8s.io/apimachinery/pkg/runtime"

 // DeepCopyInto 把一个对象的所有属性复制给此对象类型的指针
 func (in *Project) DeepCopyInto(out *Project) {
     out.TypeMeta = in.TypeMeta
     out.ObjectMeta = in.ObjectMeta
     out.Spec = ProjectSpec{
         Replicas: in.Spec.Replicas,
     }
 }

 // DeepCopyObject 返回一个对象类型
 func (in *Project) DeepCopyObject() runtime.Object {
     out := Project{}
     in.DeepCopyInto(&out)

     return &out
 }

 // DeepCopyObject 返回一个对像类型
 func (in *ProjectList) DeepCopyObject() runtime.Object {
     out := ProjectList{}
     out.TypeMeta = in.TypeMeta
     out.ListMeta = in.ListMeta

     if in.Items != nil {
         out.Items = make([]Project, len(in.Items))
         for i := range in.Items {
             in.Items[i].DeepCopyInto(&out.Items[i])
         }
     }

     return &out
 }

上面这个DeepCopy是我们手动来生成的，你可能已经注意到，定义所有这些不同的 DeepCopy 方法并不是一件很有趣的事情。有很多不同的工具和框架可以自动生成这些方法（所有的文档和整体成熟度都有很大的不同）。我发现效果最好的是控制器生成工具，它是Kubebuilder框架的一部分。

下面我们就来看一下：

go get -u github.com/kubernetes-sigs/controller-tools/cmd/controller-gen

为了能够使用controller-gen，我们需要在CRD类型上面的添加一个annotation，如下：

test.go

 // +k8s:deepcopy-gen:interfaces=k8s.io/apimachinery/pkg/runtime.Object
 type Project struct {
     // ...
 }

 // +k8s:deepcopy-gen:interfaces=k8s.io/apimachinery/pkg/runtime.Object
 type ProjectList struct {
     // ...
 }

Tip

说明：对于这些annotation我们没有必要去全部记住，只有当使用到的时候再去查阅一下就行，根据二八原则，只需要记住一些常用的就可以了，其它那些不常用的只需要了解一下。

写好了上述代码，我们运行一下命令controller-gen object paths=./api/types/v1alpha1/project.go即可生成需要代码。

为了更加的简化，你甚至可以在代码文件的前面加一个声明go:generate，具体请参考。如：

test.go

 package v1alpha1

 import metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"

 //go:generate controller-gen object paths=$GOFILE

 // ...

然后只需要在代码的根路径中执行go generate ./...即可。

4.3 注册类型

接下来，你需要让客户端库知道你的新类型。这将允许客户端在与API服务器通信时（或多或少）自动处理你的新类型。

为此，在你的包中添加一个新文件 register.go。

 package v1alpha1

 import (
     metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
     "k8s.io/apimachinery/pkg/runtime"
     "k8s.io/apimachinery/pkg/runtime/schema"
 )

 const GroupName = "example-gzh.com"
 const GroupVersion = "v1alpha1"

 var SchemeGroupVersion = schema.GroupVersion{Group: GroupName, Version: GroupVersion}

 var (
     SchemeBuilder = runtime.NewSchemeBuilder(addKnownTypes)
     AddToScheme   = SchemeBuilder.AddToScheme
 )

 func addKnownTypes(scheme *runtime.Scheme) error {
     scheme.AddKnownTypes(SchemeGroupVersion,
         &Project{},
         &ProjectList{},
     )

     metav1.AddToGroupVersion(scheme, SchemeGroupVersion)
     return nil
 }

正如你所注意到的，这段代码还没有真正做任何事情（除了创建一个新的runtime.SchemeBuilder实例）。重要的部分是AddToScheme函数（第16行），它是第15行创建的runtime.SchemeBuilder类型的导出结构成员。只要Kubernetes客户端被初始化以注册你的类型定义，你就可以在以后从客户端代码的任何部分调用这个函数。

4.4 创建HTTP Client

在定义了类型并添加了一个方法来在全局方案构建器上注册它们之后，你现在可以创建一个能够加载你的自定义资源的HTTP客户端。

为此，将以下代码添加到你的包的main.go文件中：

main.go

 package main

 import (
     "flag"
     "log"

     "ks.io/apimachinery/pkg/runtime/schema"
     "ks.io/apimachinery/pkg/runtime/serializer"

     "github.com/double12gzh/k8s-demo/api/types/valpha"
     "ks.io/client-go/kubernetes/scheme"
     "ks.io/client-go/rest"
     "ks.io/client-go/tools/clientcmd"
 )

 var kubeconfig string

 func init() {
     flag.StringVar(&kubeconfig, "kubeconfig", "", "path to Kubernetes config file")
     flag.Parse()
 }

 func main() {
     var config *rest.Config
     var err error

     if kubeconfig == "" {
         log.Printf("using in-cluster configuration")
         config, err = rest.InClusterConfig()
     } else {
         log.Printf("using configuration from '%s'", kubeconfig)
         config, err = clientcmd.BuildConfigFromFlags("", kubeconfig)
     }

     if err != nil {
         panic(err)
     }

     valpha.AddToScheme(scheme.Scheme)

     crdConfig := *config
     crdConfig.ContentConfig.GroupVersion = &schema.GroupVersion{Group: valpha.GroupName, Version: valpha.GroupVersion}
     crdConfig.APIPath = "/apis"
     crdConfig.NegotiatedSerializer = serializer.NewCodecFactory(scheme.Scheme)
     crdConfig.UserAgent = rest.DefaultKubernetesUserAgent()

     exampleRestClient, err := rest.UnversionedRESTClientFor(&crdConfig)
     if err != nil {
         panic(err)
     }
 }

现在你可以使用第48行创建的exampleRestClient来查询example.martin-helmich.de/v1alpha1 API组中的所有自定义资源。例如：

result := v1alpha1.ProjectList{}
err := exampleRestClient.Get().Resource("projects").Do().Into(&result)

为了以一种更安全的方式使用你的API，通常情况下，我们最好在自己的clientet中封装这些操作。为此，创建一个新的子包clientet/v1alpha1。

首先，实现一个定义你的API组类型的接口，并将配置设置从你的主方法移到该clientet的构造函数中（下面例子中的NewForConfig）。

package valpha

import (
    "github.com/double12gzh/k8s-demo/api/types/valpha"
    "ks.io/apimachinery/pkg/runtime/schema"
    "ks.io/client-go/kubernetes/scheme"
    "ks.io/client-go/rest"
)

type ExampleVAlphaInterface interface {
    Projects(namespace string) ProjectInterface
}

type ExampleVAlphaClient struct {
    restClient rest.Interface
}

func NewForConfig(c *rest.Config) (*ExampleVAlphaClient, error) {
    config := *c
    config.ContentConfig.GroupVersion = &schema.GroupVersion{Group: valpha.GroupName, Version: valpha.GroupVersion}
    config.APIPath = "/apis"
    config.NegotiatedSerializer = scheme.Codecs.WithoutConversion()
    config.UserAgent = rest.DefaultKubernetesUserAgent()

    client, err := rest.RESTClientFor(&config)
    if err != nil {
        return nil, err
    }

    return &ExampleVAlphaClient{restClient: client}, nil
}

func (c *ExampleVAlphaClient) Projects(namespace string) ProjectInterface {
    return &projectClient{
        restClient: c.restClient,
        ns:         namespace,
    }
}

下面的代码还不能编译，因为它仍然缺少ProjectInterface和projectClient类型。我们稍后将讨论这些类型。

ExampleV1Alpha1Interface和它的实现--ExampleV1Alpha1Client结构现在是访问自定义资源的中心点。现在，你可以在main.go中简单地调用clientet, err := v1alpha1.NewForConfig(config)来创建一个新的客户集。

接下来，你需要实现一个特定的clientset来访问Project自定义资源（注意，上面的例子已经使用了ProjectInterface和projectClient类型，我们仍然需要提供）。在同一个包中创建第二个文件projects.go。

package valpha

import (
    "github.com/double12gzh/k8s-demo/api/types/valpha"
    metav "ks.io/apimachinery/pkg/apis/meta/v"
    "ks.io/apimachinery/pkg/watch"
    "ks.io/client-go/kubernetes/scheme"
    "ks.io/client-go/rest"
)

type ProjectInterface interface {
    List(opts metav.ListOptions) (*valpha.ProjectList, error)
    Get(name string, options metav.GetOptions) (*valpha.Project, error)
    Create(*valpha.Project) (*valpha.Project, error)
    Watch(opts metav.ListOptions) (watch.Interface, error)
    // ...
}

type projectClient struct {
    restClient rest.Interface
    ns         string
}

func (c *projectClient) List(opts metav.ListOptions) (*valpha.ProjectList, error) {
    result := valpha.ProjectList{}
    err := c.restClient.
        Get().
        Namespace(c.ns).
        Resource("projects").
        VersionedParams(&opts, scheme.ParameterCodec).
        Do().
        Into(&result)

    return &result, err
}

func (c *projectClient) Get(name string, opts metav.GetOptions) (*valpha.Project, error) {
    result := valpha.Project{}
    err := c.restClient.
        Get().
        Namespace(c.ns).
        Resource("projects").
        Name(name).
        VersionedParams(&opts, scheme.ParameterCodec).
        Do().
        Into(&result)

    return &result, err
}

func (c *projectClient) Create(project *valpha.Project) (*valpha.Project, error) {
    result := valpha.Project{}
    err := c.restClient.
        Post().
        Namespace(c.ns).
        Resource("projects").
        Body(project).
        Do().
        Into(&result)

    return &result, err
}

func (c *projectClient) Watch(opts metav.ListOptions) (watch.Interface, error) {
    opts.Watch = true
    return c.restClient.
        Get().
        Namespace(c.ns).
        Resource("projects").
        VersionedParams(&opts, scheme.ParameterCodec).
        Watch()
}

这个client显然还不完善，还缺失了删除、更新等方法。不过，这些方法可以和已有的方法类似实现。看看现有的clientset（例如，Pod clientset）以获得灵感。

在创建了clientset之后，用它来列出你现有的资源就变得非常容易了。

package main

import (
    "fmt"

    clientValpha "github.com/double12gzh/k8s-demo/clientset/valpha"
)

// ...

func main() {
    // ...

    clientSet, err := clientValpha.NewForConfig(config)
    if err != nil {
        panic(err)
    }

    projects, err := clientSet.Projects("default").List(metav.ListOptions{})
    if err != nil {
        panic(err)
    }

    fmt.Printf("projects found: %+v\n", projects)
}

4.5 生成Informer

在构建Kubernetes Operator时，您通常希望能够对新创建或更新的资源做出反应。理论上，您可以定期调用List()方法，检查是否有新资源被添加。在实践中，这是一个次优的解决方案，尤其是当您有很多这样的资源时。

大多数Operator的工作方式是通过使用初始List()调用来初始加载资源的所有相关实例，然后使用Watch()调用来订阅更新。然后，初始对象列表和从Watch接收到的更新被用来构建一个本地缓存，允许快速访问任何自定义资源，而不必每次都打到API服务器。

这种模式非常常见，以至于client-go库为此提供了一个助手：k8s.io/client-go/tools/cache包中的Informer。您可以为您的自定义资源构建一个新的 Informer，如下所示：

package main

import (
    "time"

    "github.com/double12gzh/k8s-demo/api/types/valpha"
    client_valpha "github.com/double12gzh/k8s-demo/clientset/valpha"
    metav "ks.io/apimachinery/pkg/apis/meta/v"
    "ks.io/apimachinery/pkg/runtime"
    "ks.io/apimachinery/pkg/util/wait"
    "ks.io/apimachinery/pkg/watch"
    "ks.io/client-go/tools/cache"
)

func WatchResources(clientSet client_valpha.ExampleVAlphaInterface) cache.Store {
    projectStore, projectController := cache.NewInformer(
        &cache.ListWatch{
            ListFunc: func(lo metav.ListOptions) (result runtime.Object, err error) {
                return clientSet.Projects("some-namespace").List(lo)
            },
            WatchFunc: func(lo metav.ListOptions) (watch.Interface, error) {
                return clientSet.Projects("some-namespace").Watch(lo)
            },
        },
        &valpha.Project{},
        *time.Minute,
        cache.ResourceEventHandlerFuncs{},
    )

    go projectController.Run(wait.NeverStop)
    return projectStore
}

NewInformer方法返回两个对象。第二个返回值，控制器控制List()和Watch()调用，并在第一个返回值，即存储中填充一个（或多或少）最近在API服务器上被监视的资源状态的缓存（在本例中，项目CRD）。

现在，你可以使用 store 来轻松访问你的 CRD，要么列出所有的 CRD，要么通过名称来访问它们。请记住，存储函数返回的是通用interface{}类型，所以您必须将它们类型化回您的CRD类型。

store := WatchResource(clientSet)
project := store.GetByKey("some-namespace/some-project").(*v1alpha1.Project)

5. 总结

为Custom Resources构建客户端是（至少，目前）只有很少的文档，有时可能会有点棘手。

如本文所示，为你的Custom Resource建立一个客户端库，以及相应的Informer是一个很好的起点，可以构建你自己的Kubernetes Operator，对Custom Resource的变化做出反应。

您可以到我的github上查看完整代码

欢迎关注我的微信公众号：

在windows上通过wsl来部署k8s

2020-09-27T00:00:00+00:00

摘要：是Windows10和WSL2的新手，还是Docker和Kubernetes的新手？欢迎来到这篇博文，我们将在Docker KinD和Minikube中从头开始安装Kubernetes。

1. 写在前面

为什么要在windows上使用kubernetes?

在过去的几年里，Kubernetes成为了在分布式环境中运行容器化服务和应用的事实标准平台。虽然存在各种各样的发行版和安装程序来部署Kubernetes在云环境（公共的、私有的或混合的），或在裸机环境中，但仍然需要在本地部署和运行Kubernetes，例如，在开发者的工作站上。

Kubernetes最初被设计为在Linux环境中部署和使用。然而，有不少用户（不仅是应用开发者）使用Windows操作系统作为日常工具。当微软揭示了WSL–Windows Subsystem for Linux时，Windows和Linux环境之间的界限变得更加不明显。

同时，WSL还带来了在Windows上几乎无缝运行Kubernetes的能力!

下面，我们将简要介绍如何安装和使用各种解决方案在本地运行Kubernetes。

2. 前提条件

尽管我们将会安装Kind，但是，讲解太多关于如何安装的细节，如果您对这个比较关注，请关注我后续的文章。

首先，我们先看一下我们继续进行下面的操作前，我们的最小的软件版本的需求:

OS：Win10 version 2004, build 19041。
WSL2开启。安装完成后，可以使用wsl.exe --set-default-version 2设置使用WSL2。
WSL2可以通过win应用商店来安装，这里使用的是Ubuntu 18.04。
Docker-desktop-for-windows。
(可选)Microsoft Terminal。可以从windows应用商店进行安装。

Tip

如何查看win10的版本信息？

win+R
输入winver

3. WSL2：首次接触

上面的软件都安装完成后，我们就可以从开始->Ubuntu来打开wsl2了。

打开后，你完全可以把它看成是一个正常的Linux的发行，同样的，你也可以在里面设置用户等。

3.1 (可选)设置``sudoers``

由于我们是在本地计算机上工作，通常情况下，更新sudoers，并将%sudo组设置为无密码组，可能会更好。

# 用visudo打开sudoer文件
sudo visudo

# 设置sudo group免密登陆
%sudo   ALL=(ALL:ALL) NOPASSWD: ALL

# 按 CTRL+X 退出
# 按 Y 保存
# 按 Enter 确认

3.2 更新Ubuntu

在进行后面的操作前，我们先升级一下我们的系统。

# 更新apt-get源
sudo apt update
# 基于最新的源更新系统。automatically
sudo apt upgrade -y

4. Docker Desktop

Docker-Windows-Desktop与WSL2更配哦。

在我们进入设置之前，让我们做一个小测试，它将显示出与Docker Desktop的新集成是多么的酷。

# 看一下docker的版本及docker是否被安装
docker version
# 看一下kubectl的版本及kubectl是否被安装
kubectl version

你有遇到错误吗？有错误就对了，所以现在让我们继续进行设置。

4.1 设置docker desktop：开启对WSL2的支持

如果还没有打开Docker-For-Windows的话，首先我们来启动它。打开Windows的开始菜单，输入”docker”，点击名称启动应用程序。

现在在你的任务栏中就能看到它的图标了。

下面我们在docker-for-windows的中设置一下，让他使用wsl2:

这个选项默认情况下并没有开启:

这个功能在幕后所做的就是在WSL2中创建了两个新的发行版，包含并运行所有需要的后端socket、守护进程以及CLI工具（如：docker和kubectl命令）。

但是，第一种设置仍然不足以在我们的发行版中运行命令。如果我们尝试，我们会遇到和之前一样的错误。

为了解决这个问题，并最终能够使用这些命令，我们需要告诉Docker桌面也要”附加 “到我们的发行版上。

接下来，我们再看一下命令是否正常了呢：

# 看一下docker的版本及docker是否被安装
docker version
# 看一下kubectl的版本及kubectl是否被安装
kubectl version

System Message: ERROR/3 (/home/docs/checkouts/readthedocs.org/user_builds/gzh/checkouts/latest/blogs/Kubernetes/2020-09-27-WSL-Docker-Kubernetes-on-the-Windows-Desktop.rst, line 155)

Figure caption must be a paragraph or empty comment.

.. figure:: https://gitee.com/double12gzh/wiki-pictures/raw/master/2020-09-27-wsl_docker_kubernetes_win10/11.png
   :alt:

    说明:

    -  如果没有发生任何事情，重启Docker
       Desktop并在Powershell中重启WSL进程。重启服务LxssManager并启动一个新的Ubuntu会话。
    -  如果您的docker-desktop-for-win中没有\ ``Use the WSL2 based engine``\ 的，请重新安装它的\ ``edge``\ 版本。

5. Kind: 让k8s方便的运行在容器中

现在，我们的Docker已经安装好了，配置好了，上次的测试也很正常。

但是，如果我们仔细观察kubectl命令，它找到了”客户端版本”（1.15.5），但它没有找到任何服务器。

这很正常，因为我们没有启用Docker Kubernetes集群。所以让我们安装KinD并创建我们的第一个集群。

我们将按照KinD官方网站上的教程（部分）进行操作。

# 下载 KinD
curl -Lo ./kind https://github.com/kubernetes-sigs/kind/releases/download/v0.7.0/kind-$(uname)-amd64
# 增加可执行权限
chmod +x ./kind
# 移动到系统PATH中
sudo mv ./kind /usr/local/bin/

5.1 创建单节点的集群

下面，我们将会创建我们的第一个集群：

# 检查 KUBECONFIG 是否存在
echo $KUBECONFIG
# Check if the .kube directory is created > if not, no need to create it
ls $HOME/.kube
# Create the cluster and give it a name (optional)
kind create cluster --name wslkind
# Check if the .kube has been created and populated with files
ls $HOME/.kube

System Message: ERROR/3 (/home/docs/checkouts/readthedocs.org/user_builds/gzh/checkouts/latest/blogs/Kubernetes/2020-09-27-WSL-Docker-Kubernetes-on-the-Windows-Desktop.rst, line 203)

Figure caption must be a paragraph or empty comment.

.. figure:: https://gitee.com/double12gzh/wiki-pictures/raw/master/2020-09-27-wsl_docker_kubernetes_win10/13.png
   :alt:

    说明：对于执行的每一步，都会有一个小图标与之显示。

运行完上面的命令后，k8s集群就已经创建好了，因为我们使用是docker desktop，所以，里面的网络默认使用的是as is。

我们可以在浏览器中打开kubernetes master的页面：

而这才是Docker Desktop for Windows与WSL2后台的真正优势。Docker真的做了一个惊人的整合。

5.2 创建多节点的集群

上一节中，我们刚创建的那是一个单节点的集群。

# Check how many nodes it created
kubectl get nodes
# Check the services for the whole cluster
kubectl get all --all-namespaces

虽然那也已经能满足大多数人的需求了，但是，下面我们还是来继续看一下它另外一个更加酷炫的能力：创建多节点的集群。

# Delete the existing cluster
kind delete cluster --name wslkind
# Create a config file for a 3 nodes cluster
cat << EOF > kind-3nodes.yaml
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
  - role: control-plane
  - role: worker
  - role: worker
EOF
# Create a new cluster with the config file
kind create cluster --name wslkindmultinodes --config ./kind-3nodes.yaml
# Check how many nodes it created
kubectl get nodes

System Message: ERROR/3 (/home/docs/checkouts/readthedocs.org/user_builds/gzh/checkouts/latest/blogs/Kubernetes/2020-09-27-WSL-Docker-Kubernetes-on-the-Windows-Desktop.rst, line 253)

Figure caption must be a paragraph or empty comment.

.. figure:: https://gitee.com/double12gzh/wiki-pictures/raw/master/2020-09-27-wsl_docker_kubernetes_win10/16.png
   :alt:

    提示：根据我们运行 "get nodes"命令的速度，可能不是所有的节点都准备好了，等几秒钟再运行，一切都应该准备好了。

到此，我们已经创建完了三节点的一个集群，我们通过下面的命令再来看一下，如果你仔细看你会发现，每一个服务都是三副本的了。

# Check the services for the whole cluster
kubectl get all --all-namespaces

5.3 查看k8s Dashboard

对于开发人员来说，在命令行上执行操作是可以接受，并且这样效率也比较高。然而，在处理Kubernetes时，我们可能希望在某些时候有一个可视化的概述。为此，我们创建了Kubernetes Dashboard项目。安装和第一次连接测试是相当快的，所以我们来做吧。

# Install the Dashboard application into our cluster
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0-rc6/aio/deploy/recommended.yaml
# Check the resources it created based on the new namespace created
kubectl get all -n kubernetes-dashboard

虽然kind使用ClusterIP为集群创建了一个service，但是由于这个IP是一个内网的IP，所以我们现在还无法从页面上直接访问dashboard服务。

这个问题可以通过创建一个proxy来解决：

# Start a kubectl proxy
kubectl proxy
# Enter the URL on your browser: http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/

最后要登录，我们可以输入一个我们没有创建的Token，或者从我们的Cluster中输入kubeconfig文件。

如果我们尝试用kubeconfig登录，我们会得到错误 “Internal error (500): Not enough data to create auth info structure”。没有足够的数据来创建Auth信息结构”。这是由于kubeconfig文件中缺乏凭证。

因此，为了避免你以同样的错误结束，让我们按照推荐的RBAC方法。

让我们打开一个新的WSL2会话。

# Create a new ServiceAccount
kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
  name: admin-user
  namespace: kubernetes-dashboard
EOF
# Create a ClusterRoleBinding for the ServiceAccount
kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: admin-user
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: admin-user
  namespace: kubernetes-dashboard
EOF

# Get the Token for the ServiceAccount
kubectl -n kubernetes-dashboard describe secret $(kubectl -n kubernetes-dashboard get secret | grep admin-user | awk '{print $1}')
# Copy the token and copy it into the Dashboard login and press "Sign in"

6. minikube: 让k8s可任意部署

现在，我们的Docker已经安装好了，配置好了，上次的测试也很正常。

但是，如果我们仔细观察kubectl命令，它找到了 “Client Version”（1.15.5），但它没有找到任何服务器。

这很正常，因为我们没有启用Docker Kubernetes集群。所以让我们安装Minikube并创建我们的第一个集群。

我们将按照Kubernetes.io网站上的方法（部分）进行操作。

# Download the latest version of Minikube
curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
# Make the binary executable
chmod +x ./minikube
# Move the binary to your executable path
sudo mv ./minikube /usr/local/bin/

6.1 更新Host

如果我们按照how-to，它提示我们应该使用–driver=none标志，以便直接在主机和Docker上运行Minikube。

不幸的是，我们会得到一个关于运行Kubernetes v 1.18需要 “conntrack”的错误信息

# Create a minikube one node cluster
minikube start --driver=none

根据提示，我们是缺少了一个包，下面我们就把它安装上：

# Install the conntrack package
sudo apt install -y conntrack

安装完成后，再次启动：

# Create a minikube one node cluster
minikube start --driver=none
# We got a permissions error > try again with sudo
sudo minikube start --driver=none

这次是不是没有出错呢。

6.2 启用`systemd`

为了能够使用systemd，我们需要按照这个脚本来配置一下。

说明：如果您想了解更多关于这个脚本背后的考虑，请参考

在终端中输入以下命令：

# Install the needed packages
sudo apt install -yqq daemonize dbus-user-session fontconfig

# Create the start-systemd-namespace script
sudo vi /usr/sbin/start-systemd-namespace
#!/bin/bash

SYSTEMD_PID=$(ps -ef | grep '/lib/systemd/systemd --system-unit=basic.target$' | grep -v unshare | awk '{print $2}')
if [ -z "$SYSTEMD_PID" ] || [ "$SYSTEMD_PID" != "1" ]; then
    export PRE_NAMESPACE_PATH="$PATH"
    (set -o posix; set) | \
        grep -v "^BASH" | \
        grep -v "^DIRSTACK=" | \
        grep -v "^EUID=" | \
        grep -v "^GROUPS=" | \
        grep -v "^HOME=" | \
        grep -v "^HOSTNAME=" | \
        grep -v "^HOSTTYPE=" | \
        grep -v "^IFS='.*"$'\n'"'" | \
        grep -v "^LANG=" | \
        grep -v "^LOGNAME=" | \
        grep -v "^MACHTYPE=" | \
        grep -v "^NAME=" | \
        grep -v "^OPTERR=" | \
        grep -v "^OPTIND=" | \
        grep -v "^OSTYPE=" | \
        grep -v "^PIPESTATUS=" | \
        grep -v "^POSIXLY_CORRECT=" | \
        grep -v "^PPID=" | \
        grep -v "^PS1=" | \
        grep -v "^PS4=" | \
        grep -v "^SHELL=" | \
        grep -v "^SHELLOPTS=" | \
        grep -v "^SHLVL=" | \
        grep -v "^SYSTEMD_PID=" | \
        grep -v "^UID=" | \
        grep -v "^USER=" | \
        grep -v "^_=" | \
        cat - > "$HOME/.systemd-env"
    echo "PATH='$PATH'" >> "$HOME/.systemd-env"
    exec sudo /usr/sbin/enter-systemd-namespace "$BASH_EXECUTION_STRING"
fi
if [ -n "$PRE_NAMESPACE_PATH" ]; then
    export PATH="$PRE_NAMESPACE_PATH"
fi

# Create the enter-systemd-namespace
sudo vi /usr/sbin/enter-systemd-namespace
#!/bin/bash

if [ "$UID" != 0 ]; then
    echo "You need to run $0 through sudo"
    exit 1
fi

SYSTEMD_PID="$(ps -ef | grep '/lib/systemd/systemd --system-unit=basic.target$' | grep -v unshare | awk '{print $2}')"
if [ -z "$SYSTEMD_PID" ]; then
    /usr/sbin/daemonize /usr/bin/unshare --fork --pid --mount-proc /lib/systemd/systemd --system-unit=basic.target
    while [ -z "$SYSTEMD_PID" ]; do
        SYSTEMD_PID="$(ps -ef | grep '/lib/systemd/systemd --system-unit=basic.target$' | grep -v unshare | awk '{print $2}')"
    done
fi

if [ -n "$SYSTEMD_PID" ] && [ "$SYSTEMD_PID" != "1" ]; then
    if [ -n "$1" ] && [ "$1" != "bash --login" ] && [ "$1" != "/bin/bash --login" ]; then
        exec /usr/bin/nsenter -t "$SYSTEMD_PID" -a \
            /usr/bin/sudo -H -u "$SUDO_USER" \
            /bin/bash -c 'set -a; source "$HOME/.systemd-env"; set +a; exec bash -c '"$(printf "%q" "$@")"
    else
        exec /usr/bin/nsenter -t "$SYSTEMD_PID" -a \
            /bin/login -p -f "$SUDO_USER" \
            $(/bin/cat "$HOME/.systemd-env" | grep -v "^PATH=")
    fi
    echo "Existential crisis"
fi

# Edit the permissions of the enter-systemd-namespace script
sudo chmod +x /usr/sbin/enter-systemd-namespace
# Edit the bash.bashrc file
sudo sed -i 2a"# Start or enter a PID namespace in WSL2\nsource /usr/sbin/start-systemd-namespace\n" /etc/bash.bashrc

现在再重新打开一个wsl2的窗口，没有必要把前一个窗口关闭。

6.3 创建集群

下面我们创建我们的第一个集群:

# Check if the KUBECONFIG is not set
echo $KUBECONFIG
# Check if the .kube directory is created > if not, no need to create it
ls $HOME/.kube
# Check if the .minikube directory is created > if yes, delete it
ls $HOME/.minikube
# Create the cluster with sudo
sudo minikube start --driver=none

为了不用sudo就能执行kubelet，Minikube建议执行一下chown命令:

# Change the owner of the .kube and .minikube directories
sudo chown -R $USER $HOME/.kube $HOME/.minikube
# Check the access and if the cluster is running
kubectl cluster-info
# Check the resources created
kubectl get all --all-namespaces

集群成功创建了，并且Minikube使用的是wsl2的IP，这样以来，我们不需要新配置proxy就可以直接访问dashboard了。

而WSL2集成的真正优势，8443端口一旦在WSL2发行版上打开，它其实是转发到Windows上的，所以我们不需要代理这个IP地址，也可以通过localhost访问到Kubernetes的dashboard URL。

6.4 访问dashboard

在命令行上工作总是好的，而且非常有见地。然而，当处理Kubernetes时，我们可能会在某些时候希望有一个可视化的概述。

为此，Minikube嵌入了Kubernetes Dashboard。得益于它，运行和访问Dashboard非常简单。

# Enable the Dashboard service
sudo minikube dashboard
# Access the Dashboard from a browser on Windows side

该命令还创建了一个代理，这意味着一旦我们按CTRL+C键结束该命令，Dashboard将不再被访问。

不过，如果我们查看命名空间kubernetes-dashboard，我们会发现服务仍然存在。

# Get all the services from the dashboard namespace
kubectl get all --namespace kubernetes-dashboard

接下来，我们更改一下service的类型，让他以LoadBalancer作为后端：

# Edit the Dashoard service
kubectl edit service/kubernetes-dashboard --namespace kubernetes-dashboard
# Go to the very end and remove the last 2 lines
status:
  loadBalancer: {}
# Change the type from ClusterIO to LoadBalancer
  type: LoadBalancer
# Save the file

再次查看dashboard相关的service，这次我们通过LoadBalancer来访问：

# Get all the services from the dashboard namespace
kubectl get all --namespace kubernetes-dashboard
# Access the Dashboard from a browser on Windows side with the URL: localhost:<port exposed>

7. 结论

很明显，我们还远远没有完成，因为我们可以实现一些LoadBalancing和/或其他服务（存储、入口、注册表等）。

关于WSL2上的Minikube，由于它需要启用SystemD，我们可以把它看作是一个中间层来实现。

那么，在两种解决方案中，什么才是 “最适合你”的呢？两者都有各自的优势和不便，所以这里仅从我们的角度来概述一下。

对比项	Kind	Minikube
与WSL2共同使用	非常简单	一般简单
多节点	支持	不支持
插件	手动安装	自动安装
持久化	支持(但这并不是它的本初设计)	支持
同类型的其它产品	k3s	MicroK8s

我们希望你能真正体验到不同组件之间的整合。WSL2 - Docker Desktop -KinD/Minikube。这给了你一些想法，甚至更好的是，给了你在Windows和WSL2上使用KinD和/或Minikube的Kubernetes工作流的一些答案。

8. 出处

WSL+Docker: Kubernetes on the Windows Desktop

使用GitOps管理K8S Secret

2020-10-03T00:00:00+00:00

摘要: 介绍如何使用GitOps来管理Kubernetes Secret。

1. 写在前面

GitOps是伴随着云原生产生的一个新的概念，它的核心是以一种声明式的方式管理资源，表示当前的状态，让你在任何时候都能知道git中的情况，并将这种声明式的状态解析为集群。

我们在GitOps上犯的最大错误是结构。仓库的结构至关重要，你选择如何在公司里组织GitOps，将决定它的成败。

当你解决了结构问题之后，我们面临的下一个最大的问题就是如何保证Secret的安全。一般来说，最后的结果是人们有不需要的访问权限，或者有一个共享的Secret，通过Slack或1Password传来传去。

Sealed Secrets是Kubernetes上解决Secret的一种流行方式，它是一个不错的解决方案，依靠PKI和共享公钥来加密，并在集群上安装私钥。

本文将尝试解释如何使用GitOps来管理k8s的Secret资源。

2. 管理Secret比较好的方式

Mozilla的SOPS。

SOPS支持多种来源的密钥输入，包括AWS KMS、GCE、Vault、PGP等。它提供了使用AWS KMS的外部密钥作为输入来加密和解密秘密的能力，但它也支持Shamir的``Secret` <https://en.wikipedia.org/wiki/Shamir’s_Secret_Sharing>`__共享和密钥组，本质上允许对解密所需的密钥以及这些密钥的数量进行策略。

由于SOPS让我们有能力使用AWS KMS这样的服务，我们可以控制谁有加密和解密的权限，但这也意味着我们可以利用AWS的实例配置文件，让机器做它们设计时最擅长的事情，通过自动化让我们的生活更轻松。

最后一个我想提请大家注意的功能是，一旦文件被加密，所有关于如何加密的元数据都是文件本身的一部分，不需要第三方服务、数据库、隐藏目录或二级文件来知道如何解密文件。

Flux对SOPS有一流的支持。

3. 结构

一开始我就说过，正确架构你的仓库是至关重要的。这一点来源于个人在工程实践中总结的一些经验之谈，对于不同的场景，您可能需要权衡一下我这里的“最佳实践”。

对于结构化化来说，通常可以简单的分成两个部分：

仓库中内容的布局
使用仓库的数量

在我的项目中，我通常会使用三个库： - 定义集群运行所需的每一个基础资源 - 处理工程团队负责的产品的所有发布 - 给Secret使用

项目中我只使用了SOPS与专用的Secret库，使用Flux和SOPS使我们获得了这种能力，具有前所未有的灵活性。

3.1 目录结构

|-- .sops.yaml
|-- secrets
    |-- dev (environment/cluster)
        |-- database.yaml
    |-- stg (environment/cluster)
        |-- database.yaml
    |-- prd (environment/cluster)
        |-- database.yaml

这个文件布局为我们提供了使用SOPS创建规则来控制文件如何加密的基础。我们可以使用不同的密钥、密钥组和阈值。它还允许我们告诉Flux在克隆和解析集群上需要的东西时只关心一个特定的路径。下面是一个例子(注意：这不是一个完整可运行的例子)。

creation_rules:
- path_regex: secrets/dev/.*
  encrypted_regex: "^(data|stringData)$"
  kms:
    arn: kms-arn
    role: ksm-role
- path_regex: secrets/stg/.*
  encrypted_regex: "^(data|stringData)$"
  kms:
    arn: kms-arn
    role: ksm-role
- path_regex: secrets/prd/.*
  encrypted_regex: "^(data|stringData)$"
  kms:
    arn: kms-arn
    role: ksm-role

3.2 Scaling

使用这个设置，我们几乎可以无限地扩展这个设置。它只受存储在版本库中的数据量和服务于它的git服务器的限制。秘密一般不会经常变化，但它们会被轮换，这就是像Reloader这样的额外工具的作用(这里不会作详细介绍)。

Reloader:

它可以用于监视ConfigMap和Secret是否发生变化，如果发生了变化，它将触发与之相关的以下资源实现滚动更新：

DeploymentConfig

Deployment

Daemonset

Statefulset

4. 设置SOPS

前面我们已经讲解了SOPS的目录结构和设计原则，下面我们通过一个小例子实践一下。

有多种方法可以利用SOPS，但我只介绍其中一种：使用AWS KMS与多个键和AWS Instance Profile(Flux可以使用)。

4.1 设置AWS

在真正的使用场景中，我会建议使用多个AWS账户，并假设角色权限，但对于这样的文章来说，这可能会变得不必要的复杂，所以我们要假设一个单一的AWS账户，但仍然利用使用3个密钥。

aws kms create-key

一定要把ARN收集起来，以便以后使用。

接下来我们需要创建我们的.sops.yaml文件与创建规则。在真正的使用场景中，你会希望你的阈值是2或更多，并且让你的密钥至少比阈值高N+1。让我们从创建一个基础目录开始，然后创建.sops.yaml文件，内容如下，确保用你的有效ARNs交换ARNs。

creation_rules:
- path_regex: secrets/dev/.*
  encrypted_regex: "^(data|stringData)$"
  shamir_threshold: 2
  key_groups:
    - kms:
        - arn: arn:aws:kms:us-west-2:000000000000:key/b5d44bf0-7ec5-49a9-b404-bc4d8b4036fb
    - kms:
        - arn: arn:aws:kms:us-west-2:000000000000:key/16d44186-2393-40d9-90e1-9a2f92fd5863
    - kms:
        - arn: arn:aws:kms:us-west-2:000000000000:key/2120d2c1-a89e-4aeb-844f-f17ae2abd210

这个创建规则规定，secrets/dev目录下的所有文件都要用3个不同的密钥进行加密，解密阈值为2。

接下来创建你的secrets/dev目录，并创建一个example.yaml文件，内容如下：

apiVersion: v1
kind: Secret
metadata:
  name: example
type: Opaque
data:
  username: gzhGZHSBWUDESIN=
  password: SBALIBSBWUDESIN=

使用如下命令结上面的yaml文件进行加密：

sops -e -i secrets/dev/example.yaml

说明:

-e: 加密

-i: 支持原地修改(如果您不想修改原文件并且想看加密后的输入内容，请忽略此参数)

上面的命令执行完成后您就可以提交到仓库中了。

4.2 AWS实例配置文件

这个系统的好处是，Flux可以简单地利用AWS实例配置文件，通过STS承担角色，并获得临时的密钥，以便在集群本身运行时能够解密。要实现这一点，您需要设置一个角色，该角色具有Encrypt/Decrypt和可能的Generate权限，具体取决于您使用的密钥类型，并设置您的AWS实例以使用配置文件。

一旦您完成了这些设置，只需使用正确的 CLI 选项将 Flux 安装到群集上，Flux就会让您的群集保持最新状态。

4.3 设置Flux

你只需要做几件事情来确保Flux的正常运行，你需要启用SOPS，这取决于你的部署方法，可能是配置选项或CLI标志--sops。你需要启用 SOPS，根据你的部署方法，可能是一个配置选项或 CLI 标志``–sops``。你还需要指示你的 Flux``实例只关心默认分支中的一个特定路径。\ ``--git-path 需要设置为 Secrets 下的一个目录，比如 --git-path=secrets/dev。

5. 小结

使用这种方法可以让你更好地控制Secret及谁有访问权，另外，它也允许您让AWS处理提供Secret中比较难搞的部分，以通过自动化和短暂的Secret来访问Secret解密，您可以将所有的Secret保存在一个地方，以便于管理和轮换。

client-go系列之1—client-go代码详解

2020-10-11T00:00:00+00:00

摘要：介绍golang-client的代码结构

1. 写在前面

个人主页: https://gzh.readthedocs.io

关注容器技术、关注Kubernetes。
问题或建议，请公众号留言。

本系列内容都是基于这个版本的client-go进行讲解，不同版本的略有差异。

[root@77DDE94FF07FCC1-wsl /ACode/client-go] git rev-parse HEAD
becbabb360023e1825a48b4db85f454e452ae249

下面简单罗列一下本文中可能会用提到的一些常用缩写，详细的介绍请参考后面的文章(TODO)谈起k8s中的GVR我们实际在讲什么。

说明：

看一下k8s的资源模型：

apiVersion: extensions/v1beta1
kind: ReplicaSet

对于Resource我们可以将之类比于编程语言中的“包”的概念，主要用于区分不同的API，
这样可以有效避免Kinds重名的问题。通常会使用公司的域名等具有独特明显区分的字符
串作为Resource的值，如：alibaba-inc.com
Version用于区分不同API的稳定程度及兼容性，如：v1beta1, v1

Kind即为API所对应的名字，如：Deployment, Service

2. 代码结构

从这个包的名字可以很明显的知道，client-go其实主要是提供了用户与k8s交互时使用客户端，方便大家编程。

个别目录已过滤掉。

[root@77DDE94FF07FCC1-wsl /ACode/client-go] tree -d -L 1 -I "testing|examples|*_test*|Godeps|third_party|metadata|deprecated|restmapper"
.
├── discovery                   # 定义DsicoveryClient客户端。作用是用于发现k8s所支持GVR(Group, Version, Resources)。
├── dynamic                     # 定义DynamicClient客户端。可以用于访问k8s Resources(如: Pod, Deploy...)，也可以访问用户自定义资源(即: CRD)。
├── informers                   # k8s中各种Resources的Informer机制的实现。
├── kubernetes                  # 定义ClientSet客户端。它只能用于访问k8s Resources。每一种资源(如: Pod等)都可以看成是一个客端，而ClientSet是多个客户端的集合，它对RestClient进行了封装，引入了对Resources和Version的管
|                               # 理。通常来说ClientSet是client-gen来自动生成的。
├── listers                     # 提供对Resources的获取功能。对于Get()和List()而言，listers提供给二者的数据都是从缓存中读取的。
├── pkg
├── plugin                      # 提供第三方插件。如：GCP, OpenStack等。
├── rest                        # 定义RestClient，实现了Restful的API。同时会支持Protobuf和Json格式数据。
├── scale                       # 定义ScalClient。用于Deploy, RS, RC等的扩/缩容。
├── tools                       # 定义诸如SharedInformer、Reflector、DealtFIFO和Indexer等常用工具。实现client查询和缓存机制，减少client与api-server请求次数，减少api-server的压力。
├── transport
└── util                        # 提供诸如WorkQueue、Certificate等常用方法。

12 directories

3. 代码使用简单示例

在对每一部分进行讲解前，先用一个图来讲解各部分之间的关系：

对于图中的每一个带有标号的部分，下面给出简单的代码使用展示，如果暂时不明白下面的代码可以先进行下一章节的学习。

3.1 获取kubeconfig及context

这一部分对应于序号1—tools/clientcmd。

func main() {
        var kubeconfig *string

        // 默认会从~/.kube/config路径下获取配置文件
        if home := homeDir(); home != "" {
                kubeconfig = flag.String("kubeconfig", filepath.Join(home, ".kube", "config"), "(optional)absolute path to the kubeconfig file")
        } else {
                kubeconfig = flag.String("kubeconfig", "", "absolute path to the kubeconfig file")
        }

        flag.Parse()

        // 使用k8s.io/client-go/tools/clientcmd生成config的对象
        if config, err := clientcmd.BuildConfigFromFlags("", *kubeconfig); err != nil {
                panic(err.Error())
        }
}

3.2 创建ClientSet

这一部分对应于序号2—ClientSet。

// 使用k8s.io/client-go/kubernetes生成一个ClientSet的客户端，客户端生成后，就可以使用这个客户端与k8s API server进行交互了，如获取资源列表、Create/Update/Delete资源等
clientset, err := kubenetes.NewForConfig(config)
if err != nil {
    panic(err.Error())
}

3.3 使用ClientSet获取集群中的pods

这一部分对应于序号2/3/4—RestClient。

for {
    // 使用ClientSet客户端获取集群中所有的Pods。其中：ListOptions的结构如下：
    // type ListOptions struct {
    //      TypeMeta `json:",inline"`
    //      LabelSelector string `json:"labelSelector,omitempty"`
    //      FieldSelector string `json:"fieldSelector,omitempty"`
    //}
    pods, err := clientset.CoreV1().Pods("").List(metav1.ListOptions{})
    if err != nil {
        panic(err.Error())
    }

    fmt.Printf("Number of pods are: %d\n", len(pods.Items))
}

3.4 使用ClientSet获取指定的pod

这一部分对应于序号2/3/4—tools/clientcmd。

for {
    // 在这里我们从default这个namespace中获取了名为my-pod的Pod对象
    pod, err := clientset.CoreV1().Pods("default").Get("my-pod", metav1.GetOptions{})
    if err != nil {
        painc(err.Error())
    }

    fmt.Printf("%v\n\n\n\n", pod.spec)
}

4. 各种Clients详解

client-go中定义的比较重要的client有：

RestClient
ClientSet (用法示例)
DiscoveryClient
DynamicClient (用法示例)

其中，RestClient是所有客户端的基础，后三者都是对RestClient的封装。RestClient它通过kubeconfig与k8s-api-server进行交互。详细结构如下图：

ClientSets使用预生成的API对象, 这样的好处是当本地的API对象与k8s-api-server进行交互时会变得比较方便，方便的同时，随之也带来了版本与类型强耦合的问题。

DynamicClient则使用unstructured.Unstructured表示来自API Server的所有对象值。Unstructured类型是一个嵌套的map[string]inferface{}值的集合来创建一个内部结构，这一点类似于RESTful API中的Json数据，这样可以解决ClientSet中出现的强耦合的问题，换句话说，当客户端的API发生变化时，DynamicClient无需重新编译。DynamicClient使所有数据实现延时绑定，即只有到运行时才会实现绑定，这意味着程序运行之前，使用DynamicClient的程序将不会对对象进行Validation，这也是本client的一个缺点。

5. 其它组件

client-go中除了上面提到比较重要的客户端外, 本库还包含了各种机制(tools/cache)。

下图比较直观的展示了client-go与customer controller及client-go各组件之间的交互关系，是我们在开发自定义控制器时经常需要使用的机制，了解这个图有助于我们更好的理解client-go及controller背后的实现逻辑。

如果您对client-go之前就比较了解，建议您移步sample-controller看一下控制器实现的具体代码。

5.1 Reflector

refelector是定义在包缓存里面的Reflector结构体，可以用于监视指定资源类型（kind）的Kubernetes API。

实现这个功能的函数是ListAndWatch。监视的对象可以是一个内置的资源，也可以是一个自定义的资源(CRD)。

当reflector通过watch API接收到关于新资源实例存在的通知时，它会使用相应的listing API获取新创建的对象，并将其放在watchHandler函数里面的DeltaFIFO队列中。

5.2 Informer

它是定义在包缓存中的一个基础控制器，它可以w使用函数processLoop从DeltaFIFO队列中取出对象。

这个基础控制器的工作是保存对象以便以后检索，并调用我们的控制器将对象传递给它。

5.3 Indexer

提供对对象的索引功能。它被定义在tools/cache包中的Indexer类型中。

一个典型的索引用例是基于对象标签创建一个索引。Indexer可以基于几个索引函数来维护索引。Indexer使用一个线程安全的数据存储来存储对象和它们的键值。

在tools/cache内的Store类型中定义了一个名为MetaNamespaceKeyFunc的默认函数，该函数为该对象生成一个对象的键，作为<namespace>/<name>组合。

5.4 WorkQueue

这是在控制器代码中创建的队列，用于将对象的分发与处理解耦。编写 Resource Event Handler 函数来提取所分发对象的键值并将其添加到工作队列中。

欢迎关注我的微信公众号：

client-go系列之2—管理kubeconfig

2020-10-13T00:00:00+00:00

摘要：分析如何通过client-go来管理kubeconfig。

1. 写在前面

个人主页: https://gzh.readthedocs.io

关注容器技术、关注Kubernetes。问题或建议，请公众号留言。

本系列内容都是基于这个版本的client-go进行讲解，不同版本的略有差异。

在使用client-go开发时，通常会遇到两种情况：

在集群内部访问kubernetes资源
在集群外部访问kubernetes资源

关于这两种方式的区别，可以分别看一下下面这段代码直观感受一下：

2. 集群配置管理

k8s的配置文件默认会存放在~/.kube/config中，其内容如下：

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0xxxxxxxxCg==
    server: https://127.0.0.1:33629
  name: kind-kind
contexts:
- context:
    cluster: kind-kind
    user: kind-kind
  name: kind-kind
current-context: kind-kind
kind: Config
preferences: {}
users:
- name: kind-kind
  user:
    client-certificate-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1Jxxxxxxx==
    client-key-data: LS0tLS1yyyyyyyCg==

上面这是单个配置文件情况，client-go提供了合并多个配置文件的能力，合并完成后如下：

apiVersion: v1

clusters:
- cluster:
    certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQtCg==
    server: https://127.0.0.1:51107
  name: kind-guan
- cluster:
    certificate-authority-data: LS0tLS1CRUdJTiBDRVJtCg==
    server: https://127.0.0.1:33629
  name: kind-kind

contexts:
- context:
    cluster: kind-guan
    user: kind-guan
  name: kind-guan
- context:
    cluster: kind-kind
    user: kind-kind
  name: kind-kind


current-context: kind-kind

kind: Config

preferences: {}

users:
- name: kind-guan
  user:
    client-certificate-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUUtLS0tLQo=
    client-key-data: LS0tLS1CRUdJTiBxxxxxS0tCg==
- name: kind-kind
  user:
    client-certificate-data: LS0tLS1CRUdJTiBDRVJxxxxxxEUtLS0tLQo=
    client-key-data: LS0tLS1CRUdJTiBSU0EgUFJJVkFURSxxxxg==

client-go中对于配置文件的管理可以简单概括为以下两点：

加载配置文件
合并配置文件

接下来分别从代码层面看一下。

2.1 加载配置文件

加载配置文件的代码如下：

func main() {
        var kubeconfig *string

        // 默认会从~/.kube/config路径下获取配置文件
        if home := homeDir(); home != "" {
                kubeconfig = flag.String("kubeconfig", filepath.Join(home, ".kube", "config"), "(optional)absolute path to the kubeconfig file")
        } else {
                kubeconfig = flag.String("kubeconfig", "", "absolute path to the kubeconfig file")
        }

        flag.Parse()

        // 使用k8s.io/client-go/tools/clientcmd加载配置文件并生成config的对象
        if config, err := clientcmd.BuildConfigFromFlags("", *kubeconfig); err != nil {
                panic(err.Error())
        }
}

clientcmd.BuildConfigFromFlags加载配置文件后, 会生成一个Config的对象，这个对象中会包含如：apiserver地址、用户名、密码、token等信息。

进入到clientcmd.BuildConfigFromFlags查看其进行配置加载相关的代码：

代码位置：tools/clientcmd/client_config.go

生成一个结构体：ClientConfigLoadingRules，这里面记录了当前传入的kubeconfig文件的位置。另外，在这个结构体中有一个变量load ClientConfigLoader，对于kubeconfig文件的管理，就是通过其中定义的ClientConfigLoadingRules.Load()实现的。

2.2 合并配置文件

上面对kubeconfig完成加载后，下一步就需要对kubeconfig做合并处理。

代码位置: tools/clientcmd/loader.go

欢迎关注我的微信公众号：

client-go系列之3—restclient的使用

2020-10-14T00:00:00+00:00

摘要：介绍如何使用client-go中的restclient，可以结合“系列之1”来看。

0. 背景

个人主页: https://gzh.readthedocs.io

关注容器技术、关注Kubernetes。问题或建议，请公众号留言。

首先我通过kind创建了一个6节点的集群，本文章中所有的操作都是在这个集群中进行的。

通过本文的讲解，希望您能了解如何使用client-go中的RESTClient来对资源进行操作，这里我只是举了最简单的例子—pod资源获取。

文中用到的软件的版本如下：

kind

[root@xxx-wsl ~/client-go-example] kind version
kind v0.9.0 go1.15.2 linux/amd64

1. 环境准备

通过kind创建多节点的k8s集群: 3个master节点 + 3个worker节点

[root@xxx-wsl ~/init_kind_clusters] kind create cluster --config=init_cluster.yaml
Creating cluster "kind" ...
 ✓ Ensuring node image (kindest/node:v1.19.1) 🖼
 ✓ Preparing nodes 📦 📦 📦 📦 📦 📦
 ✓ Configuring the external load balancer ⚖️
 ✓ Writing configuration 📜
 ✓ Starting control-plane 🕹️
 ✓ Installing CNI 🔌
 ✓ Installing StorageClass 💾
 ✓ Joining more control-plane nodes 🎮
 ✓ Joining worker nodes 🚜
Set kubectl context to "kind-kind"
You can now use your cluster with:

kubectl cluster-info --context kind-kind

Not sure what to do next? 😅  Check out https://kind.sigs.k8s.io/docs/user/quick-start/

其中init_cluster.yaml内容如下：

[root@xxx-wsl ~/init_kind_clusters] cat init_cluster.yaml
# a cluster with 3 control-plane nodes and 3 workers
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
- role: control-plane
- role: control-plane
- role: worker
- role: worker
- role: worker

2. RestClient使用示例

这段代码的作用：从namespace为kube-system中获取所有的pod并输出到屏幕

main.go

package main

import (
        "context"
        "fmt"

        corev1 "k8s.io/api/core/v1"
        metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"

        "k8s.io/client-go/kubernetes/scheme"
        "k8s.io/client-go/rest"
        "k8s.io/client-go/tools/clientcmd"
)

func main() {
        fmt.Println("Prepare config object.")

        // 加载k8s配置文件，生成Config对象
        config, err := clientcmd.BuildConfigFromFlags("", "/root/.kube/config")
        if err != nil {
                panic(err)
        }

        config.APIPath = "api"
        config.GroupVersion = &corev1.SchemeGroupVersion
        config.NegotiatedSerializer = scheme.Codecs

        fmt.Println("Init RESTClient.")

        // 定义RestClient，用于与k8s API server进行交互
        restClient, err := rest.RESTClientFor(config)
        if err != nil {
                panic(err)
        }

        fmt.Println("Get Pods in cluster.")

        // 获取pod列表。这里只会从namespace为"kube-system"中获取指定的资源(pods)
        result := &corev1.PodList{}
        if err := restClient.
                Get().
                Namespace("kube-system").
                Resource("pods").
                VersionedParams(&metav1.ListOptions{Limit: 500}, scheme.ParameterCodec).
                Do(context.TODO()).
                Into(result); err != nil {
                panic(err)
        }

        fmt.Println("Print all listed pods.")

        // 打印所有获取到的pods资源，输出到标准输出
        for _, d := range result.Items {
                fmt.Printf("NAMESPACE: %v NAME: %v \t STATUS: %v \n", d.Namespace, d.Name, d.Status.Phase)
        }
}

go.mod

module main

go 1.15

require (
        github.com/go-logr/logr v0.2.1 // indirect
        github.com/google/gofuzz v1.2.0 // indirect
        github.com/imdario/mergo v0.3.11 // indirect
        golang.org/x/crypto v0.0.0-20201002170205-7f63de1d35b0 // indirect
        golang.org/x/net v0.0.0-20201010224723-4f7140c49acb // indirect
        golang.org/x/oauth2 v0.0.0-20200902213428-5d25da1a8d43 // indirect
        golang.org/x/sys v0.0.0-20201009025420-dfb3f7c4e634 // indirect
        golang.org/x/time v0.0.0-20200630173020-3af7569d3a1e // indirect
        k8s.io/api v0.19.2
        k8s.io/apimachinery v0.19.2
        //k8s.io/client-go v11.0.0+incompatible
        //      k8s.io/client-go v11.0.0+incompatible
        k8s.io/klog v1.0.0 // indirect
        k8s.io/klog/v2 v2.3.0 // indirect
        k8s.io/utils v0.0.0-20201005171033-6301aaf42dc7 // indirect
)

require k8s.io/client-go v0.19.2

3. 输出结果

[root@xxx-wsl ~/client-go-example] go run main.go
Prepare config object.
Init RESTClient.
Get Pods in cluster.
Print all listed pods.
NAMESPACE: kube-system NAME: coredns-f9fd979d6-rhzfd     STATUS: Running
NAMESPACE: kube-system NAME: coredns-f9fd979d6-whrj2     STATUS: Running
NAMESPACE: kube-system NAME: etcd-kind-control-plane     STATUS: Running
NAMESPACE: kube-system NAME: etcd-kind-control-plane2    STATUS: Running
NAMESPACE: kube-system NAME: etcd-kind-control-plane3    STATUS: Running
NAMESPACE: kube-system NAME: kindnet-bpsfl       STATUS: Running
NAMESPACE: kube-system NAME: kindnet-ks6zv       STATUS: Running
NAMESPACE: kube-system NAME: kindnet-pm6zl       STATUS: Running
NAMESPACE: kube-system NAME: kindnet-qfhqt       STATUS: Running
NAMESPACE: kube-system NAME: kindnet-s7qqn       STATUS: Running
NAMESPACE: kube-system NAME: kindnet-trk5l       STATUS: Running
NAMESPACE: kube-system NAME: kube-apiserver-kind-control-plane   STATUS: Running
NAMESPACE: kube-system NAME: kube-apiserver-kind-control-plane2          STATUS: Running
NAMESPACE: kube-system NAME: kube-apiserver-kind-control-plane3          STATUS: Running
NAMESPACE: kube-system NAME: kube-controller-manager-kind-control-plane          STATUS: Running
NAMESPACE: kube-system NAME: kube-controller-manager-kind-control-plane2         STATUS: Running
NAMESPACE: kube-system NAME: kube-controller-manager-kind-control-plane3         STATUS: Running
NAMESPACE: kube-system NAME: kube-proxy-7gz67    STATUS: Running
NAMESPACE: kube-system NAME: kube-proxy-bvbkk    STATUS: Running
NAMESPACE: kube-system NAME: kube-proxy-clf72    STATUS: Running
NAMESPACE: kube-system NAME: kube-proxy-d8zpb    STATUS: Running
NAMESPACE: kube-system NAME: kube-proxy-dsmsj    STATUS: Running
NAMESPACE: kube-system NAME: kube-proxy-fplkk    STATUS: Running
NAMESPACE: kube-system NAME: kube-scheduler-kind-control-plane   STATUS: Running
NAMESPACE: kube-system NAME: kube-scheduler-kind-control-plane2          STATUS: Running
NAMESPACE: kube-system NAME: kube-scheduler-kind-control-plane3          STATUS: Running

client-go系列之4—Indexer

2020-10-17T00:00:00+00:00

摘要：介绍client-go中Indexer机制。

1. 写在前面

在本系列教程的第一篇中，我们已经对如下这张图作了简单介绍。这张图非常重要，理解这张图对我们正确理解client-go及Controller非常有帮助(出处)。

client-go中对其实现的代码位于tools/cache，如下图：

除了上图中展示的Indexer的定义比较重要外，我们还需要关注Indexer比较重要的数据结构：

[root@xxxx-wsl /ACode/client-go] cat tools/cache/index.go| grep -B 1 -A 1 type

// IndexFunc knows how to compute the set of indexed values for an object.
type IndexFunc func(obj interface{}) ([]string, error)

--
// Index maps the indexed value to a set of keys in the store that match on that value
type Index map[string]sets.String

// Indexers maps a name to a IndexFunc
type Indexers map[string]IndexFunc

// Indices maps a name to an Index
type Indices map[string]Index

IndexFunc: 从接收的资源对象中，根据一系列的key来获取相应的值。
Index: 建立key与被索引值的对应关系并存储到Store中，即它里面的数据都是Key/Value的形式。
Indexers: 存储的是索引器的名字与索引器的实现函数。
Indices: 存储缓存数据，形式Key/Value，其中Key为缓存器的字，Value为缓存数据。

2. Custom Controller中的组件

如图中所示，Custom Controller是位于下半部分的内容。从图中可以很容易的看到，一个Custom Controller主要包含以下内容：

Indexer Reference
Informer Reference
Resource Event Handler
WorkQueue
ProcessItem

2.1 Indexer

2.1.1 简单介绍

它是一个知道如何使用CRD对象的 Indexer 实例的引用(reference)。当我们写自定义控制器(Custom Controller)代码时，将使用这个reference去做对象检索。

Indexer是client-go中实现的一个本地存储，它可以建立索引并存储Resource的对象。Reflector通过Delta FIFO Queue将资源对象存储到Indexer中。

需要注意的是，Indexer中的数据与etcd中的数据是完全一致的，这样client-go需要数据时，无须每次都从api-server获取，从而减少了请求过多造成对api-server的压力。

一句话总结：Indexer是用于存储+快速查找资源，即它的目的就是为了能够进行快速查找。

Indexer是如何实现“存储+快速查找资源”的呢？我们来看一下下面这张图，通过这张图方便我们理解一下Indexer的存储结构：

说明：图中的Indexers与Indices虽然都指向了相同的IndexFunc，这并不是说二者的数据是相同的，而是说二者使用的IndexFunc是相同的。

根据上面这个图，我们可以简单的规纳出与之对应的数据结构：

// 包含的所有索引器/分类以及对应的实现
Indexers: {  
    "namespace": NamespaceIndexFunc,
    "nodeName": NodeNameIndexFunc,
}

// 包含的所有索引分类中所有的索引数据
Indices: {
    //namespace 这个索引分类下的所有索引数据
    "namespace": {  
         // Index 就是一个索引键下所有的对象键列表
        "default": ["pod-1", "pod-2"], 
        // Index
        "kube-system": ["pod-3"]   
    },

    //nodeName 这个索引分类下的所有索引数据(对象键列表)
    "nodeName": {
         // Index
        "node1": ["pod-1"],
         // Index
        "node2": ["pod-2", "pod-3"]
    }
}

Indexers和Indices都是按照IndexFunc(名字)分组，每个IndexFunc输出多个IndexKey，产生相同IndexKey的多个对象存储在一个集合中。

IndexKey主要是用于快速查找ObjectKey; 而ObjectKey是对象存储时唯一命名的key(这个key方便在存储中快速找到相应的对象)。

2.1.2 代码位置

$GOPATH/pkg/mod/k8s.io/client-go@v0.19.0/tools/cache/index.go

2.1.3 类图展示

从下图我们可以很容易的看到Indexer与cache、Store及ThreadSafeStore之间的调用关系。

上图如果长时间无法显示，请参考这里

Store: 是一个通用对象存储和处理接口。

// Store is a generic object storage and processing interface.  A
// Store holds a map from string keys to accumulators, and has
// operations to add, update, and delete a given object to/from the
// accumulator currently associated with a given key.  A Store also
// knows how to extract the key from a given object, so many operations
// are given only the object.
//
// In the simplest Store implementations each accumulator is simply
// the last given object, or empty after Delete, and thus the Store's
// behavior is simple storage.
//
// Reflector knows how to watch a server and update a Store.  This
// package provides a variety of implementations of Store.
type Store interface {
40
   // Add adds the given object to the accumulator associated with the given object's key
   Add(obj interface{}) error
43
   // Update updates the given object in the accumulator associated with the given object's key
   Update(obj interface{}) error
46
   // Delete deletes the given object from the accumulator associated with the given object's key
   Delete(obj interface{}) error
49
   // List returns a list of all the currently non-empty accumulators
   List() []interface{}
52
   // ListKeys returns a list of all the keys currently associated with non-empty accumulators
   ListKeys() []string
55
   // Get returns the accumulator associated with the given object's key
   Get(obj interface{}) (item interface{}, exists bool, err error)
58
   // GetByKey returns the accumulator associated with the given key
   GetByKey(key string) (item interface{}, exists bool, err error)
61
   // Replace will delete the contents of the store, using instead the
   // given list. Store takes ownership of the list, you should not reference
   // it after calling this function.
   Replace([]interface{}, string) error
66
   // Resync is meaningless in the terms appearing here but has
   // meaning in some implementations that have non-trivial
   // additional behavior (e.g., DeltaFIFO).
   Resync() error
}

Indexer: 扩展了多个索引的 Store，并限制每个累加器只保存当前对象（删除后为空）。
ThreadSafeStore: 与Indexer类似，是一个允许对存储后端进行并发索引访问的接口

cache: 根据 ThreadSafeStore 和关联的 KeyFunc 实现的 Indexer。所有的对象都缓存在内存中，这不是一个外部可以调用的对象，在包的外部不能直接调用cache。它的定义也比较简单，如下：

// 代码位置：client-go/tools/cache/store.go
// `*cache` implements Indexer in terms of a ThreadSafeStore and an
// associated KeyFunc.
type cache struct {
   // cacheStorage bears the burden of thread safety for the cache
   cacheStorage ThreadSafeStore
   // keyFunc is used to make the key for objects stored in and retrieved from items, and
   // should be deterministic.
   keyFunc KeyFunc
}

我们可以使用NewStore或NewIndexer来实例化一个Store或Indexer。

threadSafeMap : 是 ThreadSafeStore的实现，它实现了并发安全的存储(它是一个内存中的存储)，具备CRUD等操作。它其中包含了三个比较重要的属性，见代码：
```
61 // 代码位置：client-go/tools/cache/thread_safe_store.go
62 // threadSafeMap implements ThreadSafeStore
63 type threadSafeMap struct {
64     lock  sync.RWMutex
65     items map[string]interface{} //用于保存数据
66
67     // indexers maps a name to an IndexFunc
68     indexers Indexers
69     // indices maps a name to an Index
70     indices Indices
71 }
```
对于threadSafeMap中各种索引的关系，我们可以用下图来表示：

threadSafeMap其实只会做两件事情：存储，索引。存储即存储runtime.object到items这个Map中；索引即为items这个Map建立三层索引：indices的Map类型的索引(如：namespace, nodeName等)；index Map的类型索引(如： namespace1, namespace2, …); runtime.object的索引。

如果我们需要向threadSafeMap中添加一个对象，只需要调用下以代码即可：
```
72 // 代码位置：client-go/tools/cache/thread_safe_store.go
73 func (c *threadSafeMap) Add(key string, obj interface{}) {
74     c.lock.Lock()
75     defer c.lock.Unlock()
76     oldObject := c.items[key]
77     c.items[key] = obj
78     c.updateIndices(oldObject, obj, key)
79 }
```
如果想了解更多的细节，请查看updateIndices()

另外，从图中我们也可以看出，Indexer实际上是对threadSafeMap的封装，它继承了后者的所有方法，同时也实现了IndexFunc。

2.2 Indexer索引器实现

在kubernetes中使用的比较多的索引函数是MetaNamespaceIndexFunc()（代码位置: client-go/tools/cache/index.go）。

Indexer索引的实现是通过index.ByIndex来完成的，index.ByIndex的代码如下：

// 代码位置：client-go/tools/cache/thread_safe_store.go
// ByIndex returns a list of the items whose indexed values in the given index include the given indexed value
func (c *threadSafeMap) ByIndex(indexName, indexedValue string) ([]interface{}, error) {
   c.lock.RLock()
   defer c.lock.RUnlock()
183
   indexFunc := c.indexers[indexName]  // 关键代码。获取索引器函数。
   if indexFunc == nil {
       return nil, fmt.Errorf("Index with name %s does not exist", indexName)
   }
188
   index := c.indices[indexName]   // 关键代码。获取缓存器函数。
190
   set := index[indexedValue]    // 关键代码。Index中的数据以Set类型存储在缓存中。
   list := make([]interface{}, 0, set.Len())
   for key := range set {
       list = append(list, c.items[key])
   }
196
   return list, nil
}

上述方法接收两个参数:

indexName: 索引器的名字
indexedValue: 需要索引的key

此方法的基本思路如下：

根据索引器名字查找指定的索引器函数(c.indexers[indexName])
根据索引器名字查找相应的缓存器函数(c.indices[indexName])
根据索引key(即：indexedValue)从缓存中进行数据查询，并返回查询结果

client-go系列之5—Informer

2020-10-21T00:00:00+00:00

摘要：介绍client-go informer及controller.

1. 写在前面

个人主页: https://gzh.readthedocs.io

关注容器技术、关注Kubernetes。

问题或建议，请公众号（double12gzh）留言。

依然秉承本系列的传统，在文章开始都会再次上一下下面这经经典的图(足见其重要性，哈哈哈)。

在client-go系列之1—client-go代码结构讲解中简单介绍一个client-go中的相关的模块(即图中上半部分)，其实，在client-go中不只是有前面提到的模块，还包括上图中下半部分的内容，即自定义控制器部分，如：

informer reference：是一个Informer的实例，主要用于处理与CRD（自定义资源）对象相关的。当我们开发自定义控制器（custom controller）时，需要这个控制器开创建相匹配的Informer。
indexer reference：是一个Indexer的实例，主要用于处理与CRD（自定义资源）对象相关的。当我们开发自定义控制器时，需要创建Indexer的实例，这个实例主要作用是实现存储+索引。
WorkQueue：工作者队列。前面我们提到过Informer，它除了更新本地缓存之外，还要将数据同步给相应控制器，WorkQueue就是为了数据同步的问题而产生的。当有资源被添加、修改或删除，Informer/SharedInformer就会将相应的事件加入到WorkQueue中。其它所有的控制器需要排队对这个queue进行读取，如果某个控制器发现这个事件与自己相关，就执行相应的操作。如果操作失败，就会把刚才取出的事件再放回到WorkQueue中，等再轮到自己执行时会再去重试这次失败的操作。如果操作成功，就将该事件从队列中删除。
Resource Event Handler：这是一个回调函数，当一个Informer/SharedInformer要分发一个对象到控制器时，会调用此函数。例如：将对象的Key放在WorkQueue中并等待后续的处理。
Process Item：用户自定义的处理WorkQueue中的相应Item的函数。如，我们可以在这里面使用Indexer或Listing wrapper来根据相应的Key检索对象。

Item的内容如下：

queue中的内容如下：

在client-go的controller中给出了如何定义Indexer和Informer的方法，代码位置：client-go/tools/cache/controller.go，代码如下：

func NewIndexerInformer(
   lw ListerWatcher,                 // 用于获取/监控需要Informer处理的资源
   objType runtime.Object,           // 订阅的对象类型
   resyncPeriod time.Duration,       // 非0时，将会一直list我们所关心的对象； 0时，‘重新list’将会被推迟
   h ResourceEventHandler,           // 用于处理与resources相关的事件
   indexers Indexers,
) (Indexer, Controller) {
   // This will hold the client state, as we know it.
   clientState := NewIndexer(DeletionHandlingMetaNamespaceKeyFunc, indexers)
  353
   return clientState, newInformer(lw, objType, resyncPeriod, h, clientState)
}

ResourceEventHandler的定义如下。其代码位置: client-go/tools/cache/controller.go。这里的Evnet只是具有通知的作用，因为，我们不应该对这里收到的对象进行任何修改。

type ResourceEventHandler interface {
   OnAdd(obj interface{})                  // 当有新的对象被创建时，将会调用这个函数
   OnUpdate(oldObj, newObj interface{})    // 当对象被修改时，将会调用这个函数。除此之外，当有`re-list`操作时，这个函数也会被再次调用
   OnDelete(obj interface{})               // 当对象被删除时，将会调用这个函数。
}

2. Informer简介

一句话背景介绍：为了减少当多个控制器对k8s-api-server进行大量访问时对api-server造成压力。

2.1 产生的背景

随着Controller越来越多，如果Controller直接访问k8s-apiserver，那么将会导致其压力过大，于是在这样的背景下就有了Informer的概念。其发展到今天这个架构，大概可以总结出以下迭代思路：

第一阶段，Controller直接访问k8s-api-server。存在的问题：多个控制器大量访问k8s-apiserver时会对其造成巨大的压力。

第二阶段，Informer代替Controller去访问k8s-apiserver。而Controller的所有操作操作(如：查状态、对资源进行伸缩等）都和Informer进行交互。但Informer没有必要每次都去访问k8s-apiserver，它只要在需要的时候通过ListAndWatch(即通过k8s List API获取所有资源的最新状态；通过Wath API去监听这些资源状态的变化)与k8s-apiserver交互即可。

ListAndWatch的代码位置: client-go/tools/cache/reflector.go

func (r *Reflector) ListAndWatch(stopCh <-chan struct{}) error{ … }

第三阶段， Informer并没有直接访问k8s-api-server，而是通过一个叫Reflector的对象进行api-server的访问。上面所说的 ListAndWatch 事实上是由Reflector`实现的。

第四阶段, 通过指定资源类型来Watch特定资源。

// 代码位置: client-go/tools/cache/listwatch.go
// Watcher is any object that knows how to start a watch on a resource.
type Watcher interface {
   // Watch should begin a watch at the specified version.
   Watch(options metav1.ListOptions) (watch.Interface, error)
}

第五阶段，定义SharedInformer。如果Controller与Informer是一一对应的关系，那么k8s-api-server的压力也还是挺大的。但是类似于Pod这样的资源来说，Deployment和StatefulSet都能对它进行管理，当多个控制器同时想查Pod的状态时，实现上，只需要有一个Informer就能满足需求了，即: SharedInformered。

第六阶段，解决多个不同的控制器排除与重试问题，引入DeltaFIFOQueue。每当资源被修改时，Reflector就会收到事件通知，并将对应的事件放入DeltaFIFOQueue中。另外，SharedInformer会不断从DeltaFIFOQueue中读取事件并更新本地缓存(ThreadSafeStore)的状态。

2.2 主要功能

通过List()/Get()（代码位置：client-go/tools/cache/listwatch.go）获取资源对象
监听事件(OnAdd, OnUpdate, OnDelete)，并触发回调(ResourceEventHandler)
支持二级缓存(DeltaFIFOQueue和ThreadSafeStore，前者用于存储Watch返回的事件，后者是一个LocalStore，能够被Lister的List()和Getter的Get()方法访问)

需要注意的是，Informer与k8s-apiserver之间没有同步机制，但是Informer内部的二级缓存之间是有同步机制的。

上面提到的List()/Get()的定义位于：client-go/tools/cache/listwatch.go

// Lister is any object that knows how to perform an initial list.
type Lister interface {
   // List should return a list type object; the Items field will be extracted, and the
   // ResourceVersion field will be used to start the watch in the right place.
   List(options metav1.ListOptions) (runtime.Object, error)
}
... 
// Getter interface knows how to access Get method from RESTClient.
type Getter interface {
   Get() *restclient.Request
}

2.3 主要模块

Reflector
DeltaFIFO
ThreadSafeStore（LocalStore）
Controller
Lister
Processor

需要注意的是：

这里提到的Controller不是Kubernetes Controller（前几篇文章中我们实际上已经提到过，再次重审一下，这两个Controller并没有任何联系）

Reflector主要用于监听与指定资源类型相关的事件

DeltaFIFO和ThreadSafeStore（LocalStore）是Informer的二级缓存

Lister主要是被调用List/Get方法

Processor中记录了所有的回调函数（即 ResourceEventHandler）的实例，并负责触发之

2.4 类图

出处

2.5 SharedInformer实现机制

当同一个资源(如：pdod)的Informer被实例化多次后，将会产生多个Reflector，如果这些Reflector都去调用ListAndWatch来获取资源时，将会对k8s-apiserver造成巨大的压力。

SharedInformer的意思是指：对于属于同一类型的资源来说，他们将会共享同一个Informer和Reflector，其实现代码如下：

// 代码位置: client-go/informers/factory.go
type sharedInformerFactory struct {
   client           kubernetes.Interface
   namespace        string
   tweakListOptions internalinterfaces.TweakListOptionsFunc
   lock             sync.Mutex
   defaultResync    time.Duration
   customResync     map[reflect.Type]time.Duration
62
   informers map[reflect.Type]cache.SharedIndexInformer     // sharedInformer的数据都存放在这个map中。
   // startedInformers is used for tracking which informers have been started.
   // This allows Start() to be called multiple times safely.
   startedInformers map[reflect.Type]bool
}

2.6 不同资源的Informer定义

对于不同的资源(如：pods, deployments, …)都有一个与之相对应的xxxInformer存在，他们的位置为(以pod为例):

// 代码位置：clent-go/informers/core/v1/pod.go
// PodInformer 提供了与pod相关的shared informer及lister进行交互的途径 
// 每个k8s resource都会有这样一个Informer，且Informer中都有以下两个方法：Informer(), Lister()
type PodInformer interface {
   Informer() cache.SharedIndexInformer
   Lister() v1.PodLister
}
   41
type podInformer struct {
   factory          internalinterfaces.SharedInformerFactory
   tweakListOptions internalinterfaces.TweakListOptionsFunc
   namespace        string
}

调用不同资源的Informer的使用示例如下：

deployInformer = sharedInformer.
               apps().              // client-go/informers/apps
               V1().                // client-go/informers/apps/v1
               Deployments().       // client-go/informers/apps/v1/deployment.go
               Informer()           // client-go/informers/apps/v1/deployment.go: type DeploymentInformer interface{}

3. Controller

3.1 Controller定义

代码位置: client-go/tools/cache/controller.go

// 这是一个Base Controller, 是其它所有控制器的`基类`。在`SharedInformer`中将会被用到。
// 
type Controller interface {
    // Run 只做两件事情：
   // 1. 构建并启动一个`Reflector`。把从`Config.ListerWatcher`中抛出的对象或通知发送到`Config.Queue`中，另外也可能会触发队列同步`Resync`
   // 2. 不断的从queue中弹出item，并使用Config.ProcessFunc进行处理。
   // 
   // 当channel `stopCh`被关闭时，上面两个操作会停止。
   Run(stopCh <-chan struct{})
106
   // HasSynced Config的队列是否已经同步过了
   HasSynced() bool
109
   // LastSyncResourceVersion delegates to the Reflector when there
   // is one, otherwise returns the empty string
   LastSyncResourceVersion() string
}

Controller的具体实现如下：

type controller struct {
   config         Config
   reflector      *Reflector
   reflectorMutex sync.RWMutex
   clock          clock.Clock
}

从上面的实现中，我们可以看到，一个Controller实际上是一个以Config为参数，并将会被Informer使用到的一个low-level的控制器。

3.2 Controller关键方法

// 代码位置: client-go/tools/cache/controller.go
// Run 开始处理items，当stopCh被关闭或stopCh收到某个值是将会停止执行。
func (c *controller) Run(stopCh <-chan struct{}) {
   defer utilruntime.HandleCrash()
   go func() {
       <-stopCh
       c.config.Queue.Close()
   }()
   r := NewReflector(             // 创建一个Reflector， 用于ListAndWatch， 从而获取指定资源的当前状态
       c.config.ListerWatcher,    // List/Watch指定的资源对象
       c.config.ObjectType,
       c.config.Queue,
       c.config.FullResyncPeriod,
   )
   r.ShouldResync = c.config.ShouldResync
   r.WatchListPageSize = c.config.WatchListPageSize
   r.clock = c.clock
   if c.config.WatchErrorHandler != nil {
       r.watchErrorHandler = c.config.WatchErrorHandler
   }
145
   c.reflectorMutex.Lock()
   c.reflector = r
   c.reflectorMutex.Unlock()
149
   var wg wait.Group
151
   wg.StartWithChannel(stopCh, r.Run) // r.Run中的最主要的方法就是执行Reflector的ListAndWatch()获取资源对象的值
   // c.ProcessLoop(client-go/tools/cache/controller.go)会从queue中取出资源Delta并进行处理
   wait.Until(c.processLoop, time.Second, stopCh)
   wg.Wait()
}

c.processLoop的实现如下：

func (c *controller) processLoop() {
   for {
       obj, err := c.config.Queue.Pop(PopProcessFunc(c.config.Process))
       if err != nil {
           if err == ErrFIFOClosed {
               return
           }
           if c.config.RetryOnError {
               // This is the safe way to re-enqueue.
               c.config.Queue.AddIfNotPresent(obj)  // Queue是一个DeltaFIFO
           }
       }
   }
}

3.3 Controller小结

有一个FIFO Queue的索引
有一个ListWatcher的索引
通过Pop从FIFO queue中消费资源对象(即: items)
创建Reflector
提供一个proccessLoop处理资源对象以达到期望的状态

另外需要注意的是，不要把tools/cache/controller.go中的Controller与Cumstom Controller混为一谈，两者是完全不同的两个东西。

3.4 Controller示例

前面从“理论”方面对Controller/Informer做了简单的介绍，俗话说的好“纸上得来终觉浅，绝知此事要耕行”，建议学完上面的理论后，还是结合下面例子在实践中再体会一下。

Controller的工作流程：请参考: client-go/tools/cache/controller_test.go: Example()

欢迎关注我的微信公众号：

kubernetes内部机制

2020-11-08T00:00:00+00:00

摘要：kubernetes内部机制简介。

1. 写在前面

个人主页: https://gzh.readthedocs.io

关注容器技术、关注Kubernetes。

问题或建议，请公众号（double12gzh）留言。

Kubernetes是一个容器编排引擎，设计用于在一组节点（通常称为集群）上托管容器化应用。使用系统建模方法，本系列旨在推进对Kubernetes及其基础概念的理解。对于本篇博文，建议您需要提前对Kubernetes、Kubernetes对象和Kubernetes控制器有所理解。

Kubernetes的特点是声明式容器编排引擎：在声明式系统中，用户向系统提供系统的期望状态的表示。然后，系统考虑当前状态和期望状态，确定从当前状态过渡到期望状态的需要执行哪些命令序列。因此，”声明式系统 “这个术语激发了一个经过计算的、具有明确目的的协调工作的概念，其最终目的是以便从当前状态过渡到期望状态。

然而，这不是Kubernetes的实际工作方式!

Kubernetes并没有根据当前状态和期望状态确定一个经过计算、协调的命令执行序列。相反，Kubernetes仅根据当前状态迭代确定下一个要执行的命令。如果以及无法确定下一条命令时，Kubernetes就达到了稳定状态。

2. 状态转换机制

本段概述了Kubernetes的状态转换语义的抽象模型。接下来的段落概述了一个基于部署对象和部署控制器的具体示例。

fact {
    all k8s : K8s - last | let k8s' = k8s.next {
        some c : NextCommand[k8s] {
            command.source = k8s and command.target = k8s'
        }
    }
    NextCommand[k8s.last] = none
}

上述代码展示了Kubernetes的状态转换语义。给定下一个命令函数，系统将根据当前状态k8s确定下一个命令，将系统从当前状态k8s过渡到下一个状态k8s’。

上述代码中使用到的NextCommand()的实现逻辑如下：

fun NextCommand(k8s : K8s) : set Command {
  DeploymentController.NextCommand[k8s] +
  ReplicaSetController.NextCommand[k8s] +
  ...
}

从概念上讲，NextCommand函数是由每个Kubernetes控制器的NextCommand函数的组成。

pred Steady(k8s : K8s) { NextCommand[k8s] = none }

状态序列以一个状态k8s.last结束，对于这个状态，NextCommand函数没有产生下一条命令，这个状态通常称为稳态。

3. k8s对象

Kubernetes对象存储是一组Kubernetes对象。Kubernetes对象是一些有不同规格的数据记录，称为kind。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: gzh-deployment
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: mydemo
        image: busybox:latest

如上所示即为一种k8s对象。

4. k8s控制器

每个Kubernetes Controller都会为下一条命令产生输入，一个Controller被实现为一个连续的过程，它根据Kubernetes的当前状态产生后续的命令。

process Controller = "Deployment Controller"
begin
    ControlLoop:
      while TRUE do
        \* The Deployment Controller monitors Deployment Objects
        with d ∈ {d ∈ k8s: d.kind = "Deployment"} do
          \* 1. Enabling Condition
          if Cardinality({r \in k8s: r.kind = "ReplicaSet" ∧ match(d.spec.labelSelector, r.meta.labels)}) < 1 then
            \* Reconciling Command
            CREATE([kind |-> "ReplicaSet", spec |-> [replicas |-> d.spec.replicas, template |-> d.spec.template]]);
          end if;
          \* 2. Enabling Condition
          if Cardinality({r \in k8s: r.kind = "ReplicaSet" ∧ match(d.spec.labelSelector, r.meta.labels)}) > 1 then
            \* Reconciling Command
            with r ∈ {r \in k8s: r.kind = "ReplicaSet" ∧ match(d.spec.labelSelector, r.meta.labels)} do
               DELETE(r);
            end with;
          end if;
        end with;
      end while;
end process;

上述代码5说明了deployment控制器。控制器监控deployment对象，并对每个对象执行一组条件语句。

条件

如果匹配的ReplicaSet对象少于1个

命令然后，deployment控制器将产生一个创建 ReplicaSet 命令。
条件

如果有超过1个匹配的ReplicaSet对象。

命令然后，deployment控制器将发出删除 ReplicaSet 命令。

从Controller的角度来看，如果Controller的条件都没有启用，Kubernetes就处于稳定状态，也就是说，Controller不会产生任何命令。

5. 级联指令

控制器（可以）级联地相互启用:

给定k8s的状态，如果Kubernetes控制器C被启用，C将执行一个过渡到k8s’的命令。
给定k8s’的状态，如果启用了Kubernetes控制器C’，C’将执行一个过渡到k8s’‘的命令。

图2显示了用户向API服务器提交deployment对象后产生的命令级联。

6. k8s是一个声明式系统吗？

fact {
    all sys : Sys - last | let sys' = sys.next {
        some c : Command {
            command.source = sys and command.target = sys'
        }
    }
    Desired[sys.last]
}

上述代码定义了声明式系统的状态转换机制。给定一个期望状态谓词，系统将确定一个命令序列，使系统从当前状态k8s.first过渡到期望状态k8s.last。

如果我们不把Kubernetes对象解释为事实的记录，而是解释为意图的记录，那么我们就可以认同Kubernetes是一个声明式系统的概念。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: gzh-deployment
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: mydemo
      image: busybox:latest

例如，我们可以将代码中的deployment对象解释为存在一组3个副本对象的意图，因此对象的

.spec.container[0].image等于busyBox:latest

然而，这一概念并非没有微妙之处：如果将一个对象解释为意图记录，则会出现多个选项。例如，Deployment Object 可以解释为：

应有一个 ReplicaSet 或
有一些pods

根据解释，当前状态可能与所需状态相匹配，也可能不相匹配:

如果有ReplicaSet和可选的Pods或
如果有一个ReplicaSet，并且必须有一组Pods

与我们的解释无关

如果有ReplicaSet对象，K8s与部署对象的关系处于稳定状态（deployment控制器不会产生Commands）。
如果有一组pod对象，K8s与ReplicaSet对象的关系处于稳定状态（ReplicaSet控制器不会产生命令）。

7. 结论

Kubernetes可能被描述为一个声明式系统，而Kubernetes对象可能被描述为意向记录。然而，当你推理Kubernetes和Kubernetes的行为时，你应该记住，Kubernetes不会做出协调的努力来过渡到所需的状态。相反，Kubernetes会做出持续的、不协调的努力来过渡到稳定状态。

欢迎关注我的微信公众号：

double12gzh - Posts in Kubernetes

如何使用client-go访问k8s crd

1. 写在前面

2. 写作动机

3. 定义CR(Custom Resource)

4. 创建golang client

4.1 定义类型

4.2 定义DeepCopy方法

4.3 注册类型

4.4 创建HTTP Client

4.5 生成Informer

5. 总结

在windows上通过wsl来部署k8s

1. 写在前面

2. 前提条件

3. WSL2：首次接触

3.1 (可选)设置``sudoers``

3.2 更新Ubuntu

4. Docker Desktop

4.1 设置docker desktop：开启对WSL2的支持

5. Kind: 让k8s方便的运行在容器中

5.1 创建单节点的集群

5.2 创建多节点的集群

5.3 查看k8s Dashboard

6. minikube: 让k8s可任意部署

6.1 更新Host

6.2 启用systemd

6.3 创建集群

6.4 访问dashboard

7. 结论

8. 出处

使用GitOps管理K8S Secret

1. 写在前面

2. 管理Secret比较好的方式

3. 结构

3.1 目录结构

3.2 Scaling

4. 设置SOPS

4.1 设置AWS

4.2 AWS实例配置文件

4.3 设置Flux

5. 小结

client-go系列之1—client-go代码详解

1. 写在前面

2. 代码结构

3. 代码使用简单示例

3.1 获取kubeconfig及context

3.2 创建ClientSet

3.3 使用ClientSet获取集群中的pods

3.4 使用ClientSet获取指定的pod

4. 各种Clients详解

5. 其它组件

5.1 Reflector

5.2 Informer

5.3 Indexer

5.4 WorkQueue

client-go系列之2—管理kubeconfig

1. 写在前面

2. 集群配置管理

2.1 加载配置文件

2.2 合并配置文件

client-go系列之3—restclient的使用

0. 背景

1. 环境准备

2. RestClient使用示例

3. 输出结果

client-go系列之4—Indexer

1. 写在前面

2. Custom Controller中的组件

2.1 Indexer

2.1.1 简单介绍

2.1.2 代码位置

2.1.3 类图展示

2.2 Indexer索引器实现

client-go系列之5—Informer

1. 写在前面

2. Informer简介

2.1 产生的背景

2.2 主要功能

2.3 主要模块

6.2 启用`systemd`