（转）Kubernetes Operator 快速入门教程

时间  2019-11-29
标签 kubernetes operator 快速 入门 教程 繁體版
原文   原文链接

https://www.qikqiak.com/post/k8s-operator-101/html

在 Kubernetes 的监控方案中咱们常常会使用到一个Promethues Operator的项目，该项目可让咱们更加方便的去使用 Prometheus，而不须要直接去使用最原始的一些资源对象，好比 Pod、Deployment，随着 Prometheus Operator 项目的成功，CoreOS 公司开源了一个比较厉害的工具：Operator Framework，该工具可让开发人员更加容易的开发 Operator 应用。node

在本篇文章中咱们会为你们介绍一个简单示例来演示如何使用 Operator Framework 框架来开发一个 Operator 应用。nginx

Kubernetes Operator
Operator 是由 CoreOS 开发的，用来扩展 Kubernetes API，特定的应用程序控制器，它用来建立、配置和管理复杂的有状态应用，如数据库、缓存和监控系统。Operator 基于 Kubernetes 的资源和控制器概念之上构建，但同时又包含了应用程序特定的领域知识。建立Operator 的关键是CRD（自定义资源）的设计。git

Kubernetes 1.7 版本以来就引入了自定义控制器的概念，该功能可让开发人员扩展添加新功能，更新现有的功能，而且能够自动执行一些管理任务，这些自定义的控制器就像 Kubernetes 原生的组件同样，Operator 直接使用 Kubernetes API进行开发，也就是说他们能够根据这些控制器内部编写的自定义规则来监控集群、更改 Pods/Services、对正在运行的应用进行扩缩容。github

Operator Framework
Operator Framework 一样也是 CoreOS 开源的一个用于快速开发 Operator 的工具包，该框架包含两个主要的部分：golang

Operator SDK: 无需了解复杂的 Kubernetes API 特性，便可让你根据你本身的专业知识构建一个 Operator 应用。
Operator Lifecycle Manager OLM: 帮助你安装、更新和管理跨集群的运行中的全部 Operator（以及他们的相关服务）
operator sdk
operator sdk
Workflow
Operator SDK 提供如下工做流来开发一个新的 Operator：docker

  1. 使用 SDK 建立一个新的 Operator 项目
  2. 经过添加自定义资源（CRD）定义新的资源 API
  3. 指定使用 SDK API 来 watch 的资源
  4. 定义 Operator 的协调（reconcile）逻辑
  5. 使用 Operator SDK 构建并生成 Operator 部署清单文件
    Demo
    咱们平时在部署一个简单的 Webserver 到 Kubernetes 集群中的时候，都须要先编写一个 Deployment 的控制器，而后建立一个 Service 对象，经过 Pod 的 label 标签进行关联，最后经过 Ingress 或者 type=NodePort 类型的 Service 来暴露服务，每次都须要这样操做，是否是略显麻烦，咱们就能够建立一个自定义的资源对象，经过咱们的 CRD 来描述咱们要部署的应用信息，好比镜像、服务端口、环境变量等等，而后建立咱们的自定义类型的资源对象的时候，经过控制器去建立对应的 Deployment 和 Service，是否是就方便不少了，至关于咱们用一个资源清单去描述了 Deployment 和 Service 要作的两件事情。

这里咱们将建立一个名为 AppService 的 CRD 资源对象，而后定义以下的资源清单进行应用部署：数据库

apiVersion: app.example.com/v1
kind: AppService
metadata:
name: nginx-app
spec:
size: 2
image: nginx:1.7.9
ports:
- port: 80
targetPort: 80
nodePort: 30002
经过这里的自定义的 AppService 资源对象去建立副本数为2的 Pod，而后经过 nodePort=30002 的端口去暴露服务，接下来咱们就来一步一步的实现咱们这里的这个简单的 Operator 应用。json

