double12gzh - Posts by 大海星

goroutine切换背后那些事儿

2020-09-21T00:00:00+00:00

本文基于于GoLang 1.13。

1. 写在前面

微信公众号：[double12gzh]

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

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

Goroutine很轻量，从资源消耗方面来看，它只需要一个2Kb的内存栈就可以运行；从运行时来看，它的运行成本也很低，将一个goroutine切换到另一个goroutine并不需要很多操作。

在进行讲解golang的切换之前，我们先High Level的看一下goroutine切换的相关内容。

2. 案例

golang会根据两种断点将goroutine调度到线程上：

当一个goroutine阻塞了。如：系统调用，mutex，或者通道。被阻塞的goroutine会进入睡眠模式/队列，让Go调度并运行一个等待的goroutine。被阻塞的goroutine进入睡眠模式/队列，允许Go调度

System Message: WARNING/2 (/home/docs/checkouts/readthedocs.org/user_builds/gzh/checkouts/latest/blogs/GoLang/2020-09-21-goroutine发生切换时背后发生了什么.rst, line 36)

Bullet list ends without a blank line; unexpected unindent.

和运行一个等待的goroutine。

在函数调用过程中，假如goroutine必须增长它的栈。这个断点允许Go调度另一个goroutine，避免正在运行的那个goroutine占用CPU。

在这两种情况下，运行调度器的g0会用另一个准备运行的goroutine替换当前的goroutine。然后，被选中的goroutine取代g0，从而在线程上运行。

如果您想了解更多关于g0的内容，请参考g0

将一个运行中的goroutine切换到另一个运行中的goroutine涉及到两个切换。

g-> g0。

g0-> 另一个g。

在GoLang中，groutine真的非常轻量。为了保存，它只需要两个东西：

goroutine是在哪一行停止的。即：在被调度前，goroutine是在哪一行停止的，当前要运行的指令被记录在程序计数器（PC）中。goroutine稍后将在同一点恢复。
存放goroutine的堆栈。这个堆栈的目的是为了方便再次运行时恢复其局部变量。

下面我们深入看一下。

3. PC（程序记数器）

为了便于举例，我将使用一个通过channel进行通信的goroutine来说明，这两个goroutine中，一个可以产生数据的，其它的用于消费数据。代码如下：

main.go

 package main

 import (
     "fmt"
     "sync"
 )

 const COUNT = 100

 func main() {
     var wg sync.WaitGroup

     c := make(chan int, 10)

     wg.Add(1)

     // 生产数据
     go func() {
         for i := 0; i < COUNT; i++ {
             c <- i
         }

         close(c)
         wg.Done()
     }()

     // 消费数据
     for i := 0; i < 3; i++ {
         wg.Add(1)

         go func() {
             for v := range c {
                 if v%2 == 0 {
                     fmt.Println(v)
                 }
             }
         }()
     }

     wg.Wait()
 }

消费者基本上会打印0到99的偶数，我们将重点关注第一个goroutine–生产者–向缓冲区添加数字。当缓冲区满了，它将在发送消息时阻塞。此时，Go要切换到g0，调度另一个goroutine。

如前所述，Go首先需要保存当前指令，以便在同一指令处恢复goroutine。程序计数器(PC)保存在goroutine的内部结构中。

上面的代码可以使用以下图来简单说明：

指令和它们的地址可以通过命令获取：

➜  hello go tool compile -N -l main.go
➜  hello ls | grep main.o
main.o

下面是生产者的一个示例：

➜  hello go tool objdump main.o

在函数runtime.chansend1上阻塞通道前，程序逐条指令执行。Go将当前的程序计数器保存到当前goroutine的内部属性中。在我们的例子中，Go保存程序计数器的地址是0x4268d0，这个地址是在runtime和方法runtime.chansend1内部的。

然后，当g0唤醒goroutine时，它将在同一指令处恢复，对数值进行循环并推入通道。

下面我们来谈谈goroutine切换过程中的栈管理。

4. 栈(stack)

在被阻塞之前，正在运行的goroutine有它的原始栈。这个堆栈包含临时内存，比如变量i:

然后，当它在通道上阻塞时，goroutine将和它的堆栈一起切换到g0，这个goroutine将会有一个更大的栈。

在切换之前，堆栈将被保存，以便在goroutine再次运行时恢复。

我们现在已经完整地了解了goroutine切换中涉及的不同操作。现在让我们看看它是如何影响性能的。

我们应该注意到，一些架构(比如arm)需要多保存一个寄存器LR(链接寄存器)。

5. 操作

为了测量goroutine切换可能需要的时间，我们将使用前面写的程序。然而，它并不能给出一个完美的性能视图，因为它可能取决于找到下一个要调度的goroutine所需的时间。这样goroutine的切换也会影响性能，从函数prolog的切换比从通道上阻塞的goroutine切换要做的操作更多。

我们来总结一下我们要测量的操作：

当前的g在通道上阻塞并切换到g0:
- PC和堆栈指针一起被保存在一个内部结构中
- g0被设置为正在运行的goroutine。
- g0的堆栈取代了当前的堆栈。
g0正在寻找一个新的goroutine来运行。
g0必须与所选的goroutine进行切换。
- PC和堆栈指针被从内部结构中提取出来。
- 程序跳转到获取的PC地址。

如下图：

从g到g0或g0到g的切换是最快的阶段。它们包含少量固定的指令，这一点与调度器检查许多源以寻找下一个要运行的goroutine的情况相反。根据运行程序的情况，这个阶段甚至可能需要更多的时间。

需要说明的一点是，对于以上测试的结果会因机器架构的不同而不同

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

如何使用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 函数来提取所分发对象的键值并将其添加到工作队列中。

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

double12gzh - Posts by 大海星

goroutine切换背后那些事儿

1. 写在前面

2. 案例

3. PC（程序记数器）

4. 栈(stack)

5. 操作

如何使用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

6.2 启用`systemd`