k8s

介绍 Apache SkyWalking 是一个应用性能监控（APM）系统，用于分布式系统的监控、追踪和诊断。它提供了完整的可观测性解决方案，帮助开发者和运维人员快速定位和解决分布式系统中的性能问题。 组件说明 OAP (Observability Analysis Platform): 核心分析平台，负责数据收集、分析和存储 UI: Web 界面，用于可视化和查询监控数据 BanyanDB: 高性能时序数据库，作为 SkyWalking 的存储后端 etcd: 分布式键值存储，BanyanDB 使用它来存储元数据 功能特性 分布式追踪: 自动收集和关联分布式系统的调用链，支持跨服务追踪 服务拓扑: 可视化服务之间的依赖关系，实时展示服务调用图 性能指标: 收集服务的性能指标（延迟、吞吐量、错误率等） 日志关联: 将日志与追踪数据关联，通过 TraceID 快速定位问题 告警机制: 支持基于指标的告警规则配置 部署 前置要求 在开始部署之前，请确保满足以下要求： Kubernetes 集群: 版本 1.20+ 命名空间: 已创建 logging 命名空间（或根据实际情况修改） 存储: 确保节点有足够的存储空间（建议至少 10Gi） 网络: 确保 Pod 之间可以正常通信 提示: 本文档中的所有资源都部署在 logging 命名空间中，如需使用其他命名空间，请修改相应的 YAML 文件。 部署 BanyanDB BanyanDB 是 SkyWalking 的存储后端，需要先部署 BanyanDB 和 etcd。 1. 部署 etcd etcd 用于存储 BanyanDB 的元数据。

背景 在k8s 部署一套 promtail + loki + grafana 日志系统。日志由 Promtail 从 Kubernetes 集群中收集并发送到 Loki。Promtail 会提取以下标签： namespace: Pod 所在的命名空间 pod_name: Pod 名称 deployment_name: Deployment 名称（从 Pod 的 app 标签或 Pod 名称中提取） container: 容器名称 部署 loki Deployment: Loki 主服务 Service: 提供集群内部访问 ConfigMap: Loki 配置文件 PVC: 数据持久化存储（10Gi） PV: 数据存储类 创建 YAML 文件 首先创建 namespace: 1kubectl create namespace logging 创建 loki 目录并创建 pv.yaml 1apiVersion: v1 2kind: PersistentVolume 3metadata: 4 name: loki-data-pv 5spec: 6 capacity: 7 storage: 10Gi # 存储大小 8 accessModes: 9 - ReadWriteOnce 10 persistentVolumeReclaimPolicy: Retain 11 storageClassName: host-loki 12 hostPath: 13 path: /data/loki # 存储位置 14 type: DirectoryOrCreate 15 nodeAffinity: 16 required: 17 nodeSelectorTerms: 18 - matchExpressions: 19 - key: kubernetes.

背景 鉴于 Ingress NGINX 将在 2026 年 3 月停止积极维护（只保留 “best-effort maintenance”）考虑切换到Traefik。Traefik 官方推荐是最直接的替代，因为 Traefik 围绕 Ingress NGINX 的兼容层做了优化：它对部分常见的 nginx-ingress 注解提供了兼容支持。 MEtalLB 安装 1kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.15.2/config/manifests/metallb-native.yaml 1kubectl get pods -n metallb-system 创建 metallb-config.yaml 1# metallb-config.yaml 2apiVersion: metallb.io/v1beta1 3kind: IPAddressPool 4metadata: 5 name: local-pool 6 namespace: metallb-system 7spec: 8 addresses: 9 - 10.10.10.180-10.10.10.181 # ← 修改为你的局域网可用 IP 10--- 11apiVersion: metallb.io/v1beta1 12kind: L2Advertisement 13metadata: 14 name: l2adv 15 namespace: metallb-system 1kubectl apply -f metallb-config.