开发环境
环境需求
要开发 Operator 天然 Kubernetes 集群是少不了的，还须要 Golang 的环境，这里的安装就很少说了，而后还须要一个 Go 语言的依赖管理工具包：dep，因为 Operator SDK 是使用的 dep 该工具包，因此须要咱们提早安装好，能够查看资料：https://github.com/golang/dep，另一个须要说明的是，因为 dep 去安装的时候须要去谷歌的网站拉取不少代码，因此正常状况下的话是会失败的，须要作什么工做你们应该清楚吧？要科学。api

安装 operator-sdk
operator sdk 安装方法很是多，咱们能够直接在 github 上面下载须要使用的版本，而后放置到 PATH 环境下面便可，固然也能够将源码 clone 到本地手动编译安装便可，若是你是 Mac，固然还可使用经常使用的 brew 工具进行安装：

$ brew install operator-sdk
......
$ operator-sdk version
operator-sdk version: v0.7.0
$ go version
go version go1.11.4 darwin/amd64
咱们这里使用的 sdk 版本是v0.7.0，其余安装方法能够参考文档：https://github.com/operator-framework/operator-sdk/blob/master/doc/user/install-operator-sdk.md

演示
建立新项目
环境准备好了，接下来就可使用 operator-sdk 直接建立一个新的项目了，命令格式为： operator-sdk new

按照上面咱们预先定义的 CRD 资源清单，咱们这里能够这样建立：

建立项目目录

$ mkdir -p operator-learning

设置项目目录为 GOPATH 路径

$ cd operator-learning && export GOPATH=$PWD
$ mkdir -p $GOPATH/src/github.com/cnych
$ cd $GOPATH/src/github.com/cnych

使用 sdk 建立一个名为 opdemo 的 operator 项目

$ operator-sdk new opdemo
......

该过程须要，须要花费很长时间，请耐心等待

......
$ cd opdemo && tree -L 2
.
├── Gopkg.lock
├── Gopkg.toml
├── build
│ ├── Dockerfile
│ ├── _output
│ └── bin
├── cmd
│ └── manager
├── deploy
│ ├── crds
│ ├── operator.yaml
│ ├── role.yaml
│ ├── role_binding.yaml
│ └── service_account.yaml
├── pkg
│ ├── apis
│ └── controller
├── vendor
│ ├── cloud.google.com
│ ├── contrib.go.opencensus.io
│ ├── github.com
│ ├── go.opencensus.io
│ ├── go.uber.org
│ ├── golang.org
│ ├── google.golang.org
│ ├── gopkg.in
│ ├── k8s.io
│ └── sigs.k8s.io
└── version
└── version.go

23 directories, 8 files
到这里一个全新的 Operator 项目就新建完成了。

项目结构
使用operator-sdk new命令建立新的 Operator 项目后，项目目录就包含了不少生成的文件夹和文件。

Gopkg.toml Gopkg.lock — Go Dep 清单，用来描述当前 Operator 的依赖包。
cmd - 包含 main.go 文件，使用 operator-sdk API 初始化和启动当前 Operator 的入口。
deploy - 包含一组用于在 Kubernetes 集群上进行部署的通用的 Kubernetes 资源清单文件。
pkg/apis - 包含定义的 API 和自定义资源（CRD）的目录树，这些文件容许 sdk 为 CRD 生成代码并注册对应的类型，以便正确解码自定义资源对象。
pkg/controller - 用于编写全部的操做业务逻辑的地方
vendor - golang vendor 文件夹，其中包含知足当前项目的全部外部依赖包，经过 go dep 管理该目录。
咱们主要须要编写的是pkg目录下面的 api 定义以及对应的 controller 实现。

添加 API
接下来为咱们的自定义资源添加一个新的 API，按照上面咱们预约义的资源清单文件，在 Operator 相关根目录下面执行以下命令：

$ operator-sdk add api --api-version=app.example.com/v1 --kind=AppService
添加完成后，咱们能够看到相似于下面的这样项目结构： operator project layout

