带你读《云原生应用开发 Operator原理与实践》第一章引言1.2Operator 介绍(五)

简介: 带你读《云原生应用开发 Operator原理与实践》第一章引言1.2Operator 介绍

(4)  修改 Controller逻辑

Controller中需要通过Reconcile方法完成 DeploymentService 部署,并最终达到期望的状态。

Controller中的代码见代码清单 1-11,我们需要在其中加入业务逻辑。

// +kubebuilder:rbac:groups=webapp.demo.welcome.domain,resources=welcomes,ver-bs=get;list;watch;create;update;patch;delete

//+kubebuilder:rbac:groups=webapp.demo.welcome.domain,resources=welcomes/status,verbs=get;update;patch

 

//+kubebuilder:rbac:groups=apps,resources=deployments,verbs=list;watch;get;patch;create;update

//+kubebuilder:rbac:groups=core,resources=services,verbs=list;watch;get;patch;create;update

func(r*WelcomeReconciler)Reconcile(reqctrl.Request)(ctrl.Result,error){

ctx:=context.Background()

log:=r.Log.WithValues("welcome",req.NamespacedName)log.Info("reconcilingwelcome")

 

此处有两组+”标识,第一组用于Operator更新Welcome资源对象,第二组用于创DeploymentService。接下来完成 Welcome类型控制器的部分代码的实现代码清单1-12


deployment,err:=r.createWelcomeDeployment(welcome)iferr!=nil{

returnctrl.Result{},err

}

log.Info("createdeploymentsuccess!")

 

svc,err:=r.createService(welcome)iferr!=nil{

returnctrl.Result{},err

}

log.Info("createservicesuccess!")

applyOpts:=[]client.PatchOption{client.ForceOwnership,client.

FieldOwner("welcome_controller")}

err=r.Patch(ctx,&deployment,client.Apply,applyOpts...)


iferr!=nil{

returnctrl.Result{},err

}

 

err=r.Patch(ctx,&svc,client.Apply,applyOpts...)iferr!=nil{

returnctrl.Result{},err

}

在控制器部分需要完成 DeploymentService 的创建,并完成两者的关联,在上述代码中,我们分别通过调用createWelcomeDeploymentcreateService方法完成对象的创建,接下来我们完成上述方法的具体实现(见代码清单1-13

func(r*WelcomeReconciler)createWelcomeDeployment(welcomewebappv1.Welcome)(appsv1.Deployment,error){

defOne:=int32(1)

name:=welcome.Spec.Nameifname==""{

name="world"

}

depl:=appsv1.Deployment{

TypeMeta:metav1.TypeMeta{APIVersion:appsv1.SchemeGroupVersion.

String(),Kind:"Deployment"},

ObjectMeta:metav1.ObjectMeta{Name:welcome.Name,Namespace:welcome.Namespace,

},

Spec:appsv1.DeploymentSpec{Replicas:&defOne,

Selector:&metav1.LabelSelector{

MatchLabels:map[string]string{"welcome":welcome.Name},

},

Template:corev1.PodTemplateSpec{ObjectMeta:metav1.ObjectMeta{

Labels:map[string]string{"welcome":welcome.Name},

},

Spec:corev1.PodSpec{

Containers:[]corev1.Container{

{

Name:"welcome",

Env:[]corev1.EnvVar{

 

{Name:"NAME",Value:name},

},

 

Protocol:"TCP"},


Ports:[]corev1.ContainerPort{

{ContainerPort:8080,Name:"http",


},

Image:"sdfcdwefe/operatordemo:v1",Resources:corev1.ResourceRequirements{

Requests:corev1.ResourceList{corev1.ResourceCPU:   *resource.


NewMilliQuantity(100, resource.DecimalSI),NewMilliQuantity(100000,resource.BinarySI),


corev1.ResourceMemory:*resource.


在上述代码中,我们在 Deployment使用了之前制作的 Docker镜像,将 Types中获得的 NAME字段作为环境变量传入镜像中,在镜像执行 main函数时,即可获得 NAME字段并修改 index文件,在文件中插入 NAME,并默认开启 8080监听端口,用户通过Web访问时即可获得最终的期望值。

接下来,我们完成Service部分代码的实现(见代码清单1-14


func(r*WelcomeReconciler)createService(welcomewebappv1.Welcome)(corev1.Service,error){

svc:=corev1.Service{

TypeMeta:metav1.TypeMeta{APIVersion:corev1.SchemeGroupVersion.

String(),Kind:"Service"},

ObjectMeta:metav1.ObjectMeta{Name:welcome.Name,Namespace:welcome.Namespace,

},

Spec:corev1.ServiceSpec{

Ports:[]corev1.ServicePort{

{Name:"http",Port:8080,Protocol:"TCP",TargetPort:

intstr.FromString("http")},

},

Selector:map[string]string{"welcome":welcome.Name},Type:        corev1.ServiceTypeLoadBalancer,

},

}

 

    在本例中,我们创建了 LoadBalancer类型的 Service。通过kubectlgetsvc命令可以获取 URL地址,也可以访问 Web应用。

相关文章
|
12天前
|
运维 监控 Cloud Native
【云故事探索】NO.17:国诚投顾的云原生 Serverless 实践
国诚投顾携手阿里云,依托Serverless架构实现技术全面升级,构建高弹性、智能化技术底座,提升业务稳定性与运行效率。通过云原生API网关、微服务治理与智能监控,实现流量精细化管理与系统可观测性增强,打造安全、敏捷的智能投顾平台,助力行业数字化变革。
【云故事探索】NO.17:国诚投顾的云原生 Serverless 实践
|
3月前
|
Kubernetes Cloud Native 安全
云原生机密计算新范式 PeerPods技术方案在阿里云上的落地和实践
PeerPods 技术价值已在阿里云实际场景中深度落地。
|
3月前
|
Kubernetes Cloud Native 安全
云原生机密计算新范式 PeerPods 技术方案在阿里云上的落地和实践
PeerPods 技术价值已在阿里云实际场景中深度落地。
|
13天前
|
运维 监控 Cloud Native
【云故事探索】NO.17:国诚投顾的云原生 Serverless 实践
通过与阿里云深度合作,国诚投顾完成了从传统 ECS 架构向云原生 Serverless 架构的全面转型。新的技术架构不仅解决了原有系统在稳定性、弹性、运维效率等方面的痛点,还在成本控制、API 治理、可观测性、DevOps 自动化等方面实现了全方位升级。
|
5月前
|
运维 Cloud Native 测试技术
极氪汽车云原生架构落地实践
随着极氪数字业务的飞速发展,背后的 IT 技术也在不断更新迭代。极氪极为重视客户对服务的体验,并将系统稳定性、业务功能的迭代效率、问题的快速定位和解决视为构建核心竞争力的基石。
|
2月前
|
Cloud Native 中间件 调度
云原生信息提取系统:容器化流程与CI/CD集成实践
本文介绍如何通过工程化手段解决数据提取任务中的稳定性与部署难题。结合 Scrapy、Docker、代理中间件与 CI/CD 工具,构建可自动运行、持续迭代的云原生信息提取系统,实现结构化数据采集与标准化交付。
云原生信息提取系统:容器化流程与CI/CD集成实践
|
3月前
|
资源调度 Kubernetes 流计算
Flink在B站的大规模云原生实践
本文基于哔哩哔哩资深开发工程师丁国涛在Flink Forward Asia 2024云原生专场的分享,围绕Flink On K8S的实践展开。内容涵盖五个部分:背景介绍、功能及稳定性优化、性能优化、运维优化和未来展望。文章详细分析了从YARN迁移到K8S的优势与挑战,包括资源池统一、环境一致性改进及隔离性提升,并针对镜像优化、Pod异常处理、启动速度优化等问题提出解决方案。此外,还探讨了多机房容灾、负载均衡及潮汐混部等未来发展方向,为Flink云原生化提供了全面的技术参考。
193 9
Flink在B站的大规模云原生实践
|
2月前
|
运维 Kubernetes Cloud Native
分钟级到秒级:Yahaha 基于 OpenKruiseGame 的 UE5 游戏云原生实践
回顾《STRIDEN》项目在短短两个月内完成云原生转型的历程,它验证了一条清晰、可行的路径,即如何利用云原生技术,从根本上解决现代在线游戏所面临的运维复杂性难题。

热门文章

最新文章