介绍 提供一个在 Kubernetes 中使用 cert-manager + Cloudflare 自动签发并自动更新 Let’s Encrypt 证书的完整思路与示例（DNS-01 验证），方便你在集群内自动化 TLS 证书更新。 前置条件 Kubernetes 集群：可正常访问外网。不做网络环境配置的教程，具体可以去看其他文章 Cloudflare 账号：已将你的域名托管到 Cloudflare。使用 Cloudflare 做 dns-01 挑战 kubectl：已连接到集群。最基本的条件，保证k8s能正常访问 helm：推荐用 Helm 安装 cert-manager。使用helm安装，方便干净 安装 官方推荐用 Helm，这里我使用 1.18.2 的版本，在我这个时间点这个版本还是比较新的 安装 cert-manager 1# 安装 cert-manager CRDs 2kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.18.2/cert-manager.crds.yaml 1## Add the Jetstack Helm repository 2helm repo add jetstack https://charts.jetstack.io --force-update 1## Install the cert-manager helm chart 2helm install cert-manager --namespace cert-manager --version v1.18.2 jetstack/cert-manager 验证：

准备工作 节点名称 节点IP k8s-master-1 10.10.10.151 k8s-master-2 10.10.10.152 k8s-master-3 10.10.10.153 kube-vip(虚拟IP) 10.10.10.150 RKE 安装 rancher 在第一个 master 安装 RKE2 server 1# 安装 RKE2 2curl -sfL https://get.rke2.io | sh - 创建配置文件 1mkdir -p /etc/rancher/rke2/ 1# 配置 server 2cat <<EOF >/etc/rancher/rke2/config.yaml 3write-kubeconfig-mode: "0644" 4tls-san: 5 - 10.10.10.150 6 - rancher.jobcher.com 7cni: cilium 8disable-kube-proxy: true 9EOF 1# 启动 server 2systemctl enable rke2-server --now 3systemctl status rke2-server 1ln -s /var/lib/rancher/rke2/bin/kubectl /usr/local/bin/kubectl 2echo 'export KUBECONFIG=/etc/rancher/rke2/rke2.yaml' >> ~/.

环境准备(配置代理) proxy_setting.yml 1--- 2- name: 设置全局代理并测试连接 3 hosts: all 4 become: yes 5 vars: 6 proxy_host: "10.10.10.254" 7 proxy_port: "7890" 8 http_proxy: "http://{{ proxy_host }}:{{ proxy_port }}" 9 https_proxy: "http://{{ proxy_host }}:{{ proxy_port }}" 10 no_proxy: "localhost,127.0.0.1" 11 12 environment: 13 http_proxy: "{{ http_proxy }}" 14 https_proxy: "{{ https_proxy }}" 15 no_proxy: "{{ no_proxy }}" 16 17 tasks: 18 - name: 显示代理设置 19 debug: 20 msg: 21 - "HTTP Proxy: {{ http_proxy }}" 22 - "HTTPS Proxy: {{ https_proxy }}" 23 - "NO_PROXY: {{ no_proxy }}" 24 25 - name: 使用 curl 测试外部连接（使用代理） 26 command: curl -I https://www.