添加控制器
上面咱们添加自定义的 API，接下来能够添加对应的自定义 API 的具体实现 Controller，一样在项目根目录下面执行以下命令：

$ operator-sdk add controller --api-version=app.example.com/v1 --kind=AppService
这样整个 Operator 项目的脚手架就已经搭建完成了，接下来就是具体的实现了。

自定义 API
打开源文件pkg/apis/app/v1/appservice_types.go，须要咱们根据咱们的需求去自定义结构体 AppServiceSpec，咱们最上面预约义的资源清单中就有 size、image、ports 这些属性，全部咱们须要用到的属性都须要在这个结构体中进行定义：

type AppServiceSpec struct {
// INSERT ADDITIONAL SPEC FIELDS - desired state of cluster
// Important: Run "operator-sdk generate k8s" to regenerate code after modifying this file
// Add custom validation using kubebuilder tags: https://book.kubebuilder.io/beyond_basics/generating_crd.html
Size *int32 json:"size"
Image string json:"image"
Resources corev1.ResourceRequirements json:"resources,omitempty"
Envs []corev1.EnvVar json:"envs,omitempty"
Ports []corev1.ServicePort json:"ports,omitempty"
}
代码中会涉及到一些包名的导入，因为包名较多，因此咱们会使用一些别名进行区分，主要的包含下面几个：

import (
appsv1 "k8s.io/api/apps/v1"
corev1 "k8s.io/api/core/v1"
appv1 "github.com/cnych/opdemo/pkg/apis/app/v1"
metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
)
这里的 resources、envs、ports 的定义都是直接引用的"k8s.io/api/core/v1"中定义的结构体，并且须要注意的是咱们这里使用的是ServicePort，而不是像传统的 Pod 中定义的 ContanerPort，这是由于咱们的资源清单中不只要描述容器的 Port，还要描述 Service 的 Port。

而后一个比较重要的结构体AppServiceStatus用来描述资源的状态，固然咱们能够根据须要去自定义状态的描述，我这里就偷懒直接使用 Deployment 的状态了：

type AppServiceStatus struct {
// INSERT ADDITIONAL STATUS FIELD - define observed state of cluster
// Important: Run "operator-sdk generate k8s" to regenerate code after modifying this file
// Add custom validation using kubebuilder tags: https://book.kubebuilder.io/beyond_basics/generating_crd.html
appsv1.DeploymentStatus json:",inline"
}
定义完成后，在项目根目录下面执行以下命令：

$ operator-sdk generate k8s
改命令是用来根据咱们自定义的 API 描述来自动生成一些代码，目录pkg/apis/app/v1/下面以zz_generated开头的文件就是自动生成的代码，里面的内容并不须要咱们去手动编写。

这样咱们就算完成了对自定义资源对象的 API 的声明。

实现业务逻辑
上面 API 描述声明完成了，接下来就须要咱们来进行具体的业务逻辑实现了，编写具体的 controller 实现，打开源文件pkg/controller/appservice/appservice_controller.go，须要咱们去更改的地方也不是不少，核心的就是Reconcile方法，该方法就是去不断的 watch 资源的状态，而后根据状态的不一样去实现各类操做逻辑，核心代码以下：

