1. 项目概述当可观测性遇上Kubernetes的包管理器如果你正在Kubernetes上部署和管理Apache SkyWalking并且对一遍遍手动编写和调整YAML文件感到厌倦那么apache/skywalking-helm这个项目就是你一直在找的“自动化管家”。简单来说这是一个官方的Helm Chart仓库它把SkyWalking这个强大的应用性能监控APM和可观测性平台的复杂部署流程打包成了一个标准化的、可参数化的“安装包”。想象一下在没有Helm之前部署SkyWalking到K8s集群意味着什么你需要为oap-server后端分析服务、ui前端界面、elasticsearch或其它存储后端分别创建Deployment、Service、ConfigMap、Secret等一系列资源定义文件。这动辄就是十几个YAML文件任何配置的修改比如调整JVM内存、修改存储地址、开启某个功能特性都意味着你要小心翼翼地编辑多个文件稍有不慎就可能引入错误。而skywalking-helm的出现将这些繁琐的细节全部封装了起来。你只需要关注几个核心的配置值例如使用哪种存储、UI的访问域名、资源限制然后一条helm install命令一个完整、生产就绪的SkyWalking集群就能在你的K8s环境中运行起来。它不仅仅是为了“一键安装”更重要的是实现了部署的标准化、版本化和可重复性这对于团队协作和CI/CD流程集成至关重要。这个Chart覆盖了SkyWalking的核心组件并且紧跟上游版本的发布。无论是想快速搭建一个测试环境还是为生产系统规划一个高可用、带持久化存储的监控平台它都提供了相应的配置选项。接下来我会带你深入这个Chart的内部拆解它的设计思路、关键配置并分享从测试到生产环境落地过程中的一系列实战经验和避坑指南。2. 核心架构与设计思路拆解2.1 Helm Chart的标准结构解析拿到apache/skywalking-helm项目首先得看懂它的目录结构这是理解其设计意图的钥匙。一个标准的Helm Chart通常包含以下核心部分Chart.yaml 这是Chart的“身份证”定义了Chart的名称skywalking、版本appVersion对应SkyWalking版本version对应Chart自身的版本、描述和依赖关系。这里需要特别注意版本兼容性Chart的版本和它支持的SkyWalking应用版本是绑定的用错了可能导致部署失败。values.yaml 这是整个Chart的“控制中枢”和“默认参数库”。所有可配置的参数都在这里定义了默认值。这个文件通常很长因为它要涵盖所有组件的所有可能配置。用户通过创建自己的custom-values.yaml文件来覆盖这里的默认值从而实现个性化部署。templates/目录 这是“魔法发生的地方”。里面存放了所有Kubernetes资源模板文件使用Go Template语法编写。例如deployment.yaml、service.yaml、configmap.yaml等。这些模板文件会读取values.yaml以及用户覆盖的值动态生成最终的Kubernetes YAML清单。charts/目录 如果这个Chart依赖其他子Chart例如SkyWalking可能直接封装一个Elasticsearch的Subchart它们会放在这里。不过skywalking-helm通常将存储依赖如Elasticsearch作为外部依赖处理通过values.yaml配置连接信息而不是直接包含这保持了Chart的简洁和灵活性。这个设计思路的核心是“分离关注点”模板工程师负责在templates/里编写通用的、参数化的资源定义而最终用户只需要关心values.yaml里的配置无需触碰复杂的模板逻辑。这种模式极大地降低了使用门槛和出错概率。2.2 SkyWalking Helm Chart的组件化设计skywalking-helmChart将SkyWalking的架构映射为多个独立的Kubernetes组件每个组件都可以独立配置和启用/禁用。主要包含OAP Server (oap) 这是SkyWalking的大脑负责接收、聚合、分析来自各种探针Agent的数据。在Chart中它通常被部署为一个StatefulSet如果考虑持久化缓存或更稳定的网络标识或Deployment并配套Service用于服务发现。配置重点在于资源限制CPU/内存、副本数实现高可用、JVM参数以及最重要的——存储后端的连接信息。UI (ui) 提供数据可视化和查询的Web界面。它被部署为一个Deployment并通过Service通常是ClusterIP或NodePort暴露。其核心配置是连接到哪个OAP Server的Service。Storage Initializer (initContainer) 这是一个非常关键的设计。在首次部署或存储后端为空时SkyWalking需要在Elasticsearch/MySQL等存储中创建必要的索引和表结构。Chart通过为OAP Pod定义一个initContainer来实现这个初始化任务。这个容器只运行一次执行初始化脚本成功后就退出然后主容器OAP才启动。这确保了依赖顺序是生产部署中一个优雅的解决方案。这种组件化设计使得你可以灵活部署。例如在资源紧张的环境你可以先只部署OAP和UI而在大规模生产环境你可以为OAP配置多个副本、HPA水平Pod自动扩缩容并为UI配置Ingress和TLS证书。3. 关键配置深度解析与实操要点直接使用默认的values.yaml部署很可能无法满足实际需求。下面我们深入几个最常需要调整的核心配置区块。3.1 存储后端配置Chart的“心脏”SkyWalking支持多种存储后端Helm Chart通过storage和elasticsearch等配置节来适配。这是部署前必须明确的第一要务。以Elasticsearch 7.x为例# 在自定义的 custom-values.yaml 中 elasticsearch: enabled: true config: # 用于UI连接ES进行日志查询等功能 host: elasticsearch-master port: 9200 user: elastic passwordSecretName: elastic-credentials # 推荐从Secret读取密码 storage: # 用于OAP Server连接ES存储遥测数据 host: elasticsearch-master port: 9200 user: elastic passwordSecretName: elastic-credentials重要提示 很多新手会混淆config和storage。简单来说config是给SkyWalking UI用的让UI能直接查询ES中的详细日志如果开启了相关功能storage是给OAP Server用的是核心数据的存储地。在大多数内网部署中两者地址通常相同。务必确保passwordSecretName对应的Secret已事先在K8s集群中创建好Chart不会自动创建它。如果你使用外部的、已存在的Elasticsearch集群elasticsearch: enabled: false # 关键禁用Chart内可能存在的ES子Chart部署 oap: env: SW_STORAGE: elasticsearch SW_STORAGE_ES_CLUSTER_NODES: your-external-es-host:9200 SW_ES_USER: elastic SW_ES_PASSWORD: your-password这里我们直接通过OAP容器的环境变量来注入存储配置完全绕过了Chart的storage配置节。这种方式更直接适用于管理严格的云服务ES或已有集群。3.2 OAP Server配置性能与功能的权衡OAP是资源消耗大户配置不当极易导致OOM内存溢出。oap: replicaCount: 2 # 生产环境建议至少2个实现高可用 image: tag: 9.7.0 # 指定明确的版本切勿使用latest javaOpts: -Xms4g -Xmx4g -XX:UseG1GC # JVM堆内存根据数据量调整 resources: limits: memory: 6Gi # 总内存限制应大于堆内存预留空间给堆外内存 cpu: 2000m requests: memory: 4Gi cpu: 1000m env: # 核心配置采样率。10000表示100%采样生产环境可调低以降低负载。 SW_CORE_DEFAULT_SAMPLE_RATE: 10000 # 设置时区避免时间显示问题 TZ: Asia/Shanghai storage: # 设置索引滚动周期例如按月滚动便于管理 indexShardsNumber: 2 indexReplicasNumber: 1 dayStep: 1 # 数据聚合的步长天 superDatasetDayStep: 1实操心得内存估算 OAP的内存占用 ≈ 堆内存 (Xmx) 堆外内存用于网络缓冲、直接内存等。通常建议limits.memory比Xmx大25%-50%。例如Xmx设为4Glimits.memory可设为6G。采样率SW_CORE_DEFAULT_SAMPLE_RATE是控制数据量的关键阀门。在流量巨大的系统中设置为10000100%可能会导致ES和OAP不堪重负。可以从500050%或更低开始根据监控情况调整。持久化卷 OAP本身通常是无状态的数据在存储后端。但它的/skywalking/config目录可能包含动态加载的配置如果使用ConfigMap挂载则无需持久化。如果担心性能可以考虑将日志目录挂载到持久卷但非必需。3.3 UI配置与对外暴露UI的配置相对简单核心是连接到正确的OAP服务。ui: enabled: true replicaCount: 2 image: tag: 9.7.0 service: type: ClusterIP # 通常不直接暴露通过Ingress访问 port: 80 env: # 指向OAP的Service名称。这是K8s内部DNS。 SW_OAP_ADDRESS: skywalking-oap.skywalking.svc.cluster.local:12800 ingress: enabled: true className: nginx hosts: - host: skywalking.yourcompany.com paths: - path: / pathType: Prefix tls: - secretName: skywalking-tls-secret hosts: - skywalking.yourcompany.com注意事项SW_OAP_ADDRESS的值必须是K8s集群内可以解析的OAP Service地址。格式为service-name.namespace.svc.cluster.local:port。如果你在安装时指定了不同的命名空间如-n observability这里也需要相应修改。Ingress配置需要集群中已部署了对应的Ingress Controller如Nginx Ingress Controller。TLS证书的Secret也需要提前创建。4. 完整部署流程与进阶操作4.1 从零开始一次完整的部署实操假设我们已经在K8s集群中准备好了独立的Elasticsearch7.17.x版本集群并创建了访问密码的Secret。步骤1 添加仓库并获取Chart# 添加Apache的Helm仓库如果尚未添加 helm repo add apache https://apache.github.io/skywalking-helm helm repo update # 查看可用的Chart版本选择与你的SkyWalking版本匹配的Chart helm search repo apache/skywalking --versions # 拉取Chart到本地以便查看和自定义以4.3.0版本Chart为例 helm pull apache/skywalking --version 4.3.0 --untar cd skywalking步骤2 准备自定义配置文件在Chart目录外创建my-values.yaml# my-values.yaml oap: replicaCount: 2 image: tag: 9.7.0 javaOpts: -Xms2g -Xmx2g resources: limits: memory: 3Gi cpu: 1000m env: SW_STORAGE: elasticsearch SW_STORAGE_ES_CLUSTER_NODES: elasticsearch-es-http.elasticsearch.svc.cluster.local:9200 SW_ES_USER: elastic SW_ES_PASSWORD: YOUR_STRONG_PASSWORD # 生产环境请使用Secret SW_CORE_DEFAULT_SAMPLE_RATE: 5000 ui: replicaCount: 2 image: tag: 9.7.0 env: SW_OAP_ADDRESS: skywalking-oap.skywalking.svc.cluster.local:12800 ingress: enabled: true className: nginx hosts: - host: skywalking-demo.example.com paths: - path: / pathType: Prefix elasticsearch: enabled: false # 使用外部ES禁用内置部署步骤3 部署到Kubernetes# 创建一个独立的命名空间推荐 kubectl create namespace skywalking # 使用Helm进行安装命名为skywalking安装在skywalking命名空间使用我们的自定义配置 helm install skywalking ./skywalking \ --namespace skywalking \ --values ./my-values.yaml \ --wait # 等待所有资源就绪步骤4 验证部署# 查看Pod状态 kubectl get pods -n skywalking -w # 应该看到类似以下的输出所有Pod状态应为Running # NAME READY STATUS RESTARTS AGE # skywalking-oap-0 1/1 Running 0 2m # skywalking-oap-1 1/1 Running 0 2m # skywalking-ui-7c5b8f6c5d-xxxxx 1/1 Running 0 2m # skywalking-ui-7c5b8f6c5d-xxxxx 1/1 Running 0 2m # 查看Service和Ingress kubectl get svc,ingress -n skywalking4.2 进阶操作升级、回滚与卸载升级当Chart或SkyWalking有新版本时使用helm upgrade。# 先更新仓库获取最新Chart信息 helm repo update # 假设新Chart版本是4.4.0我们更新了my-values.yaml中的image tag helm upgrade skywalking apache/skywalking \ --namespace skywalking \ --version 4.4.0 \ --values ./my-values.yaml \ --wait回滚如果升级出现问题Helm可以轻松回滚到上一个版本。# 查看发布历史 helm history skywalking -n skywalking # 回滚到特定版本例如版本1 helm rollback skywalking 1 -n skywalking卸载彻底删除所有相关资源。helm uninstall skywalking -n skywalking kubectl delete namespace skywalking # 如果需要删除命名空间警告 卸载操作会删除所有由该Chart创建的资源包括PersistentVolumeClaim如果使用了动态存储且未设置storageClass的回收策略为Retain数据可能会丢失生产环境操作前务必确认。5. 生产环境部署的避坑指南与问题排查在实际生产环境中部署skywalking-helm你会遇到一些在测试环境可能不会出现的问题。这里记录了几个典型的“坑”和解决方案。5.1 存储连接与初始化失败问题现象 OAP Pod 一直处于Init:0/1或CrashLoopBackOff状态查看OAP或InitContainer日志提示无法连接Elasticsearch或初始化脚本执行失败。排查思路检查网络连通性 首先确认OAP Pod所在K8s节点网络是否能访问你配置的ES地址。在集群内启动一个临时busyboxPod进行测试kubectl run -it --rm debug --imagebusybox -n skywalking -- sh # 进入容器后 nslookup elasticsearch-es-http.elasticsearch.svc.cluster.local telnet elasticsearch-es-http.elasticsearch.svc.cluster.local 9200检查认证信息 确认SW_ES_USER和SW_ES_PASSWORD或passwordSecretName是否正确。密码中如果包含特殊字符可能需要转义或使用Secret以Base64编码形式存储更安全。检查ES集群状态 确认ES集群本身是健康的且有足够的磁盘空间。初始化过程会创建大量索引需要相应权限。查看初始化容器日志 这是最关键的一步。# 获取OAP Pod名称 kubectl get pods -n skywalking -l appskywalking,componentoap # 查看初始化容器的日志 kubectl logs oap-pod-name -n skywalking -c init日志会清晰显示初始化步骤是在连接ES时失败还是在创建索引模板时失败。常见解决措施如果使用外部ES确保ES服务端口如9200对K8s集群开放。如果ES启用了安全认证如Elasticsearch Security确保使用的用户具有创建索引、管理索引模板的权限通常是superuser或具有相应特权的角色。对于初始化脚本失败有时是因为ES版本与SkyWalking内置的索引模板不兼容。可以尝试在values.yaml中为OAP设置环境变量SW_STORAGE_ES_INDEX_SHARDS_NUMBER和SW_STORAGE_ES_INDEX_REPLICAS_NUMBER来使用更简单的索引设置或者查阅SkyWalking官方文档看是否有针对特定ES版本的已知问题。5.2 OAP Server内存溢出OOMKilled问题现象 OAP Pod频繁重启kubectl describe pod显示原因是OOMKilled。排查与解决调整JVM堆参数 这是首要步骤。在oap.javaOpts中增加-Xmx值例如从-Xms2g -Xmx2g调整为-Xms4g -Xmx4g。同时确保oap.resources.limits.memory大于-Xmx值建议至少大1-2GB。调整SkyWalking内部缓存 OAP使用堆外内存进行数据缓存和聚合。通过环境变量可以调整oap: env: SW_CORE_BUFFER_SIZE: 10000 # 增大缓冲区大小 SW_CORE_FLUSH_PERIOD: 15 # 调整数据刷写到存储的周期秒降低频率可减少瞬时压力降低采样率 如前所述将SW_CORE_DEFAULT_SAMPLE_RATE从10000降低到3000或5000能直接减少数据处理量。垂直扩容 如果业务数据量确实巨大考虑增加OAP Pod的resources.limits.cpu和memory并可能增加replicaCount通过多个OAP实例分担负载。5.3 UI无法连接到OAP或数据为空问题现象 UI可以访问但拓扑图是空的或者一直显示“Loading...”。排查思路检查UI配置 确认ui.env.SW_OAP_ADDRESS配置的地址和端口完全正确。在UI Pod内部执行curl命令测试连通性kubectl exec -it ui-pod-name -n skywalking -- sh curl skywalking-oap.skywalking.svc.cluster.local:12800应该返回OAP服务的健康状态信息。检查OAP服务 确认OAP Service的端口默认为12800和11800是否正确暴露。12800是gRPC端口用于UI查询11800是HTTP端口用于接收Agent数据。kubectl get svc skywalking-oap -n skywalking -o yaml检查Agent数据上报 UI没数据根本原因可能是没有应用Agent上报数据。确保你的被监控应用已经正确配置了SkyWalking Agent并且Agent指向了OAP Service的11800端口对应oap.service.port。Agent配置示例Java# agent.config agent.service_nameyour-application collector.backend_serviceskywalking-oap.skywalking.svc.cluster.local:118005.4 配置热更新与调试技巧有时需要调整OAP的运行时配置而不重启Pod。SkyWalking支持部分配置热更新但更多配置需要重启生效。Helm Chart通过ConfigMap管理配置。查看生成的配置 在调试时可以查看Helm渲染出的最终Kubernetes资源helm template skywalking ./skywalking --namespace skywalking --values ./my-values.yaml output.yaml这会在本地生成一个output.yaml文件包含了所有即将部署的K8s资源定义方便你检查ConfigMap里的内容是否正确。更新配置并应用 修改my-values.yaml后执行helm upgrade。对于通过环境变量传递的配置如SW_CORE_DEFAULT_SAMPLE_RATEOAP Pod会重启以应用新配置。对于通过文件挂载的配置取决于具体实现可能需要重启。直接进入Pod调试 当问题复杂时直接进入OAP容器查看环境变量和日志是最直接的方式kubectl exec -it oap-pod-name -n skywalking -- sh # 查看环境变量 env | grep SW_ # 查看日志 tail -f /skywalking/logs/skywalking-oap.log部署apache/skywalking-helm到生产环境本质上是一个将标准Chart与你的特定基础设施网络、存储、安全策略进行适配的过程。理解其设计原理熟练掌握核心配置项并积累一套自己的问题排查清单就能让这个强大的可观测性平台在你的K8s集群中稳定、高效地运行起来。记住每次变更前在非生产环境充分测试是避免线上事故的最佳实践。
基于Helm Chart的Apache SkyWalking在Kubernetes中的自动化部署与生产实践
1. 项目概述当可观测性遇上Kubernetes的包管理器如果你正在Kubernetes上部署和管理Apache SkyWalking并且对一遍遍手动编写和调整YAML文件感到厌倦那么apache/skywalking-helm这个项目就是你一直在找的“自动化管家”。简单来说这是一个官方的Helm Chart仓库它把SkyWalking这个强大的应用性能监控APM和可观测性平台的复杂部署流程打包成了一个标准化的、可参数化的“安装包”。想象一下在没有Helm之前部署SkyWalking到K8s集群意味着什么你需要为oap-server后端分析服务、ui前端界面、elasticsearch或其它存储后端分别创建Deployment、Service、ConfigMap、Secret等一系列资源定义文件。这动辄就是十几个YAML文件任何配置的修改比如调整JVM内存、修改存储地址、开启某个功能特性都意味着你要小心翼翼地编辑多个文件稍有不慎就可能引入错误。而skywalking-helm的出现将这些繁琐的细节全部封装了起来。你只需要关注几个核心的配置值例如使用哪种存储、UI的访问域名、资源限制然后一条helm install命令一个完整、生产就绪的SkyWalking集群就能在你的K8s环境中运行起来。它不仅仅是为了“一键安装”更重要的是实现了部署的标准化、版本化和可重复性这对于团队协作和CI/CD流程集成至关重要。这个Chart覆盖了SkyWalking的核心组件并且紧跟上游版本的发布。无论是想快速搭建一个测试环境还是为生产系统规划一个高可用、带持久化存储的监控平台它都提供了相应的配置选项。接下来我会带你深入这个Chart的内部拆解它的设计思路、关键配置并分享从测试到生产环境落地过程中的一系列实战经验和避坑指南。2. 核心架构与设计思路拆解2.1 Helm Chart的标准结构解析拿到apache/skywalking-helm项目首先得看懂它的目录结构这是理解其设计意图的钥匙。一个标准的Helm Chart通常包含以下核心部分Chart.yaml 这是Chart的“身份证”定义了Chart的名称skywalking、版本appVersion对应SkyWalking版本version对应Chart自身的版本、描述和依赖关系。这里需要特别注意版本兼容性Chart的版本和它支持的SkyWalking应用版本是绑定的用错了可能导致部署失败。values.yaml 这是整个Chart的“控制中枢”和“默认参数库”。所有可配置的参数都在这里定义了默认值。这个文件通常很长因为它要涵盖所有组件的所有可能配置。用户通过创建自己的custom-values.yaml文件来覆盖这里的默认值从而实现个性化部署。templates/目录 这是“魔法发生的地方”。里面存放了所有Kubernetes资源模板文件使用Go Template语法编写。例如deployment.yaml、service.yaml、configmap.yaml等。这些模板文件会读取values.yaml以及用户覆盖的值动态生成最终的Kubernetes YAML清单。charts/目录 如果这个Chart依赖其他子Chart例如SkyWalking可能直接封装一个Elasticsearch的Subchart它们会放在这里。不过skywalking-helm通常将存储依赖如Elasticsearch作为外部依赖处理通过values.yaml配置连接信息而不是直接包含这保持了Chart的简洁和灵活性。这个设计思路的核心是“分离关注点”模板工程师负责在templates/里编写通用的、参数化的资源定义而最终用户只需要关心values.yaml里的配置无需触碰复杂的模板逻辑。这种模式极大地降低了使用门槛和出错概率。2.2 SkyWalking Helm Chart的组件化设计skywalking-helmChart将SkyWalking的架构映射为多个独立的Kubernetes组件每个组件都可以独立配置和启用/禁用。主要包含OAP Server (oap) 这是SkyWalking的大脑负责接收、聚合、分析来自各种探针Agent的数据。在Chart中它通常被部署为一个StatefulSet如果考虑持久化缓存或更稳定的网络标识或Deployment并配套Service用于服务发现。配置重点在于资源限制CPU/内存、副本数实现高可用、JVM参数以及最重要的——存储后端的连接信息。UI (ui) 提供数据可视化和查询的Web界面。它被部署为一个Deployment并通过Service通常是ClusterIP或NodePort暴露。其核心配置是连接到哪个OAP Server的Service。Storage Initializer (initContainer) 这是一个非常关键的设计。在首次部署或存储后端为空时SkyWalking需要在Elasticsearch/MySQL等存储中创建必要的索引和表结构。Chart通过为OAP Pod定义一个initContainer来实现这个初始化任务。这个容器只运行一次执行初始化脚本成功后就退出然后主容器OAP才启动。这确保了依赖顺序是生产部署中一个优雅的解决方案。这种组件化设计使得你可以灵活部署。例如在资源紧张的环境你可以先只部署OAP和UI而在大规模生产环境你可以为OAP配置多个副本、HPA水平Pod自动扩缩容并为UI配置Ingress和TLS证书。3. 关键配置深度解析与实操要点直接使用默认的values.yaml部署很可能无法满足实际需求。下面我们深入几个最常需要调整的核心配置区块。3.1 存储后端配置Chart的“心脏”SkyWalking支持多种存储后端Helm Chart通过storage和elasticsearch等配置节来适配。这是部署前必须明确的第一要务。以Elasticsearch 7.x为例# 在自定义的 custom-values.yaml 中 elasticsearch: enabled: true config: # 用于UI连接ES进行日志查询等功能 host: elasticsearch-master port: 9200 user: elastic passwordSecretName: elastic-credentials # 推荐从Secret读取密码 storage: # 用于OAP Server连接ES存储遥测数据 host: elasticsearch-master port: 9200 user: elastic passwordSecretName: elastic-credentials重要提示 很多新手会混淆config和storage。简单来说config是给SkyWalking UI用的让UI能直接查询ES中的详细日志如果开启了相关功能storage是给OAP Server用的是核心数据的存储地。在大多数内网部署中两者地址通常相同。务必确保passwordSecretName对应的Secret已事先在K8s集群中创建好Chart不会自动创建它。如果你使用外部的、已存在的Elasticsearch集群elasticsearch: enabled: false # 关键禁用Chart内可能存在的ES子Chart部署 oap: env: SW_STORAGE: elasticsearch SW_STORAGE_ES_CLUSTER_NODES: your-external-es-host:9200 SW_ES_USER: elastic SW_ES_PASSWORD: your-password这里我们直接通过OAP容器的环境变量来注入存储配置完全绕过了Chart的storage配置节。这种方式更直接适用于管理严格的云服务ES或已有集群。3.2 OAP Server配置性能与功能的权衡OAP是资源消耗大户配置不当极易导致OOM内存溢出。oap: replicaCount: 2 # 生产环境建议至少2个实现高可用 image: tag: 9.7.0 # 指定明确的版本切勿使用latest javaOpts: -Xms4g -Xmx4g -XX:UseG1GC # JVM堆内存根据数据量调整 resources: limits: memory: 6Gi # 总内存限制应大于堆内存预留空间给堆外内存 cpu: 2000m requests: memory: 4Gi cpu: 1000m env: # 核心配置采样率。10000表示100%采样生产环境可调低以降低负载。 SW_CORE_DEFAULT_SAMPLE_RATE: 10000 # 设置时区避免时间显示问题 TZ: Asia/Shanghai storage: # 设置索引滚动周期例如按月滚动便于管理 indexShardsNumber: 2 indexReplicasNumber: 1 dayStep: 1 # 数据聚合的步长天 superDatasetDayStep: 1实操心得内存估算 OAP的内存占用 ≈ 堆内存 (Xmx) 堆外内存用于网络缓冲、直接内存等。通常建议limits.memory比Xmx大25%-50%。例如Xmx设为4Glimits.memory可设为6G。采样率SW_CORE_DEFAULT_SAMPLE_RATE是控制数据量的关键阀门。在流量巨大的系统中设置为10000100%可能会导致ES和OAP不堪重负。可以从500050%或更低开始根据监控情况调整。持久化卷 OAP本身通常是无状态的数据在存储后端。但它的/skywalking/config目录可能包含动态加载的配置如果使用ConfigMap挂载则无需持久化。如果担心性能可以考虑将日志目录挂载到持久卷但非必需。3.3 UI配置与对外暴露UI的配置相对简单核心是连接到正确的OAP服务。ui: enabled: true replicaCount: 2 image: tag: 9.7.0 service: type: ClusterIP # 通常不直接暴露通过Ingress访问 port: 80 env: # 指向OAP的Service名称。这是K8s内部DNS。 SW_OAP_ADDRESS: skywalking-oap.skywalking.svc.cluster.local:12800 ingress: enabled: true className: nginx hosts: - host: skywalking.yourcompany.com paths: - path: / pathType: Prefix tls: - secretName: skywalking-tls-secret hosts: - skywalking.yourcompany.com注意事项SW_OAP_ADDRESS的值必须是K8s集群内可以解析的OAP Service地址。格式为service-name.namespace.svc.cluster.local:port。如果你在安装时指定了不同的命名空间如-n observability这里也需要相应修改。Ingress配置需要集群中已部署了对应的Ingress Controller如Nginx Ingress Controller。TLS证书的Secret也需要提前创建。4. 完整部署流程与进阶操作4.1 从零开始一次完整的部署实操假设我们已经在K8s集群中准备好了独立的Elasticsearch7.17.x版本集群并创建了访问密码的Secret。步骤1 添加仓库并获取Chart# 添加Apache的Helm仓库如果尚未添加 helm repo add apache https://apache.github.io/skywalking-helm helm repo update # 查看可用的Chart版本选择与你的SkyWalking版本匹配的Chart helm search repo apache/skywalking --versions # 拉取Chart到本地以便查看和自定义以4.3.0版本Chart为例 helm pull apache/skywalking --version 4.3.0 --untar cd skywalking步骤2 准备自定义配置文件在Chart目录外创建my-values.yaml# my-values.yaml oap: replicaCount: 2 image: tag: 9.7.0 javaOpts: -Xms2g -Xmx2g resources: limits: memory: 3Gi cpu: 1000m env: SW_STORAGE: elasticsearch SW_STORAGE_ES_CLUSTER_NODES: elasticsearch-es-http.elasticsearch.svc.cluster.local:9200 SW_ES_USER: elastic SW_ES_PASSWORD: YOUR_STRONG_PASSWORD # 生产环境请使用Secret SW_CORE_DEFAULT_SAMPLE_RATE: 5000 ui: replicaCount: 2 image: tag: 9.7.0 env: SW_OAP_ADDRESS: skywalking-oap.skywalking.svc.cluster.local:12800 ingress: enabled: true className: nginx hosts: - host: skywalking-demo.example.com paths: - path: / pathType: Prefix elasticsearch: enabled: false # 使用外部ES禁用内置部署步骤3 部署到Kubernetes# 创建一个独立的命名空间推荐 kubectl create namespace skywalking # 使用Helm进行安装命名为skywalking安装在skywalking命名空间使用我们的自定义配置 helm install skywalking ./skywalking \ --namespace skywalking \ --values ./my-values.yaml \ --wait # 等待所有资源就绪步骤4 验证部署# 查看Pod状态 kubectl get pods -n skywalking -w # 应该看到类似以下的输出所有Pod状态应为Running # NAME READY STATUS RESTARTS AGE # skywalking-oap-0 1/1 Running 0 2m # skywalking-oap-1 1/1 Running 0 2m # skywalking-ui-7c5b8f6c5d-xxxxx 1/1 Running 0 2m # skywalking-ui-7c5b8f6c5d-xxxxx 1/1 Running 0 2m # 查看Service和Ingress kubectl get svc,ingress -n skywalking4.2 进阶操作升级、回滚与卸载升级当Chart或SkyWalking有新版本时使用helm upgrade。# 先更新仓库获取最新Chart信息 helm repo update # 假设新Chart版本是4.4.0我们更新了my-values.yaml中的image tag helm upgrade skywalking apache/skywalking \ --namespace skywalking \ --version 4.4.0 \ --values ./my-values.yaml \ --wait回滚如果升级出现问题Helm可以轻松回滚到上一个版本。# 查看发布历史 helm history skywalking -n skywalking # 回滚到特定版本例如版本1 helm rollback skywalking 1 -n skywalking卸载彻底删除所有相关资源。helm uninstall skywalking -n skywalking kubectl delete namespace skywalking # 如果需要删除命名空间警告 卸载操作会删除所有由该Chart创建的资源包括PersistentVolumeClaim如果使用了动态存储且未设置storageClass的回收策略为Retain数据可能会丢失生产环境操作前务必确认。5. 生产环境部署的避坑指南与问题排查在实际生产环境中部署skywalking-helm你会遇到一些在测试环境可能不会出现的问题。这里记录了几个典型的“坑”和解决方案。5.1 存储连接与初始化失败问题现象 OAP Pod 一直处于Init:0/1或CrashLoopBackOff状态查看OAP或InitContainer日志提示无法连接Elasticsearch或初始化脚本执行失败。排查思路检查网络连通性 首先确认OAP Pod所在K8s节点网络是否能访问你配置的ES地址。在集群内启动一个临时busyboxPod进行测试kubectl run -it --rm debug --imagebusybox -n skywalking -- sh # 进入容器后 nslookup elasticsearch-es-http.elasticsearch.svc.cluster.local telnet elasticsearch-es-http.elasticsearch.svc.cluster.local 9200检查认证信息 确认SW_ES_USER和SW_ES_PASSWORD或passwordSecretName是否正确。密码中如果包含特殊字符可能需要转义或使用Secret以Base64编码形式存储更安全。检查ES集群状态 确认ES集群本身是健康的且有足够的磁盘空间。初始化过程会创建大量索引需要相应权限。查看初始化容器日志 这是最关键的一步。# 获取OAP Pod名称 kubectl get pods -n skywalking -l appskywalking,componentoap # 查看初始化容器的日志 kubectl logs oap-pod-name -n skywalking -c init日志会清晰显示初始化步骤是在连接ES时失败还是在创建索引模板时失败。常见解决措施如果使用外部ES确保ES服务端口如9200对K8s集群开放。如果ES启用了安全认证如Elasticsearch Security确保使用的用户具有创建索引、管理索引模板的权限通常是superuser或具有相应特权的角色。对于初始化脚本失败有时是因为ES版本与SkyWalking内置的索引模板不兼容。可以尝试在values.yaml中为OAP设置环境变量SW_STORAGE_ES_INDEX_SHARDS_NUMBER和SW_STORAGE_ES_INDEX_REPLICAS_NUMBER来使用更简单的索引设置或者查阅SkyWalking官方文档看是否有针对特定ES版本的已知问题。5.2 OAP Server内存溢出OOMKilled问题现象 OAP Pod频繁重启kubectl describe pod显示原因是OOMKilled。排查与解决调整JVM堆参数 这是首要步骤。在oap.javaOpts中增加-Xmx值例如从-Xms2g -Xmx2g调整为-Xms4g -Xmx4g。同时确保oap.resources.limits.memory大于-Xmx值建议至少大1-2GB。调整SkyWalking内部缓存 OAP使用堆外内存进行数据缓存和聚合。通过环境变量可以调整oap: env: SW_CORE_BUFFER_SIZE: 10000 # 增大缓冲区大小 SW_CORE_FLUSH_PERIOD: 15 # 调整数据刷写到存储的周期秒降低频率可减少瞬时压力降低采样率 如前所述将SW_CORE_DEFAULT_SAMPLE_RATE从10000降低到3000或5000能直接减少数据处理量。垂直扩容 如果业务数据量确实巨大考虑增加OAP Pod的resources.limits.cpu和memory并可能增加replicaCount通过多个OAP实例分担负载。5.3 UI无法连接到OAP或数据为空问题现象 UI可以访问但拓扑图是空的或者一直显示“Loading...”。排查思路检查UI配置 确认ui.env.SW_OAP_ADDRESS配置的地址和端口完全正确。在UI Pod内部执行curl命令测试连通性kubectl exec -it ui-pod-name -n skywalking -- sh curl skywalking-oap.skywalking.svc.cluster.local:12800应该返回OAP服务的健康状态信息。检查OAP服务 确认OAP Service的端口默认为12800和11800是否正确暴露。12800是gRPC端口用于UI查询11800是HTTP端口用于接收Agent数据。kubectl get svc skywalking-oap -n skywalking -o yaml检查Agent数据上报 UI没数据根本原因可能是没有应用Agent上报数据。确保你的被监控应用已经正确配置了SkyWalking Agent并且Agent指向了OAP Service的11800端口对应oap.service.port。Agent配置示例Java# agent.config agent.service_nameyour-application collector.backend_serviceskywalking-oap.skywalking.svc.cluster.local:118005.4 配置热更新与调试技巧有时需要调整OAP的运行时配置而不重启Pod。SkyWalking支持部分配置热更新但更多配置需要重启生效。Helm Chart通过ConfigMap管理配置。查看生成的配置 在调试时可以查看Helm渲染出的最终Kubernetes资源helm template skywalking ./skywalking --namespace skywalking --values ./my-values.yaml output.yaml这会在本地生成一个output.yaml文件包含了所有即将部署的K8s资源定义方便你检查ConfigMap里的内容是否正确。更新配置并应用 修改my-values.yaml后执行helm upgrade。对于通过环境变量传递的配置如SW_CORE_DEFAULT_SAMPLE_RATEOAP Pod会重启以应用新配置。对于通过文件挂载的配置取决于具体实现可能需要重启。直接进入Pod调试 当问题复杂时直接进入OAP容器查看环境变量和日志是最直接的方式kubectl exec -it oap-pod-name -n skywalking -- sh # 查看环境变量 env | grep SW_ # 查看日志 tail -f /skywalking/logs/skywalking-oap.log部署apache/skywalking-helm到生产环境本质上是一个将标准Chart与你的特定基础设施网络、存储、安全策略进行适配的过程。理解其设计原理熟练掌握核心配置项并积累一套自己的问题排查清单就能让这个强大的可观测性平台在你的K8s集群中稳定、高效地运行起来。记住每次变更前在非生产环境充分测试是避免线上事故的最佳实践。