背景 已经2024年了， k8s已经更新到 1.30.x的版本了，但是还有很多公司还在使用1.17.9版本，那么我们今天就来手动安装一下1.17.9版本的k8s。 安装 我们在测试centos服务器192.168.40.1安装单节点 Kubernetes 集群（Master 节点）使用 kubeadm 是一个相对直接的过程。 前提条件 确保主机满足以下要求： 操作系统：CentOS 7.x 或更高版本 内存：至少 2 GB 内存 磁盘空间：至少 20 GB 磁盘空间 网络：至少 2 个网络接口 配置主机名和 IP 1sudo hostnamectl set-hostname k8s 2echo "192.168.40.1 k8s" | sudo tee -a /etc/hosts 更新系统 切换镜像源,选择你喜欢的镜像源，我这里选择腾讯云 1bash <(curl -sSL https://linuxmirrors.cn/main.sh) 更新系统 1sudo yum update -y 禁用 SELinux 1sudo setenforce 0 2sudo sed -i --follow-symlinks 's/^SELINUX=enforcing/SELINUX=permissive/' /etc/selinux/config 禁用 Swap 1sudo swapoff -a 2sudo sed -i '/swap/d' /etc/fstab 修改 /etc/sysctl.

containerd 现在很多人说起容器都会说到docker，docker凭借镜像（images）快捷的部署，占领了极大的技术市场，docker公司将自己的核心依赖 Contanerd 捐给了 CNCF，这个就是contanerd的由来，containerd 在kubernetes在 v1.24之后的版本作为底层核心进行使用。 Containerd架构 可以看到 Containerd 仍然采用标准的 C/S 架构，服务端通过 GRPC 协议提供稳定的 API，客户端通过调用服务端的 API 进行高级的操作。 为了解耦，Containerd 将不同的职责划分给不同的组件，每个组件就相当于一个子系统（subsystem）。连接不同子系统的组件被称为模块。 总体上 Containerd 被划分为两个子系统： Bundle : 在 Containerd 中，Bundle 包含了配置、元数据和根文件系统数据，你可以理解为容器的文件系统。而 Bundle 子系统允许用户从镜像中提取和打包 Bundles。 Runtime : Runtime 子系统用来执行 Bundles，比如创建容器。 其中，每一个子系统的行为都由一个或多个模块协作完成（架构图中的 Core 部分）。每一种类型的模块都以插件的形式集成到 Containerd 中，而且插件之间是相互依赖的。例如，上图中的每一个长虚线的方框都表示一种类型的插件，包括 Service Plugin、Metadata Plugin、GC Plugin、Runtime Plugin 等，其中 Service Plugin 又会依赖 Metadata Plugin、GC Plugin 和 Runtime Plugin。每一个小方框都表示一个细分的插件，例如 Metadata Plugin 依赖 Containers Plugin、Content Plugin 等。 总之，万物皆插件，插件就是模块，模块就是插件。 常用插件 Content Plugin : 提供对镜像中可寻址内容的访问，所有不可变的内容都被存储在这里。 Snapshot Plugin : 用来管理容器镜像的文件系统快照。镜像中的每一个 layer 都会被解压成文件系统快照，类似于 Docker 中的 graphdriver。 Metrics : 暴露各个组件的监控指标。 安装 卸载docker 首先要保证环境干净整洁，如果你有安装docker服务，需要先卸载docker，如果没有安装可以跳过

Argo cd 安装和部署 Argo CD 是一个为 Kubernetes 而生的，遵循声明式 GitOps 理念的持续部署（CD）工具。Argo CD 可在 Git 存储库更改时自动同步和部署应用程序 安装 前提：你已经安装好了 k8s 环境，我们将在国内的k8s环境下部署argocd 1k3s kubectl create namespace argocd 2kubectl apply -n argocd -f https://github.jobcher.com/gh/https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml 检查是否正常部署 1kubectl get po -n argocd 如果没有错误的情况下应该是全部都runnning，但是如果出现argocd-repo-server CrashLoopBackOff错误有以下解决途径： 使用以下补丁修补了部署。删除后，错误消失，repo 服务器可以启动。 1apiVersion: apps/v1 2kind: Deployment 3metadata: 4 name: argocd-repo-server 5spec: 6 template: 7 spec: 8 securityContext: 9 seccompProfile: 10 type: RuntimeDefault 如果出现argocd-dex-server imagepullbackoff错误有以下解决方法： 1docker pull ghcr.io/dexidp/dex:v2.37.0 2docker tag ghcr.io/dexidp/dex:v2.37.0 harbor/dexidp/dex:v2.37.0 3docker push harbor/dexidp/adex:v2.

简介 企业在上云之后，云计算基础设施支出不断创造新高，但 IT 团队却难以找到成本失控的源头，跟每一个业务沟通，所需要的资源都是必须的，降本增效无从谈起。 引入FinOps 的目标是在云上创造一种财务问责制度，每个业务团队需要根据 FinOps 团队的数据做出更加合理的配置、规划，从而在财务成本、业务稳定之间找到一种平衡。FinOps 并不是一次性、短暂的任务，而是在规划实施之后依旧需要进行持续管理，这要求企业必须设定明确的、持续的角色和责任，以保持对成本长期控制。 概念 建立对云成本的共识：企业中各个相关角色应该意识到云成本的重要性，并将成本管理纳入到决策过程中。通过提高成本意识，可以更好地控制和优化云资源的使用。 明确云成本管理的责任和角色：确定负责 FinOps 团队成员，建立相应责任制度。这样确保有专门人员负责云成本的监控、分析和优化，从而提高整体的财务管理效果。 提供培训和教育资源：培训企业成员了解成本管理的基本概念、工具和技术。这有助于增强团队的能力，使他们能够更好地理解和应对云成本挑战。 促进不同团队之间的合作：财务团队、开发团队和运维团队应该紧密合作，共同制定和实施成本管理策略。通过协作，可以更好地理解业务需求、优化资源配置，并确保成本管理策略与业务目标相一致。 利用自动化技术提高效率和准确性：通过采用自动化工具收集、分析和报告云成本数据。自动化还可以帮助实现实时监控和警报，以及自动化资源管理，从而提高成本管理的效率和准确性。 使用 kubecost 分析 Kubernetes 成本 接下来我们展开今天的具体内容，如何使用 kubecost 分析 Kubernetes 成本。 kubecost 是目前较优秀的开源 Kubernetes 成本分析工具，它提供了丰富的功能和仪表板，帮助用户更好地理解和控制其容器化工作负载的成本。 kubecost 目前支持 阿里云、AWS 等云厂商对接，它能够提供集群中命名空间、应用等各类资源成本分配，用户还可以基于这些信息在 Kubecost 中设置预算和警报，帮助运维和财务管理人员进一步实现成本管理。 安装 Kubecost 安装 Kubecost 建议使用 Helm 进行安装，使用以下命令： 1helm repo add kubecost https://kubecost.github.io/cost-analyzer/ 2helm repo update 3helm upgrade --install kubecost kubecost/cost-analyzer --namespace kubecost --create-namespace 几分钟后，检查以确保 Kubecost 已启动并运行： 1kubectl get pods -n kubecost 2# Connect to the Kubecost dashboard UI 3kubectl port-forward -n kubecost svc/kubecost-cost-analyzer 9090:9090 现在可以打开浏览器并指向 http://127.

基础配置 三台环境为centos7.9，以下配置需要在每台机器上执行 配置hosts解析 1cat >> /etc/hosts <<EOF 2192.168.2.23 node1 3192.168.2.24 node2 4192.168.2.25 node3 5EOF 关闭防火墙和selinux 1systemctl stop firewalld && systemctl disable firewalld 2setenforce 0 && sed -i 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/selinux/config 分别在三个节点设置主机名 1hostnamectl set-hostname node1 2hostnamectl set-hostname node2 3hostnamectl set-hostname node3 配置主机时间同步 1systemctl restart chronyd.service && systemctl enable chronyd.service 配置免密登录 1ssh-keygen 2ssh-copy-id -i .ssh/id_rsa.pub node1 3ssh-copy-id -i .ssh/id_rsa.pub node2 4ssh-copy-id -i .ssh/id_rsa.pub node3 安装pip和ansible、git 1yum install python-pip ansible git -y 部署ceph集群 克隆存储库 这里我选择安装的是ceph nautilus版本

背景 使用 kubeadm 安装 kubernetes 集群非常方便，但是也有一个比较烦人的问题就是默认的证书有效期只有一年时间，所以需要考虑证书升级的问题 检查证书 由 kubeadm 生成的客户端证书默认只有一年有效期，我们可以通过 check-expiration 命令来检查证书是否过期： 1kubeadm alpha certs check-expiration 该命令显示 /etc/kubernetes/pki 文件夹中的客户端证书以及 kubeadm 使用的 KUBECONFIG 文件中嵌入的客户端证书的到期时间/剩余时间。 手动更新 kubeadm alpha certs renew 这个命令用 CA（或者 front-proxy-CA ）证书和存储在 /etc/kubernetes/pki 中的密钥执行更新。 高可用的集群，这个命令需要在所有控制面板节点上执行 具体执行 接下来我们来更新我们的集群证书，下面的操作都是在 master 节点上进行 备份节点 1$ mkdir /etc/kubernetes.bak 2$ cp -r /etc/kubernetes/pki/ /etc/kubernetes.bak 3$ cp /etc/kubernetes/*.conf /etc/kubernetes.bak 备份 etcd 数据目录 1$ cp -r /var/lib/etcd /var/lib/etcd.bak 执行更新证书的命令 1kubeadm alpha certs renew all --config=kubeadm.yaml 检查更新 1kubeadm alpha certs check-expiration 更新下 kubeconfig 文件 1kubeadm init phase kubeconfig all --config kubeadm.