func (r *ReconcileAppService) Reconcile(request reconcile.Request) (reconcile.Result, error) {
reqLogger := log.WithValues("Request.Namespace", request.Namespace, "Request.Name", request.Name)
reqLogger.Info("Reconciling AppService")

// Fetch the AppService instance
instance := &appv1.AppService{}
err := r.client.Get(context.TODO(), request.NamespacedName, instance)
if err != nil {
    if errors.IsNotFound(err) {
        // Request object not found, could have been deleted after reconcile request.
        // Owned objects are automatically garbage collected. For additional cleanup logic use finalizers.
        // Return and don't requeue
        return reconcile.Result{}, nil
    }
    // Error reading the object - requeue the request.
    return reconcile.Result{}, err
}

if instance.DeletionTimestamp != nil {
    return reconcile.Result{}, err
}

// 若是不存在，则建立关联资源
// 若是存在，判断是否须要更新
//   若是须要更新，则直接更新
//   若是不须要更新，则正常返回

deploy := &appsv1.Deployment{}
if err := r.client.Get(context.TODO(), request.NamespacedName, deploy); err != nil && errors.IsNotFound(err) {
    // 建立关联资源
    // 1. 建立 Deploy
    deploy := resources.NewDeploy(instance)
    if err := r.client.Create(context.TODO(), deploy); err != nil {
        return reconcile.Result{}, err
    }
    // 2. 建立 Service
    service := resources.NewService(instance)
    if err := r.client.Create(context.TODO(), service); err != nil {
        return reconcile.Result{}, err
    }
    // 3. 关联 Annotations
    data, _ := json.Marshal(instance.Spec)
    if instance.Annotations != nil {
        instance.Annotations["spec"] = string(data)
    } else {
        instance.Annotations = map[string]string{"spec": string(data)}
    }

    if err := r.client.Update(context.TODO(), instance); err != nil {
        return reconcile.Result{}, nil
    }
    return reconcile.Result{}, nil
}

oldspec := appv1.AppServiceSpec{}
if err := json.Unmarshal([]byte(instance.Annotations["spec"]), oldspec); err != nil {
    return reconcile.Result{}, err
}

if !reflect.DeepEqual(instance.Spec, oldspec) {
    // 更新关联资源
    newDeploy := resources.NewDeploy(instance)
    oldDeploy := &appsv1.Deployment{}
    if err := r.client.Get(context.TODO(), request.NamespacedName, oldDeploy); err != nil {
        return reconcile.Result{}, err
    }
    oldDeploy.Spec = newDeploy.Spec
    if err := r.client.Update(context.TODO(), oldDeploy); err != nil {
        return reconcile.Result{}, err
    }

    newService := resources.NewService(instance)
    oldService := &corev1.Service{}
    if err := r.client.Get(context.TODO(), request.NamespacedName, oldService); err != nil {
        return reconcile.Result{}, err
    }
    oldService.Spec = newService.Spec
    if err := r.client.Update(context.TODO(), oldService); err != nil {
        return reconcile.Result{}, err
    }

    return reconcile.Result{}, nil
}

return reconcile.Result{}, nil

}
上面就是业务逻辑实现的核心代码，逻辑很简单，就是去判断资源是否存在，不存在，则直接建立新的资源，建立新的资源除了须要建立 Deployment 资源外，还须要建立 Service 资源对象，由于这就是咱们的需求，固然你还能够本身去扩展，好比在建立一个 Ingress 对象。更新也是同样的，去对比新旧对象的声明是否一致，不一致则须要更新，一样的，两种资源都须要更新的。

另外两个核心的方法就是上面的resources.NewDeploy(instance)和resources.NewService(instance)方法，这两个方法实现逻辑也很简单，就是根据 CRD 中的声明去填充 Deployment 和 Service 资源对象的 Spec 对象便可。

NewDeploy 方法实现以下：

func NewDeploy(app appv1.AppService) appsv1.Deployment {
labels := map[string]string{"app": app.Name}
selector := &metav1.LabelSelector{MatchLabels: labels}
return &appsv1.Deployment{
TypeMeta: metav1.TypeMeta{
APIVersion: "apps/v1",
Kind: "Deployment",
},
ObjectMeta: metav1.ObjectMeta{
Name: app.Name,
Namespace: app.Namespace,

OwnerReferences: []metav1.OwnerReference{
            *metav1.NewControllerRef(app, schema.GroupVersionKind{
                Group: v1.SchemeGroupVersion.Group,
                Version: v1.SchemeGroupVersion.Version,
                Kind: "AppService",
            }),
        },
    },
    Spec: appsv1.DeploymentSpec{
        Replicas: app.Spec.Size,
        Template: corev1.PodTemplateSpec{
            ObjectMeta: metav1.ObjectMeta{
                Labels: labels,
            },
            Spec: corev1.PodSpec{
                Containers: newContainers(app),
            },
        },
        Selector: selector,
    },
}

}

