ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

KubeVela webservice 组件类型全解析:从 Application 声明到 Deployment 与 Service 的渲染原理

KubeVela webservice 组件类型全解析:从 Application 声明到 Deployment 与 Service 的渲染原理 云原生DevOps运维微服务【免费下载链接】kubevelaThe Modern Application Platform.项目地址https://gitcode.com/gh_mirrors/ku/kubevela点击查看免费下载KubeVelaThe Modern Application Platform以Application为统一交付入口而webservice是其中最核心、最常用的内置组件类型它把一个长期运行、可水平扩容、对外提供稳定网络端点的容器化服务抽象为一组声明式参数。本文以 webservice 使用示例 为主线结合 webservice 的 CUE 定义 与其在 Helm Chart 中的生成产物完整讲解每个参数的默认值与取值约束、底层渲染为 Kubernetes Deployment 与 Service 的机制、健康检查策略以及挂载存储、配置资源、对接 HPA 等典型实战场景。读完本文你将能够不看文档就写出一份正确的 webservice 组件配置并理解其背后的渲染逻辑。组件定位与官方描述webservice组件的官方描述定义在 webservice.cue 中为Describes long-running, scalable, containerized services that have a stable network endpoint to receive external network traffic from customers.即描述长期运行、可扩展、容器化的服务且具备稳定的网络端点以接收来自客户的外部网络流量。它适用于 Web 应用、API 服务、网关等需要对外提供流量的无状态或轻状态工作负载。从定义结构看该组件有两个关键元数据元数据值说明attributes.workload.definitionapps/v1的Deployment声明其托管的工作负载类型attributes.workload.typedeployments.apps供资源拓扑、回滚、伸缩等能力识别使用也就是说声明一个webservice组件KubeVela 最终会将其渲染为 KubernetesDeployment并根据端口暴露配置自动附带一个Service。最简示例一份可运行的 Applicationwebservice.eg.md 给出了完整的最小可用示例覆盖了镜像、启动命令、端口暴露、CPU 与环境变量等最常用字段apiVersion: core.oam.dev/v1beta1 kind: Application metadata: name: website spec: components: - name: frontend type: webservice properties: image: oamdev/testapp:v1 cmd: [node, server.js] ports: - port: 8080 expose: true cpu: 0.1 env: - name: FOO value: bar - name: FOO valueFrom: secretKeyRef: name: bar key: bar将该 YAML 通过vela up -f或kubectl apply -f提交给集群后KubeVela 会生成一个名为frontend的Deploymentapps/v1容器镜像为oamdev/testapp:v1入口命令为[node, server.js]容器端口 8080CPU requests/limits 均为0.1环境变量FOObar另一个FOO取自名为bar的 Secret 中bar键的值一个名为frontend的Servicev1由于expose: true该端口会被暴露Service 类型默认ClusterIP监听端口 8080targetPort 也是 8080。参数全表类型、默认值与取值约束webservice的全部入参都在 webservice.cue 的parameter块中以 CUE 结构化 schema 形式声明。下表按字段整理*表示默认值参数类型 / 取值默认值说明imagestring必填无服务镜像CLI 短参数为-ilabels[string]: string无注入到工作负载 Pod 的 labelsannotations[string]: string无注入到工作负载 Pod 的 annotationsimagePullPolicyAlways \| Never \| IfNotPresent不设置镜像拉取策略imagePullSecrets[...string]无拉取私有镜像所需的 Secret 名称列表cmd[...string]无容器入口命令对应 Deployment 的commandargs[...string]无入口命令参数对应 Deployment 的argsenv对象数组见下无环境变量支持value与valueFromports对象数组见下无端口列表schema 注释提示默认面向 80 端口portint已废弃无旧版单端口字段已被ports取代CLI 短参数-pexposeTypeClusterIP \| NodePort \| LoadBalancerClusterIP生成的 Service 类型nodePort仅在NodePort下生效addRevisionLabelboolfalse为 true 时给底层 Pod 打上app.oam.dev/revision标签cpustring无CPU 资源如0.50.5 核、11 核memorystring无内存资源如1024MiK8s 数量格式limit{cpu?, memory?}无资源上限不设置时上限与请求一致volumeMounts结构体见下无挂载卷pvc / configMap / secret / emptyDir / hostPathvolumes对象数组已废弃无旧版卷字段建议改用volumeMountslivenessProbe#HealthProbe无存活探针readinessProbe#HealthProbe无就绪探针hostAliases[{ip, hostnames}]无注入/etc/hosts的域名映射ports 子字段ports: - port: 8080 # Service 监听端口必填 containerPort: 8080 # 容器端口缺省时取 port 值 name: http # 端口名缺省时自动生成为 port-port非 TCP 协议追加 -udp/-sctp 后缀 protocol: TCP # 默认 TCP可选 UDP / SCTP expose: true # 是否生成 Service 暴露默认 false nodePort: 30080 # 仅当 exposeType 为 NodePort 时生效env 子字段env: - name: FOO # 环境变量名必填 value: bar # 直接赋值 - name: FOO valueFrom: # 从 Secret / ConfigMap 取值 secretKeyRef: name: bar # Secret 名称 key: bar # Secret 键 configMapKeyRef: name: cfg # ConfigMap 名称 key: foo # ConfigMap 键volumeMounts 支持的卷类型类型关键子字段默认值pvcname、mountPath、subPath?、claimName—configMapname、mountPath、subPath?、defaultMode、cmName、items?defaultMode: 420即 0644items[].mode: 511secretname、mountPath、subPath?、defaultMode、secretName、items?defaultMode: 420emptyDirname、mountPath、subPath?、mediummedium: 磁盘介质可设MemoryhostPathname、mountPath、subPath?、path—健康探针 #HealthProbelivenessProbe与readinessProbe共用#HealthProbe结构webservice.cue三种探测方式三选一exec/httpGet/tcpSocket其余参数均有默认值参数默认值说明exec.command无容器内执行命令退出码 0 视为健康httpGet.path/httpGet.port无HTTP GET 探测的路径与端口另有host?、scheme?默认HTTP、httpHeaders?tcpSocket.port无TCP 端口探测initialDelaySeconds0容器启动后延迟探测秒数periodSeconds10探测周期秒timeoutSeconds1单次探测超时秒successThreshold1连续成功判定健康所需次数failureThreshold3连续失败判定不健康/不就绪所需次数渲染原理一个组件如何变成 Deployment Servicewebservice的模板由三部分构成CUE 定义中的output、outputs与辅助列表理解它即可预判最终的 Kubernetes 资源形态。主资源 outputDeploymentoutput直接声明一个apps/v1Deploymentwebservice.cue关键渲染规则包括选择器spec.selector.matchLabels[app.oam.dev/component]固定等于组件名context.namePod 标签恒注入app.oam.dev/name应用名与app.oam.dev/component组件名addRevisionLabel: true时额外注入app.oam.dev/revision版本号容器容器名取组件名image必填cmd映射为commandargs映射为args端口若使用旧字段port且未定义ports仅生成containerPort若定义ports则每个条目生成containerPort与protocol端口名缺省时按port-port规则自动生成非 TCP 协议追加小写协议后缀这正对应 Kubernetes 对端口名必须以小写字母开头的约束资源cpu/memory的请求与上限存在两条分支webservice.cue——指定limit.cpu时requests.cpu cpu且limits.cpu limit.cpu未指定时requests与limits均为cpu内存同理。也就是说默认情况下请求与上限相等属于 Guaranteed QoS 的保守配置环境变量env直接透传同时若存在context.config如来自 config 类 trait 的注入会将其合并进env卷推荐的新字段volumeMounts会先拼装mountsArray挂载点列表与volumesList卷定义再经deDupVolumesArray按name去重后写入 Deployment旧字段volumes则直接按typepvc/configMap/secret/emptyDir逐条生成卷其他imagePullPolicy、imagePullSecrets、livenessProbe、readinessProbe、hostAliases带// patchKeyip标记支持按 IP 做 patch 合并均有对应透传。辅助资源 outputsService当ports中存在expose: true的条目时模板会计算exposePorts列表并生成名为组件名的 Servicewebservice.cueselector固定为app.oam.dev/component: context.name与 Deployment 的选择器一一对应type取exposeType默认ClusterIP每个暴露端口生成portService 端口、targetPort缺省与port相同否则取containerPort、protocol与自动生成的端口名exposeType: NodePort且指定nodePort时会一并写入。这套组件即服务的建模方式意味着只要在ports中把expose置为 trueKubeVela 就自动完成 Service 的创建与关联无需单独再写 Service 资源。状态与健康策略Ready 到底怎么算webservice还内置了自定义状态与健康策略webservice.cue用于vela status等场景的输出与判定customStatus输出形如Ready: 2/3的信息分子取status.readyReplicas缺省 0分母取spec.replicashealthPolicy同时收集updatedReplicas、readyReplicas、replicas与observedGeneration均缺省 0判定健康的条件为spec.replicas readyReplicas且spec.replicas updatedReplicas且spec.replicas replicas同时observedGeneration不小于metadata.generation即期望副本数全部就绪、全部更新且观测代数已追上健康检查开关若 Pod 上有注解app.oam.dev/disable-health-check则直接强制isHealth: true方便跳过健康判定。从源码结构看这套逻辑与 KubeVela 通用的healthPolicy/customStatus机制一致是组件定义层面声明式表达可观测性的典型做法。实战场景从存储挂载到弹性伸缩场景一挂载 PVC 存储使用新版volumeMounts字段可同时挂载多个卷相同name的卷会被自动去重合并application-with-storage.yaml 展示了通过storagetrait 创建 PVC 并挂载组件内直接挂载 PVC 的写法见 core-definitions 示例spec: components: - name: express-server type: webservice properties: image: crccheck/hello-world exposeType: NodePort ports: - port: 8000 - port: 8001 name: exposeport1 protocol: UDP expose: true - port: 8002 protocol: UDP expose: true volumeMounts: pvc: - name: my-mount mountPath: /test claimName: myclaim - name: my-mount mountPath: /test2 subPath: /sub claimName: myclaim注意两点expose: true只对显式标记的端口生效此处 8001/8002 是 UDP 端口会自动生成port-8001-udp这类合法端口名两个 PVC 挂载共享name: my-mount渲染时会合并为一个卷、两个挂载点其中一个带subPath。场景二细粒度资源控制webservice的cpu/memory是请求值配合limit可拆分请求与上限application-with-resource.yaml 则演示了更常见的做法——通过resourcetrait 统一覆盖资源请求properties: image: busybox cmd: [sleep, 1000] cpu: 0.2 memory: 256Mi limit: cpu: 1 memory: 512Mi渲染结果为requests.cpu0.2、limits.cpu1、requests.memory256Mi、limits.memory512Mi。若省略limit请求与上限会保持相等。场景三配合 scaler / hpa 实现弹性webservice 面向可扩展服务设计天然可与scaler、hpa等 trait 组合。hpatrait 通过targetAPIVersion: apps/v1、targetKind: Deployment指向 webservice 生成的 Deployment 并依据 CPU/内存利用率自动伸缩application-with-hpa.yamlspec: components: - name: helloworld type: webservice properties: cpu: 0.5 exposeType: ClusterIP image: oamdev/hello-world memory: 1024Mi ports: - expose: true port: 80 protocol: TCP traits: - type: scaler properties: replicas: 1 - type: hpa properties: targetAPIVersion: apps/v1 targetKind: Deployment max: 10 min: 1 cpu: type: Utilization value: 80 mem: type: AverageValue value: 90当业务进入灰度/滚动发布场景时还可叠加k8s-update-strategytrait 精细控制RollingUpdate的maxSurge与maxUnavailable示例见 application-with-k8s-update-strategy.yaml而apply-once策略可以保护spec.replicas不被回滚逻辑覆盖同文件中的policies段。定义来源与修改方式webservice的权威定义位于 vela-templates/definitions/internal/component/webservice.cue安装 KubeVela 时由 Helm Chart 渲染为名为webservice的ComponentDefinition资源生成产物见 charts/vela-core/templates/defwithtemplate/webservice.yaml其头部注释明确标注请编辑原始 CUE 文件勿直接改生成文件。若需自定义行为可复制该 CUE 模板后通过vela def工具重新生成新的组件定义并将其注册到目标命名空间。小结围绕 webservice.eg.md 中那份短短 24 行的示例本文完整展开了webservice组件的参数体系含全部默认值与取值约束、双资源渲染链路Deployment Service、健康状态判定逻辑以及存储、资源、HPA、滚动更新等实战组合。核心要点可归纳为三句话image是唯一必填参数其余字段都有安全的缺省行为端口默认暴露ClusterIP、资源默认请求等于上限ports[].expose: true是触发自动生成 Service 的开关exposeType决定 Service 类型所有字段最终都被 CUE 模板精准映射为 Deployment 与 Service 字段理解 webservice.cue 就等于理解了全部渲染行为。赞分享云原生DevOps运维微服务【免费下载链接】kubevelaThe Modern Application Platform.项目地址https://gitcode.com/gh_mirrors/ku/kubevela点击查看免费下载相关推荐TanStack Table Solid 版 FlexRender 组件用法、类型与渲染原理全解析TanStack Table Solid 版 FlexRender 组件用法、类型与渲染原理全解析 FlexRender 是 tanstack/solid前端UI组件KubeVela Operation 执行模型设计把 Day-2 操作渲染为临时 ApplicationDesign 01 全解析KubeVela Operation 执行模型设计把 Day 2 操作渲染为临时 ApplicationDesign 01 全解析 导读 本文基于 Ku云原生DevOps运维微服务从类型解析到渲染优化Fumadocs AutoTypeTable组件深度剖析从类型解析到渲染优化Fumadocs AutoTypeTable组件深度剖析 在Fumadocs文档框架开发中AutoTypeTable组件作为类型展示的核前端文档MCP 服务上一篇Windows Cleaner终极指南彻底解决C盘爆红的免费系统清理工具下一篇XHS-Downloader架构解析小红书内容采集技术实现指南创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表