func newContainers(app *v1.AppService) []corev1.Container {
containerPorts := []corev1.ContainerPort{}
for _, svcPort := range app.Spec.Ports {
cport := corev1.ContainerPort{}
cport.ContainerPort = svcPort.TargetPort.IntVal
containerPorts = append(containerPorts, cport)
}
return []corev1.Container{
{
Name: app.Name,
Image: app.Spec.Image,
Resources: app.Spec.Resources,
Ports: containerPorts,
ImagePullPolicy: corev1.PullIfNotPresent,
Env: app.Spec.Envs,
},
}
}
newService 对应的方法实现以下：

func NewService(app v1.AppService) corev1.Service {
return &corev1.Service {
TypeMeta: metav1.TypeMeta {
Kind: "Service",
APIVersion: "v1",
},
ObjectMeta: metav1.ObjectMeta{
Name: app.Name,
Namespace: app.Namespace,
OwnerReferences: []metav1.OwnerReference{
*metav1.NewControllerRef(app, schema.GroupVersionKind{
Group: v1.SchemeGroupVersion.Group,
Version: v1.SchemeGroupVersion.Version,
Kind: "AppService",
}),
},
},
Spec: corev1.ServiceSpec{
Type: corev1.ServiceTypeNodePort,
Ports: app.Spec.Ports,
Selector: map[string]string{
"app": app.Name,
},
},
}
}
这样咱们就实现了 AppService 这种资源对象的业务逻辑。

调试
若是咱们本地有一个能够访问的 Kubernetes 集群，咱们也能够直接进行调试，在本地用户~/.kube/config文件中配置集群访问信息，下面的信息代表能够访问 Kubernetes 集群：

$ kubectl cluster-info
Kubernetes master is running at https://ydzs-master:6443
KubeDNS is running at https://ydzs-master:6443/api/v1/namespaces/kube-system/services/kube-dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
首先，在集群中安装 CRD 对象：

$ kubectl create -f deploy/crds/app_v1_appservice_crd.yaml
customresourcedefinition "appservices.app.example.com" created
$ kubectl get crd
NAME AGE
appservices.app.example.com
......
当咱们经过kubectl get crd命令获取到咱们定义的 CRD 资源对象，就证实咱们定义的 CRD 安装成功了。其实如今只是 CRD 的这个声明安装成功了，可是咱们这个 CRD 的具体业务逻辑实现方式还在咱们本地，并无部署到集群之中，咱们能够经过下面的命令来在本地项目中启动 Operator 的调试：

$ operator-sdk up local
INFO[0000] Running the operator locally.
INFO[0000] Using namespace default.
{"level":"info","ts":1559207203.964137,"logger":"cmd","msg":"Go Version: go1.11.4"}
{"level":"info","ts":1559207203.964192,"logger":"cmd","msg":"Go OS/Arch: darwin/amd64"}
{"level":"info","ts":1559207203.9641972,"logger":"cmd","msg":"Version of operator-sdk: v0.7.0"}
{"level":"info","ts":1559207203.965905,"logger":"leader","msg":"Trying to become the leader."}
{"level":"info","ts":1559207203.965945,"logger":"leader","msg":"Skipping leader election; not running in a cluster."}
{"level":"info","ts":1559207206.928867,"logger":"cmd","msg":"Registering Components."}
{"level":"info","ts":1559207206.929077,"logger":"kubebuilder.controller","msg":"Starting EventSource","controller":"appservice-controller","source":"kind source: /, Kind="}
{"level":"info","ts":1559207206.9292521,"logger":"kubebuilder.controller","msg":"Starting EventSource","controller":"appservice-controller","source":"kind source: /, Kind="}
{"level":"info","ts":1559207209.622659,"logger":"cmd","msg":"failed to initialize service object for metrics: OPERATOR_NAME must be set"}
{"level":"info","ts":1559207209.622693,"logger":"cmd","msg":"Starting the Cmd."}
{"level":"info","ts":1559207209.7236018,"logger":"kubebuilder.controller","msg":"Starting Controller","controller":"appservice-controller"}
{"level":"info","ts":1559207209.8284118,"logger":"kubebuilder.controller","msg":"Starting workers","controller":"appservice-controller","worker count":1}
上面的命令会在本地运行 Operator 应用，经过~/.kube/config去关联集群信息，如今咱们去添加一个 AppService 类型的资源而后观察本地 Operator 的变化状况，资源清单文件就是咱们上面预约义的（deploy/crds/app_v1_appservice_cr.yaml）

apiVersion: app.example.com/v1
kind: AppService
metadata:
name: nginx-app
spec:
size: 2
image: nginx:1.7.9
ports:
- port: 80
targetPort: 80
nodePort: 30002
直接建立这个资源对象：

$ kubectl create -f deploy/crds/app_v1_appservice_cr.yaml
appservice "nginx-app" created
咱们能够看到咱们的应用建立成功了，这个时候查看 Operator 的调试窗口会有以下的信息出现：

......
{"level":"info","ts":1559207416.670523,"logger":"controller_appservice","msg":"Reconciling AppService","Request.Namespace":"default","Request.Name":"nginx-app"}
{"level":"info","ts":1559207417.004226,"logger":"controller_appservice","msg":"Reconciling AppService","Request.Namespace":"default","Request.Name":"nginx-app"}
{"level":"info","ts":1559207417.004331,"logger":"controller_appservice","msg":"Reconciling AppService","Request.Namespace":"default","Request.Name":"nginx-app"}
{"level":"info","ts":1559207418.33779,"logger":"controller_appservice","msg":"Reconciling AppService","Request.Namespace":"default","Request.Name":"nginx-app"}
{"level":"info","ts":1559207418.951193,"logger":"controller_appservice","msg":"Reconciling AppService","Request.Namespace":"default","Request.Name":"nginx-app"}
......
而后咱们能够去查看集群中是否有符合咱们预期的资源出现：

$ kubectl get AppService
NAME AGE
nginx-app
$ kubectl get deploy
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-app 2 2 2 2
$ kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 443/TCP 76d
nginx-app NodePort 10.108.227.5 80:30002/TCP
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-app-76b6449498-2j82j 1/1 Running 0
nginx-app-76b6449498-m4h58 1/1 Running 0
看到了吧，咱们定义了两个副本（size=2），这里就出现了两个 Pod，还有一个 NodePort=30002 的 Service 对象，咱们能够经过该端口去访问下应用： crd nginx app demo

若是应用在安装过程当中出现了任何问题，咱们均可以经过本地的 Operator 调试窗口找到有用的信息，而后调试修改便可。

清理：

$ kubectl delete -f deploy/crds/app_v1_appservice_crd.yaml
$ kubectl delete -f deploy/crds/app_v1_appservice_cr.yaml
部署
自定义的资源对象如今测试经过了，可是若是咱们将本地的operator-sdk up local命令终止掉，咱们能够猜测到就没办法处理 AppService 资源对象的一些操做了，因此咱们须要将咱们的业务逻辑实现部署到集群中去。

执行下面的命令构建 Operator 应用打包成 Docker 镜像：

$ operator-sdk build cnych/opdemo
INFO[0002] Building Docker image cnych/opdemo
Sending build context to Docker daemon 400.7MB
Step 1/7 : FROM registry.access.redhat.com/ubi7-dev-preview/ubi-minimal:7.6
......
Successfully built a8cde91be6ab
Successfully tagged cnych/opdemo:latest
INFO[0053] Operator build complete.
镜像构建成功后，推送到 docker hub：

$ docker push cnych/opdemo
镜像推送成功后，使用上面的镜像地址更新 Operator 的资源清单：

$ sed -i 's|REPLACE_IMAGE|cnych/opdemo|g' deploy/operator.yaml

若是你使用的是 Mac 系统，使用下面的命令

$ sed -i "" 's|REPLACE_IMAGE|cnych/opdemo|g' deploy/operator.yaml
如今 Operator 的资源清单文件准备好了，而后建立对应的 RBAC 的对象：

Setup Service Account

$ kubectl create -f deploy/service_account.yaml

Setup RBAC

$ kubectl create -f deploy/role.yaml
$ kubectl create -f deploy/role_binding.yaml
权限相关声明已经完成，接下来安装 CRD 和 Operator：

Setup the CRD

$ kubectl apply -f deploy/crds/app_v1_appservice_crd.yaml
$ kubectl get crd
NAME CREATED AT
appservices.app.example.com 2019-05-30T17:03:32Z
......

Deploy the Operator

$ kubectl create -f deploy/operator.yaml
deployment.apps/opdemo created
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
opdemo-64db96d575-9vtq6 1/1 Running 0 2m2s
到这里咱们的 CRD 和 Operator 实现都已经安装成功了。

如今咱们再来部署咱们的 AppService 资源清单文件，如今的业务逻辑就会在上面的opdemo-64db96d575-9vtq6的 Pod 中去处理了。

$ kubectl create -f deploy/crds/app_v1_appservice_cr.yaml
appservice.app.example.com/nginx-app created
$ kubectl get appservice
NAME AGE
nginx-app 18s
$ kubectl get deploy
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-app 2/2 2 2 24s
opdemo 1/1 1 1 5m51s
$ kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 443/TCP 76d
nginx-app NodePort 10.106.129.82 80:30002/TCP 29s
opdemo ClusterIP 10.100.233.51 8383/TCP 4m25s
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-app-76b6449498-ffhgx 1/1 Running 0 32s
nginx-app-76b6449498-wzjq2 1/1 Running 0 32s
opdemo-64db96d575-9vtq6 1/1 Running 0 5m59s
$ kubectl describe appservice nginx-app
Name: nginx-app
Namespace: default
Labels:
Annotations: spec: {"size":2,"image":"nginx:1.7.9","resources":{},"ports":[{"protocol":"TCP","port":80,"targetPort":80,"nodePort":30002}]}
API Version: app.example.com/v1
Kind: AppService
Metadata:
Creation Timestamp: 2019-05-30T17:41:28Z
Generation: 2
Resource Version: 19666617
Self Link: /apis/app.example.com/v1/namespaces/default/appservices/nginx-app
UID: 2756f232-8302-11e9-80ca-525400cc3c00
Spec:
Image: nginx:1.7.9
Ports:
Node Port: 30002
Port: 80
Protocol: TCP
Target Port: 80
Resources:
Size: 2
Events:
而后一样的能够经过 30002 这个 NodePort 端口去访问应用，到这里应用就部署成功了。

清理
有资源清单文件，直接删除便可：

$ kubectl delete -f deploy/crds/app_v1_appservice_cr.yaml
$ kubectl delete -f deploy/operator.yaml
$ kubectl delete -f deploy/role.yaml
$ kubectl delete -f deploy/role_binding.yaml
$ kubectl delete -f deploy/service_account.yaml
$ kubectl delete -f deploy/crds/app_v1_appservice_crd.yaml
开发
Operator SDK 为咱们建立了一个快速启动的代码和相关配置，若是咱们要开始处理相关的逻辑，咱们能够在项目中搜索TODO(user)这个注释来实现咱们本身的逻辑，好比在个人 VSCode 环境中，看上去是这样的： operator code todo demo

本篇文章示例代码地址：https://github.com/cnych/opdemo

参考资料 CLI reference User Guide Developing Kubernetes Operator is now easy with Operator Framework

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程