L B T

记 录 过 去 的 经 验

发表于 上层目录 ，

Amazon WorkSpaces 主要支持两种核心串流协议：

  • **WSP（Amazon WorkSpaces Streaming Protocol)**，基于 NICE DCV（DCV 专门为高性能图形处理（如 CAD、3D 渲染）和低延迟交互设计） 技术。是 AWS 近年大力推广的云原生协议，旨在提供更现代化的用户体验。

    • 网络适应性强 ：在网络条件不稳定或高延迟的环境下表现更好。
    • 双向音视频支持 ：原生支持 网络摄像头 (Webcam) 透传，非常适合视频会议（如 Teams, Zoom）。
    • 防火墙友好 ：通常通过 TCP/UDP 端口 443 运行，更容易穿透企业防火墙。
    • Web Access ：如果你习惯使用浏览器访问桌面，WSP 的兼容性和性能远超 PCoIP(已经不支持 Web Access)。
    • 认证支持 ：支持更高级的身份验证方式，如 WebAuthn 和智能卡。

  • PCoIP（传统协议） ： 这是 WorkSpaces 最早采用的协议，技术非常成熟，由 Teradici 开发。

    • 优点：

      • 图形渲染精准 ：在处理高对比度、像素密集型的图形任务（如图像编辑）时，色彩表现更精准。

      • 终端设备广泛 ：支持 PCoIP Zero Client（零客户机）硬件，以及包括 iPad 和 Android 在内的更广泛的移动端 App。

      • 成熟稳定 ：作为老牌协议，在极端负载下的稳定性经过了长期验证。

    • 缺点：

      • 音视频功能弱 ：原生 PCoIP 客户端通常不支持网络摄像头透传。

      • 网络要求高 ：对网络延迟较敏感，一旦丢包，体验下降明显。

      • Web 访问限制 ：已不支持。

制作镜像

为统一 AWS Workspaces 中的用户桌面系统和软件环境，建议自制镜像，预装常用软件，配置相关权限。自制桌面镜像请参考以下步骤：

  1. 先启动一台基础版的 WorkSpace。

  2. 以管理员身份登录，手动安装所有必要软件，对系统进行必要配置，如语言、地区、输入法等。

    如果要从 Windows WorkSpace 创建映像，请在运行创建进程之前使用位于 C:\Program Files\Amazon\ImageChecker.exe 中的映像检查器验证映像。

  3. 完成配置后，回到 AWS WorkSpaces 控制台，选择该桌面。

  4. 点击 Actions -> Create Image（创建镜像）。

  5. 镜像创建成功后，选择该镜像并点击 Actions -> Create Bundle（创建捆绑包） 。

    镜像创建成功后，可在 Amazon WorkSpaces -> WorkSpaces -> Image（映像） 中查看

后续操作 ： 以后为新员工开通桌面时，直接选择这个 自定义捆绑包 ，所有人的软件环境将完全一致。

配置 Workspace 云桌面无管理员权限

如果要全局配置，使 Directory 中的用户登陆云桌面后不是管理员权限，可以通过 AWS WorkSpaces 的目录设置（Directory Settings）取消用户的本地管理员权限 。实施步骤参考：

  1. 登录 AWS WorkSpaces 控制台 。

  2. 在左侧导航栏选择 Directories（目录） 。

  3. 选择对应的目录 ID，点击 目录名称进入查看详情页。

  4. 找到 Local administrator setting（本地用户管理员权限） 选项。

  5. 取消勾选 Enable local administrator setting（启用本地管理员设置） 。

结果： 用户将作为标准用户登录，无法修改系统配置或安装需要管理员权限的软件。

控制台修改后，只对新部署的桌面生效

要使已存在的桌面也生效，可以使用以下方法：

  • 重新构建（Rebuild）：系统会根据当前的目录（Directory）设置（即已禁用的管理员权限）重新初始化 C 盘。C 盘会被重置。虽然 D 盘（用户数据）会保留，但用户自行安装在 C 盘的软件、系统设置、浏览器书签（若未同步）等都会丢失。执行前必须通知员工备份。
  • 通过组策略（GPO）强制回收（推荐用此方法）：如果不希望重置员工的 C 盘，可以通过 Windows 域控的组策略强制移除用户在 Administrators 组中的身份。
    1. 登录域控服务器： 登录到您 WorkSpaces 连接的 AD 域控制器。
    2. 创建/编辑 GPO： 打开 Group Policy Management 。
    3. 导航至：Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Restricted Groups
    4. 右键点击 Add Group ，输入 Administrators
    5. 在 Members of this group（此组的成员） 中，只添加您信任的管理账号（如 Domain Admins ），不要添加 WksAdminUser 或其他普通用户。
    6. 强制刷新： 当 WorkSpace 桌面下次重启或手动执行 gpupdate /force 后，普通用户的本地管理员权限会被强制剥离。

控制 AWS Workspace 客户端设备类型

如果要控制 AWS Workspace 桌面只能从某些设备登陆，可以修改 Directory 中的 问权限的设备类型

如果使用 Amazon Workspace Client，则只能使用一个账户登陆，如果要同时登陆不同的账户，可以使用 Web Access

默认情况下，Web Access 登陆 Workspace 后因为浏览器安全限制原因，没有使用本地系统剪切板权限，无法在云桌面和本地之间粘贴复制。如果想要在本地和 workspace 云桌面之间粘贴复制（前提是未做其他限制，如 GPO 禁止粘贴），只需配置浏览器权限，允许使用剪切板即可。操作方式为，在网站左上角允许使用剪切板，具体操作如图：

AWS Workspaces 中的 AD 域管理

AWS Workspaces 使用的 AD 通常有以下两种：

  • AWS Managed Microsoft AD ： AWS 托管的 Microsoft AD 域控服务。
  • Simple AD ： 本质上是基于 Samba 4 的兼容方案

无论哪种 AD，都不支持直接通过 AWS 控制台管理，必须通过一台 Windows 管理机（EC2 或 WorkSpace）远程操作。

以下步骤以管理 Simple AD 为例提供参考步骤：

  1. 启动一台 Windows Server 实例（推荐）或一台现有的 WorkSpace。

  2. 确保这台机器已经加入到您的 Simple AD 域名下。方便起见最好是部署在 Directory 中 Workspace 云桌面，其已经在域中。

  3. 以管理员账户登陆并安装工具:

    1. 在服务器管理器中，点击 添加角色和功能 。

    2. 在 功能 列表中，勾选 组策略(Group Policy Management)管理工具 以及 远程服务器管理工具 (Remote Server Administration Tools,RSAT) -> 角色管理工具(Role Administration Tools) -> AD DS 和 AD LDS 工具 。

      如果 Directory 配置了 禁用本地管理员设置 ，使用新部署的 Workspace 桌面会不具备管理员权限，无法安装工具。只需要有 域管理员账户密码即可解决 。在任务栏或开始菜单找到 Server Manager (服务器管理器) ，选择 Run as different user (以其他用户身份运行) 。

安装完成后，即可打开 Active Directory Users and Computers 工具查看 AD 域中的用户和计算机信息

要管理组策略，使用 Group Policy Management 工具

有些由 AWS WorkSpaces 的串流协议控制的功能，如 控制在 Workspace 云桌面和本地之间复制或传输文件 等，Windows 默认是不存在这些策略的，需要手动导入 AWS 提供的模板。AWS 定义的策略官方文档（Manage your Windows WorkSpaces in WorkSpaces Personal）

发表于 更新于 上层目录 ，

环境信息

  • Centos 7
  • Prometheus Server 2.4
  • Node Exporter v1.4.0
  • Grafana v9.2.5

安装

在 Docker 中安装 Prometheus Server

创建 Prometheus Server 配置文件，如 /root/prometheus/prometheus.yml，内容如下 [1]

/data/prometheus/prometheus.yml
# my global config
global:
  scrape_interval:     15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
  evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.
  # scrape_timeout is set to the global default (10s).

# Alertmanager configuration
alerting:
  alertmanagers:
  - static_configs:
    - targets:
      # - alertmanager:9093

# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:
  # - "first_rules.yml"
  # - "second_rules.yml"

# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:
  # The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
  - job_name: 'prometheus'

    # metrics_path defaults to '/metrics'
    # scheme defaults to 'http'.

    static_configs:
    - targets: ['localhost:9090']

使用 Docker 启动时挂载此文件，作为 Prometheus Server 的配置文件，之后需要修改配置，可以直接修改此文件。

docker run -d -p 9090:9090 \
           --name prometheus \
           -v /root/prometheus/prometheus.yml:/etc/prometheus/prometheus.yml \
           prom/prometheus

启动后，可以通过 $Prometheus_IP:9090 访问 Prometheus Server UI

阅读全文 »

发表于 上层目录 ，

中国大陆地区部署不可用

IPSec 协议

使用 Docker 部署命令如下

docker run -d     --name ikev2-vpn     --restart=always     --cap-add=NET_ADMIN     -e "VPN_IPSEC_PSK=StrongPSK123"     -e "VPN_USER=myuser"     -e "VPN_PASSWORD=MyPass123"     -p 500:500/udp     -p 4500:4500/udp     hwdsl2/ipsec-vpn-server

在 iPhone 上前往 设置 -> 通用 -> VPN 与设备管理 -> VPN -> 添加 VPN 配置 ：

  • 类型: IPsec
  • 描述随便填: (如 MyVPN)
  • 服务器 :
  • 本地 ID : 留空
  • 用户名 : myuser
  • 密码 : MyPass123
  • 密钥 : StrongPSK123

L2TP 协议

使用 Docker 部署命令如下

docker run -d   --name ikev2-vpn-l2tp   --restart=always   --cap-add=NET_ADMIN   --device=/dev/ppp   -e "VPN_IPSEC_PSK=StrongPSK123"   -e "VPN_USER=myuser"   -e "VPN_PASSWORD=MyPass123"   -p 500:500/udp   -p 4500:4500/udp   -p 1701:1701/udp   hwdsl2/ipsec-vpn-server

在 iPhone 上前往 设置 -> 通用 -> VPN 与设备管理 -> VPN -> 添加 VPN 配置 ：

  • 类型: L2TP
  • 描述随便填: (如 MyVPN)
  • 服务器 :
  • 本地 ID : 留空
  • 用户名 : myuser
  • 密码 : MyPass123
  • 密钥 : StrongPSK123

发表于 上层目录 ，

Docker 部署步骤

创建配置文件 config.json

config.json
{
  "log": {
    "loglevel": "debug",    /* 为了观察运行情况或者定位问题，可以开启debug 日志 */
    "access": "/dev/stdout",
    "error": "/dev/stdout"
  },    
  "inbounds": [{
    "port": 443,
    "protocol": "vless",
    "settings": {
      "clients": [
         {
           "id": "c4187394-5865-446d-9d8d-3f6c179416b0(UID 替换为实际值)", 
           "flow": "xtls-rprx-vision"
         }
        ],
      "decryption": "none"
    },
    "streamSettings": {
      "network": "tcp",
      "security": "reality",
      "realitySettings": {
        "show": false,
        "dest": "www.microsoft.com:443",   
        "xver": 0,
        "serverNames": ["www.microsoft.com"],
        "privateKey": "mD0OUR8tFvOypHQre6yGgsZs2w-JecH4zkXB9_TY-k8（私钥）",
        "shortIds": ["a1b2c3d4"]
      }
    }
  }],
  "outbounds": [{"protocol": "freedom"}]
}

  • "id": "c4187394-5865-446d-9d8d-3f6c179416b0(UID 替换为实际值)" 可以自行生成
  • "dest": "www.microsoft.com:443" 伪装的网站地址
  • "privateKey": "mD0OUR8tFvOypHQre6yGgsZs2w-JecH4zkXB9_TY-k8（私钥）" 私钥，公司钥对可以使用如下命令生成 
    # docker run --rm teddysun/xray xray x25519
    PrivateKey: iBKDmvNMfFOAzNPOLRlnJLzoaYbHKs9RFatpW1ELeks
    Password: OV_SMIonfy1cEzxnDGZff9x0HeuhuqLyrIj0dLqAaHw
    Hash32: 1fEp1041YBnLfSvQYVsRfvGJEA8ZV_LjqFGtQKwaWG0

    • PrivateKey 对应私钥（ privateKey ）
    • Password 对应公钥（ Public Key ），要发送给客户端使用

正常启动后，在客户端如下配置：

  • 类型： VLESS

  • 地址（Address）： <SERVER IP>

  • 端口（Port）： 443 # 对应配置文件中的 inbounds.port

  • UUID： <UID> # 对应配置文件中的 inbounds.settings.clients.id

  • 流（Flow）： xtls-rprx-vision # 对应配置文件中的 inbounds.settings.clients.flow

  • 传输协议(Transport protocol(network))： TCP # 对应配置文件中的 inbounds.streamSettings.network

  • TLS/安全： Reality # 对应配置文件中的 inbounds.streamSettings.security

  • 加密(Encryption): none # 对应配置文件中的 inbounds.settings.decryption

  • SNI： www.microsoft.com # 对应配置文件中的 inbounds.streamSettings.realitySettings.dest

  • 短 ID（Short ID）： a1b2c3d4 # 对应配置文件中的 inbounds.streamSettings.realitySettings.shortIds

  • 公钥（Public key、密码、Password）： <公钥> # docker run --rm teddysun/xray xray x25519 命令生成的 Password

为了方便客户端导入，可以为配置生成以下链接，其中包含了客户端链接所需的参数：

vless://<UID>@<SERVER IP>:<Port>?encryption=none&flow=xtls-rprx-vision&security=reality&sni=www.microsoft.com&fp=chrome&pbk=<Public Key or Password>&sid=a1b2c3d4#Shanghai_MS_Reality

大多数客户端都支持从粘贴板复制以上内容自动导入配置。

Windows 中使用 v2rayN 连接 xray server

  • v2rayN 版本： v7.18.0

Windows 下载 v2rayN ，将其解压后，运行程序 v2rayN.exe 即可打开程序。复制配置链接（ vless://<UID>@<SERVER IP>:<Port>?encryption=none&flow=xtls-rprx-vision&security=reality&sni=www.microsoft.com&fp=chrome&pbk=<Public Key or Password>&sid=a1b2c3d4#Shanghai_MS_Reality ），在 v2rayN 主界面点击 Configuration -> Import Share Links from clipboard 即可自动导入配置

默认情况下， v2rayN 会测试到 google.com 的连接来验证服务端是否正常，国内服务器此测试必定失败，因此可以修改此测试目标。参考以下步骤：

  1. 导航到 Settings -> v2rayN settings: Speed Ping Test URL ，此处默认值为 google.com ，将其改为国内服务器可以访问的地址如 https://www.baidu.com

要验证 xray server 工作正常，可以在 v2rayN 客户端进行 延迟检测（Test real delay） 。右键要检测的 xray server 选择 Test real delay

如果能够获取到延迟数据，说明 xray 工作正常，如果未获取到延迟数据，可以登陆服务器，通过命令 docker logs 检查服务端日志

发表于 上层目录

Keycloak 是一个开源的身份和访问管理（IAM）解决方案。

Keycloak 官网链接

Kubernetes 中部署 Keycloak

  • Kubernetes 1.35
  • Kustomize Version: v5.7.1
  • Keycloak 26.x
  • Aurora RDS PostgreSQL

参考官方文档在 Kubernetes 中部署 Keycloak

下载 Keycloak 配置文件： https://raw.githubusercontent.com/keycloak/keycloak-quickstarts/refs/heads/main/kubernetes/keycloak.yaml 并修改数据库相关配置，本示例使用 AWS Aurora PostgreSQL：

keycloak.yaml
## 要连接 RDS PostgreSQL，需要设置这些核心环境变量：
- name: KC_DB
  value: postgres
- name: KC_DB_URL_HOST
  value: <RDS_ENDPOINT>
- name: KC_DB_URL_DATABASE
  value: <DB_NAME>
- name: KC_DB_USERNAME
  valueFrom:
      secretKeyRef:
        name: keycloak-db-secret
        key: username
- name: KC_DB_PASSWORD
  valueFrom:
      secretKeyRef:
        name: keycloak-db-secret
        key: password

本示例使用 Kustomize 部署，文档结构如下：

$ tree
.
├── base
│   ├── ingresses.yaml
│   ├── kustomization.yaml
│   ├── services.yaml
│   └── statefulset.yaml
└── overlays
    ├── dev
    └── prod
        └── kustomization.yaml

base/statefulset.yaml 内容如下，主要参考官网安装文档（https://raw.githubusercontent.com/keycloak/keycloak-quickstarts/refs/heads/main/kubernetes/keycloak.yaml）

base/statefulset.yaml
apiVersion: apps/v1
# Use a stateful setup to ensure that for a rolling update Pods are restarted with a rolling strategy one-by-one.
# This prevents losing in-memory information stored redundantly in two Pods.
kind: StatefulSet
metadata:
  name: keycloak
  labels:
    app: keycloak
spec:
  serviceName: keycloak-discovery
  # Run with one replica to save resources, or with two replicas to allow for rolling updates for configuration changes
  replicas: 2
  selector:
    matchLabels:
      app: keycloak
  template:
    metadata:
      labels:
        app: keycloak
    spec:
      containers:
        - name: keycloak
          image: quay.io/keycloak/keycloak:26.5.4
          args: ["start"]
          env:
            # 初始管理员账户和密码
            - name: KC_BOOTSTRAP_ADMIN_USERNAME
              value: "admin"
            - name: KC_BOOTSTRAP_ADMIN_PASSWORD
              value: "admin"
            # In a production environment, add a TLS certificate to Keycloak to either end-to-end encrypt the traffic between
            # the client or Keycloak, or to encrypt the traffic between your proxy and Keycloak.
            # Respect the proxy headers forwarded by the reverse proxy
            # In a production environment, verify which proxy type you are using, and restrict access to Keycloak
            # from other sources than your proxy if you continue to use proxy headers.
            - name: KC_PROXY_HEADERS
              value: "xforwarded"
            - name: KC_HTTP_ENABLED
              value: "true"
            # In this explorative setup, no strict hostname is set.
            # For production environments, set a hostname for a secure setup.
            - name: KC_HOSTNAME_STRICT
              value: "false"
            - name: KC_HEALTH_ENABLED
              value: "true"
            - name: 'KC_CACHE'
              value: 'ispn'
            # Passing the Pod's IP primary address to the JGroups clustering as this is required in IPv6 only setups
            - name: POD_IP
              valueFrom:
                fieldRef:
                  fieldPath: status.podIP
            # Instruct JGroups which DNS hostname to use to discover other Keycloak nodes
            # Needs to be unique for each Keycloak cluster
            - name: KC_CACHE_EMBEDDED_NETWORK_BIND_ADDRESS
              value: '$(POD_IP)'
            - name: 'KC_DB_URL_DATABASE'
              value: 'keycloak'
            - name: 'KC_DB_URL_HOST'
              value: '<RDS_endpoint>'
            - name: 'KC_DB'
              value: 'postgres'
            # In a production environment, use a secret to store username and password to the database
            - name: 'KC_DB_PASSWORD'
              value: '<RDS_PASSWORD>'
            - name: 'KC_DB_USERNAME'
              value: '<RDS_USERNAME>'
          ports:
            - name: http
              containerPort: 8080
            - name: jgroups
              containerPort: 7800
            - name: jgroups-fd
              containerPort: 57800
          startupProbe:
            httpGet:
              path: /health/started
              port: 9000
            periodSeconds: 1
            failureThreshold: 600              
          readinessProbe:
            httpGet:
              path: /health/ready
              port: 9000
            periodSeconds: 10
            failureThreshold: 3              
          livenessProbe:
            httpGet:
              path: /health/live
              port: 9000
            periodSeconds: 10
            failureThreshold: 3              
          resources:
            limits:
              cpu: 2000m
              memory: 2000Mi
            requests:
              cpu: 500m
              memory: 1700Mi

base/services.yaml 内容如下：

base/services.yaml
apiVersion: v1
kind: Service
metadata:
  name: keycloak
  labels:
    app: keycloak
spec:
  ports:
    - protocol: TCP
      port: 8080
      targetPort: http
      name: http
    ## 主要用于 ALB 健康检查
    - name: management
      port: 9000
      targetPort: 9000    
  selector:
    app: keycloak
  type: ClusterIP
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: keycloak
  name: keycloak-discovery
spec:
  selector:
    app: keycloak
  clusterIP: None
  type: ClusterIP

base/ingresses.yaml 内容如下：

base/ingresses.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/healthcheck-path: /health/ready
    alb.ingress.kubernetes.io/healthcheck-port: "9000"  # 健康检查（Health Check）端口和 web 端口（8080）不同 
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS": 443}]'    # admin console 必须使用 https
    alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:ap-east-1::certificate/f2cd4604-4791-43dd-8d33-545210272f1c    
  name: keycloak-web-ingress
spec:
  ingressClassName: alb
  rules:
  - http:
      paths:
      - backend:
          service:
            name: keycloak
            port:
              number: 8080
        path: /
        pathType: Prefix
    host: keycloak.example.com

base/kustomization.yaml 内容如下：

base/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - statefulset.yaml
  - services.yaml
  - ingresses.yaml

overlays/prod/kustomization.yaml 内容如下

overlays/prod/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

namespace: keycloak

resources:
  - ../../base

执行以下命令查看最终生成的配置：

$ kubectl kustomize overlays/prod/

发表于 更新于 上层目录

ArgoCD 是目前 Kubernetes 生态中最流行的 GitOps 持续交付（CD）工具。它的核心理念是将 Git 仓库视为集群状态的“唯一真理来源”。

ArgoCD 的核心工作原理 ：

  • 声明式管理 ：你不在集群里手动运行 kubectl ，而是将所有的资源清单（YAML、Helm、Kustomize）存放在 Git 中管理。
  • 同步与漂移检测 ：ArgoCD 会持续监控 Git 仓库和 EKS 集群。如果两者状态不一致（即发生“漂移”），它会报警或自动将集群恢复到 Git 定义的状态。

Argo CD 核心概念说明

ArgoCD Application 删除时的 Propagation Policy

在 Argo CD 中，当你删除一个 Application 时，Propagation Policy（传播策略） 决定了该应用下属的 Kubernetes 资源（如 Deployment, Service, ConfigMap 等） 应该如何处理。本质上是调用了 Kubernetes API 的删除机制，Argo CD 利用 K8s 的 Finalizer 机制来实现这一逻辑

策略名称 行为描述 结果
Foreground Cascade(前台级联) 最常用。先删除子资源，最后删除 Application 本身。 集群资源被彻底清理，最安全。
Background Cascade(后台级联) 立即删除 Application，子资源在后台由 K8s 垃圾回收机制静默删除。 最终结果同上，但 Application 对象消失得更快。
Orphan (Non-cascading ,孤儿模式) 只删壳，不删内容。只删除 Application 对象，保留集群里的实际资源。 资源继续运行，不再受 Argo CD 管控。
这通常用于 迁移场景 :你只想让 Argo CD 不再管这个应用，但不想让业务停掉。

在 Kubernetes 集群中安装 ArgoCD

# kubectl create namespace argocd
namespace/argocd created

# kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml --server-side
customresourcedefinition.apiextensions.k8s.io/applications.argoproj.io serverside-applied
customresourcedefinition.apiextensions.k8s.io/applicationsets.argoproj.io serverside-applied
customresourcedefinition.apiextensions.k8s.io/appprojects.argoproj.io serverside-applied
serviceaccount/argocd-application-controller serverside-applied
serviceaccount/argocd-applicationset-controller serverside-applied
serviceaccount/argocd-dex-server serverside-applied
serviceaccount/argocd-notifications-controller serverside-applied
serviceaccount/argocd-redis serverside-applied
serviceaccount/argocd-repo-server serverside-applied
serviceaccount/argocd-server serverside-applied
role.rbac.authorization.k8s.io/argocd-application-controller serverside-applied
role.rbac.authorization.k8s.io/argocd-applicationset-controller serverside-applied
role.rbac.authorization.k8s.io/argocd-dex-server serverside-applied
role.rbac.authorization.k8s.io/argocd-notifications-controller serverside-applied
role.rbac.authorization.k8s.io/argocd-redis serverside-applied
role.rbac.authorization.k8s.io/argocd-server serverside-applied
clusterrole.rbac.authorization.k8s.io/argocd-application-controller serverside-applied
clusterrole.rbac.authorization.k8s.io/argocd-applicationset-controller serverside-applied
clusterrole.rbac.authorization.k8s.io/argocd-server serverside-applied
rolebinding.rbac.authorization.k8s.io/argocd-application-controller serverside-applied
rolebinding.rbac.authorization.k8s.io/argocd-applicationset-controller serverside-applied
rolebinding.rbac.authorization.k8s.io/argocd-dex-server serverside-applied
rolebinding.rbac.authorization.k8s.io/argocd-notifications-controller serverside-applied
rolebinding.rbac.authorization.k8s.io/argocd-redis serverside-applied
rolebinding.rbac.authorization.k8s.io/argocd-server serverside-applied
clusterrolebinding.rbac.authorization.k8s.io/argocd-application-controller serverside-applied
clusterrolebinding.rbac.authorization.k8s.io/argocd-applicationset-controller serverside-applied
clusterrolebinding.rbac.authorization.k8s.io/argocd-server serverside-applied
configmap/argocd-cm serverside-applied
configmap/argocd-cmd-params-cm serverside-applied
configmap/argocd-gpg-keys-cm serverside-applied
configmap/argocd-notifications-cm serverside-applied
configmap/argocd-rbac-cm serverside-applied
configmap/argocd-ssh-known-hosts-cm serverside-applied
configmap/argocd-tls-certs-cm serverside-applied
secret/argocd-notifications-secret serverside-applied
secret/argocd-secret serverside-applied
service/argocd-applicationset-controller serverside-applied
service/argocd-dex-server serverside-applied
service/argocd-metrics serverside-applied
service/argocd-notifications-controller-metrics serverside-applied
service/argocd-redis serverside-applied
service/argocd-repo-server serverside-applied
service/argocd-server serverside-applied
service/argocd-server-metrics serverside-applied
deployment.apps/argocd-applicationset-controller serverside-applied
deployment.apps/argocd-dex-server serverside-applied
deployment.apps/argocd-notifications-controller serverside-applied
deployment.apps/argocd-redis serverside-applied
deployment.apps/argocd-repo-server serverside-applied
deployment.apps/argocd-server serverside-applied
statefulset.apps/argocd-application-controller serverside-applied
networkpolicy.networking.k8s.io/argocd-application-controller-network-policy serverside-applied
networkpolicy.networking.k8s.io/argocd-applicationset-controller-network-policy serverside-applied
networkpolicy.networking.k8s.io/argocd-dex-server-network-policy serverside-applied
networkpolicy.networking.k8s.io/argocd-notifications-controller-network-policy serverside-applied
networkpolicy.networking.k8s.io/argocd-redis-network-policy serverside-applied
networkpolicy.networking.k8s.io/argocd-repo-server-network-policy serverside-applied
networkpolicy.networking.k8s.io/argocd-server-network-policy serverside-applied

  • --server-side 选项用于解决可能的报错： The CustomResourceDefinition "applicationsets.argoproj.io" is invalid: metadata.annotations: Too long: may not be more than 262144 bytes

等待 ArgoCD 相关 Pod 运行正常

# kubectl get pods -n argocd
NAME                                               READY   STATUS    RESTARTS        AGE
argocd-application-controller-0                    1/1     Running   0               6m11s
argocd-applicationset-controller-77475dfcf-qzvsf   1/1     Running   1 (3m47s ago)   6m15s
argocd-dex-server-6485c5ddf5-4ms4f                 1/1     Running   0               6m14s
argocd-notifications-controller-758f795776-4n5rb   1/1     Running   0               6m14s
argocd-redis-6cc4bb5db5-svpwm                      1/1     Running   0               6m13s
argocd-repo-server-c76cf57cd-pv8sb                 1/1     Running   0               6m12s
argocd-server-6f85b59c87-zhmqh                     1/1     Running   0               6m12s

创建 Ingress 对外开放 ArgoCD UI，本示例中 IngressClass 为 AWS alb

argocd_ingress.yml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: argocd
  namespace: argocd
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip

spec:
  ingressClassName: alb
  rules:
  - host: argocd.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: argocd-server
            port:
              number: 80


创建并检查 Ingress

# kubectl apply -f argocd_ingress.yml 
ingress.networking.k8s.io/argocd configured

# kubectl get ingresses -A
NAMESPACE   NAME     CLASS   HOSTS                ADDRESS                                               PORTS   AGE
argocd      argocd   alb     argocd.example.com   k8s-argocd-argocd-8e8cb.ap-east-1.elb.amazonaws.com   80      8m22s

ArgoCD Pod 强制开启了 TLS (HTTPS)，而 ALB 却在使用 HTTP 进行健康检查。会因为健康检查失败无法访问

在集群中的 Pod 中尝试请求 argocd-server Pod 的地址，可以看到默认返回了重定向到 HTTPS 的响应，ALB 会因为证书问题对 Pod 健康检查失败

# curl -Iv 172.31.68.215:8080
> HEAD / HTTP/1.1
> Host: 172.31.68.215:8080
> User-Agent: curl/8.18.0
> Accept: */*
> 

HTTP/1.1 307 Temporary Redirect
Location: https://172.31.68.215:8080/


可以配置 ArgoCD 接受 HTTP 协议请求。 修改 ArgoCD Server 启动参数 ，执行命令 kubectl edit deployment argocd-server -n argocd 编辑 argocd-server 的 Deployment，在启动命令（ command ）中添加 --insecure 参数。

containers:
- args:
  - /usr/local/bin/argocd-server
  - --insecure

修改后等待 Pod 自动重启

$ kubectl get pods -A
NAMESPACE     NAME                                               READY   STATUS    RESTARTS   AGE
argocd        argocd-server-6ff754765c-pt5z6                     0/1     Running   0          18s

再次观察 ALB 的 Target 健康检查状态

ArgeCD 可以正常访问后，执行以下命令获取初始 admin 账户的密码

kubectl get secret argocd-initial-admin-secret -n argocd -o jsonpath="{.data.password}" | base64 -d

ArgoCD UI 常用操作

创建 Project

Project 可以实现资源或者 APP 的逻辑隔离，可以通过 Project 限制 APP 对以下资源的使用：

  • SOURCE REPOSITORIES ：限制该 Project 下的 Application 只能从指定的 Git Reop 或者 Helm 仓库拉取配置（Manifest）。防止越权拉取。
  • SCOPED REPOSITORIES ： 只允许属于 Project 的 APP 从指定的 Reop 拉取代码（Manifest）
  • DESTINATIONS / SCOPED CLUSTERS： 限制属于 Project 的 APP 只能部署到指定的 Kubernetes 集群（（Server URL/Name））和 Namespace。支持通配符。例如限制只能部署到 in-cluster 的 dev-* 命名空间。
  • cluster resource allow list / cluster resource deny list ： Kubernetes Cluster 范围内允许/拒绝使用的资源，针对 非命名空间资源（如 ClusterRole, CustomResourceDefinition, Namespace, StorageClass）
  • namespace resource allow list / namespace resource deny list ： Namespace 范围的资源限制/允许，针对 命名空间资源（如 Deployment, Service, Secret, ConfigMap） 。

多用户与权限控制

Argo CD 有两个核心组件控制权限：

  • argocd-server（认证）

  • argocd-rbac-cm（授权）

Argo CD 支持三种用户方式

  1. 本地用户（不推荐生产）

  2. SSO（推荐生产） ，支持：

    • GitHub

    • GitLab

    • Azure AD

    • Google

    • OIDC

    • LDAP

    • Okta

    • Keycloak

    1. Kubernetes RBAC 模式（高级） 。可以让 ServiceAccount 调用 Argo API。

发表于 上层目录

Kustomize 是专为 Kubernetes 设计的声明式配置管理工具，允许用户通过分层和声明式方式定制和管理应用程序配置，无需直接修改原始清单文件。Kustomize 已集成到 kubectl ，成为 Kubernetes 原生配置管理方案。

Kustomize 提供多种声明式配置管理能力，适用于复杂的 Kubernetes 应用场景:

  • 配置合并与分层管理

    Kustomize 采用 基础配置（ base ） 和 覆盖配置（ overlay ） 的分层架构：

    • 基础配置(base) ：应用的通用资源定义
    • 覆盖配置(overlay) ：针对特定环境或需求的定制，支持修改、添加或删除基础内容

  • 声明式配置与复用

    Kustomize 使用 YAML 格式的 kustomization.yaml 文件描述定制规则，支持：

    • 资源引用与组合
    • 名称前后缀统一管理
    • 标签与注释批量添加
    • 环境变量与配置映射替换
    • 镜像标签动态修改

    通过组件与补丁（patches），实现配置的复用与跨项目共享，降低维护成本。

  • 多环境配置管理

    Kustomize 天然支持多环境部署，可为开发、测试、生产等环境创建专属覆盖(overlay)配置，实现一套基础配置适配多环境。

关键特性

  • 无模板定制 ：无需模板语言即可修改清单
  • 基于覆盖(overlay)的配置 ：通过补丁实现变体
  • 资源生成 ：自动生成 ConfigMaps 、 Secrets
  • 资源转换 ：内置或自定义转换器
  • 插件系统 ：支持多种插件扩展，扩展资源生成与转换能力。插件类型包括：
    • Generators ：如 ConfigMapGenerator 、 SecretGenerator
    • Transformers ：如 PatchTransformer 、 NamespaceTransformer
    • Validators ：资源校验插件
  • 变量替换 ：运行时数据注入

自 Kubernetes 1.14 起，Kustomize 已内置于 kubectl ，提供原生配置管理能力。 kubectl 内置 Kustomize 版本随 Kubernetes 版本变化。

$ kubectl version --client
Client Version: v1.35.0
Kustomize Version: v5.7.1

Kustomize 相关常用命令

直接应用配置：

kubectl apply -k overlays/dev
kubectl apply --kustomize overlays/dev

预览生成的清单：

kubectl kustomize overlays/prod

查看配置差异：

kubectl diff -k overlays/prod

删除应用的资源：

kubectl delete -k overlays/dev
阅读全文 »

发表于 更新于 上层目录 ，

将源站的内容主动预取到 CDN 节点，用户首次访问可直接命中缓存，即提升首次访问速度，又能有效缓解源站压力。

  • 数据格式：请求和响应都支持 json/xml，xml 的参数与 json 的参数基本一致，json 的参数是驼峰分隔，xml 的参数是“-”分隔，详见示例。
  • 限制说明：每个账号的预取并发是 10，调高并发会增加回源的压力，请联系技术支持人员评估。
阅读全文 »

发表于 更新于 上层目录 ，

场景

远程登录 windows 失败，报错:

由于没有远程桌面授权服务器可以提供许可证，远程会话连接已断开，请跟服务器管理员联系

解决方法

  1. 打开 cmd，执行以下命令远程登录无法登录的 Windows 主机
    mstsc /v:1.1.1.1 /admin
  2. 打开注册表


3. 找到路径： HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM\GracePeriod.如果超过120天后RCM下面会有一个GracePeriod,先备份这项注册表，再删除除了默认的的注册表项。

  1. 重启电脑后生效.

发表于 更新于 上层目录 ，

HCL AppScan（原名IBM Security AppScan）是原IBM的Rational软件部门的一组网络安全测试和监控工具，2019年被HCL技术公司收购。AppScan旨在在开发过程中对Web应用程序的安全漏洞进行测试。

阅读全文 »

发表于 更新于 上层目录

环境信息

  • centos7 5.4.212-1.el7
  • kubernetes Server Version: v1.25.0
  • Helm 3.10.0

Helm 定位为 Kubernetes 包管理器 或者 Kubernetes App Store ，就如 RHEL 中的 yum/dnf 。主要组件如下：

  • helm : 纯客户端工具，负责模板渲染、插件执行和 OCI 交互。
  • kstatus 状态检查器 ： 集成 kstatus 标准，替代了以前简单的 wait 逻辑。它能更精准地判断资源（如 Deployment, StatefulSet ）是否真正“就绪”。
  • OCI 存储库 : Helm 4 进一步强化了对 OCI（Docker 镜像仓库协议）的支持，支持通过 Digest (散列值) 安装 Chart，确保供应链安全。
  • slog 日志系统 : 内部采用 Go 语言的结构化日志 slog ，方便集成到现代化的可观测性平台。

核心概念 ：

  • Chart ： 软件包。它是一系列 YAML 模板的集合，定义了应用如何运行所需的所有资源和信息。
  • Repository（仓库） ： 存放 Chart 的地方（类似 Docker Hub 或应用商店），如 https://artifacthub.io/packages/search?kind=0
  • Release : 运行中的实例。你用同一个 Chart 安装了两次，就会产生两个独立的 Release。

Helm 4 支持将复杂的配置拆分到多个 YAML 文档中，或者在一次命令中传入多个文件

helm install my-release ./my-chart -f values-base.yaml -f values-override.yaml

Helm 4 能够直接运行 Helm 3 的 Chart，无需修改代码。

安装

  1. 下载 需要的版本

    wget https://get.helm.sh/helm-v3.10.0-linux-amd64.tar.gz

  2. 解压

    tar -xf helm-v3.10.0-linux-amd64.tar.gz

  3. 在解压目中找到 helm 程序，移动到需要的目录中

    cp linux-amd64/helm /usr/local/bin/

  4. 验证

    $ helm version
     version.BuildInfo{Version:"v3.10.0", GitCommit:"ce66412a723e4d89555dc67217607c6579ffcb21", GitTreeState:"clean", GoVersion:"go1.18.6"}

helm 常用管理命令

安装 Release

首先要添加仓库，告诉 Helm 去哪里下载软件包（Chart）。最常用的是 Bitnami 仓库 或者 Artifact Hub

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update

搜索/查看 Repo 中可用的 Charts

$ helm search repo hashicorp/vault
NAME                            	CHART VERSION	APP VERSION	DESCRIPTION                          
hashicorp/vault                 	0.25.0       	1.14.0     	Official HashiCorp Vault Chart       
hashicorp/vault-secrets-operator	0.1.0        	0.1.0      	Official Vault Secrets Operator Chart

安装 Chart，安装时可以为 Release 起个名字（如 vault），也可以不指定名字，让 Helm 自动生成 helm install bitnami/mysql --generate-name

要在安装 Chart 之前自定义配置，可以通过 YAML 配置自定义选项。 要想知道有哪些配置可用，可以使用命令 helm show values 查看

$ helm install vault hashicorp/vault --version 0.25.0
NAME: vault
LAST DEPLOYED: Mon Jul 10 14:59:13 2023
NAMESPACE: default
STATUS: deployed
REVISION: 1
NOTES:
Thank you for installing HashiCorp Vault!

Now that you have deployed Vault, you should look over the docs on using
Vault with Kubernetes available here:

https://www.vaultproject.io/docs/


Your release is named vault. To learn more about the release, try:

  $ helm status vault
  $ helm get manifest vault


$ helm install bitnami/mysql --generate-name
NAME: mysql-1612624192
LAST DEPLOYED: Sat Feb  6 16:09:56 2021
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES: ...

查看 Chart 支持的自定义配置选项

## 先查看已安装的 Repo
$ helm repo list
NAME                	URL                                               
eks                 	https://aws.github.io/eks-charts                  
prometheus-community	https://prometheus-community.github.io/helm-charts

## 查看目标 Repo 中有哪些 Charts
$ helm search repo prometheus-community
NAME                                              	CHART VERSION	APP VERSION	DESCRIPTION                                       
prometheus-community/alertmanager                 	1.33.1       	v0.31.1    	The Alertmanager handles alerts sent by client ...
prometheus-community/alertmanager-snmp-notifier   	2.1.0        	v2.1.0     	The SNMP Notifier handles alerts coming from Pr...
prometheus-community/jiralert                     	1.8.2        	v1.3.0     	A Helm chart for Kubernetes to install jiralert   
prometheus-community/kube-prometheus-stack        	82.1.0       	v0.89.0    	kube-prometheus-stack collects Kubernetes manif...
prometheus-community/kube-state-metrics           	7.1.0        	2.18.0     	Install kube-state-metrics to generate and expo...

## 查看目标 Chart 支持哪些自定义配置选项
$ helm show values prometheus-community/kube-prometheus-stack | more
# Default values for kube-prometheus-stack.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.

## Provide a name in place of kube-prometheus-stack for `app:` labels
##
nameOverride: ""

## Override the deployment namespace
##
namespaceOverride: ""

## Provide a k8s version to auto dashboard import script example: kubeTargetVersionOverride: 1.26.6
##
kubeTargetVersionOverride: ""

## Allow kubeVersion to be overridden while creating the ingress
##
kubeVersionOverride: ""

## Provide a name to substitute for the full names of resources
##
fullnameOverride: ""
...
defaultRules:
  create: true
  rules:
    alertmanager: true
    etcd: true
    configReloaders: true
    general: true
    k8sContainerCpuUsageSecondsTotal: true
    k8sContainerMemoryCache: true
    k8sContainerMemoryRss: true
    k8sContainerMemorySwap: true
    k8sContainerResource: true
    k8sContainerMemoryWorkingSetBytes: true
    k8sPodOwner: true
    kubeApiserverAvailability: true
    kubeApiserverBurnrate: true
    kubeApiserverHistogram: true
    kubeApiserverSlos: true
    kubeControllerManager: true
    kubelet: true
    kubeProxy: true
    kubePrometheusGeneral: true
    kubePrometheusNodeRecording: true
    kubernetesApps: true
    kubernetesResources: true
    kubernetesStorage: true
    kubernetesSystem: true
    kubeSchedulerAlerting: true
    kubeSchedulerRecording: true
    kubeStateMetrics: true
    network: true
    node: true
    nodeExporterAlerting: true
    nodeExporterRecording: true
    prometheus: true
    prometheusOperator: true
    windows: true
...

查看已经安装的 Release 使用了哪些自定义参数，可以使用命令 helm get values <release-name>

$ helm ls -A
NAME                        	NAMESPACE  	REVISION	UPDATED                                	STATUS  	CHART                             	APP VERSION
aws-load-balancer-controller	kube-system	1       	2026-02-17 15:47:38.190164778 +0800 HKT	deployed	aws-load-balancer-controller-3.0.0	v3.0.0     
eks-monitor                 	monitoring 	14      	2026-02-21 02:23:09.462138692 +0000 UTC	deployed	kube-prometheus-stack-82.2.0      	v0.89.0  

$ helm get values -n monitoring eks-monitor
USER-SUPPLIED VALUES:
alertmanager:
  alertmanagerSpec:
    replicas: 1
  config:
    global:
      resolve_timeout: 5m
    receivers:
    - name: "null"
    - name: telegram
      telegram_configs:
      - bot_token: 7750349799:AAE6KDqMIfNE4Pb9WEM2XiIQ50FadioGkW8
        chat_id: -5293873506
        message: "\U0001F6A8 <b>{{ .CommonAnnotations.summary }}</b>\n\n<b>Alert:</b>
          {{ .CommonLabels.alertname }}\n<b>Cluster:</b> {{ .CommonLabels.cluster
          }}\n<b>Namespace:</b> {{ .CommonLabels.namespace }}\n<b>Severity:</b> {{
          .CommonLabels.severity }}\n\n<b>Description:</b>\n{{ .CommonAnnotations.description
          }}\n"
        parse_mode: HTML
        send_resolved: false
    route:
      group_by:
      - alertname
      - cluster
      group_wait: 10s
      receiver: telegram
      repeat_interval: 1h
  enabled: true
defaultRules:
  disabled:
    KubeCPUOvercommit: true
    KubeMemoryOvercommit: true
grafana:
  enabled: false
...

查看所有已安装的 Release

$ helm list -A
NAME                        	NAMESPACE  	REVISION	UPDATED                                  	STATUS  	CHART                             	APP VERSION
aws-load-balancer-controller	kube-system	1       	2026-02-17 15:47:38.190164778 +0800 +0800	deployed	aws-load-balancer-controller-3.0.0	v3.0.0     
eks-monitor                 	monitoring 	14      	2026-02-21 02:23:09.462138692 +0000 UTC  	deployed	kube-prometheus-stack-82.2.0      	v0.89.0

卸载指定的 Release

$ helm ls -A
NAME        	NAMESPACE    	REVISION	UPDATED                                	STATUS	CHART                APP VERSION
cert-manager	cert-manager 	1       	2022-11-01 09:57:11.373366484 +0800 CST	failed	cert-manager-v1.7.1  v1.7.1     
rancher     	cattle-system	1       	2022-11-01 10:05:07.370131566 +0800 CST	failed	rancher-2.6.9        v2.6.9     

$ helm uninstall rancher -n cattle-system
W1101 10:21:32.764269   11113 warnings.go:70] policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
W1101 10:21:34.043445   11113 warnings.go:70] policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
W1101 10:21:39.809766   11113 warnings.go:70] policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
release "rancher" uninstalled

更新指定的 Release

helm upgrade my-web bitnami/nginx -f my-values.yaml

helm upgrade --install my-web bitnami/nginx -f my-values.yaml

回滚到上一个 Release 版本

回滚使用命令 helm rollback [RELEASE] [REVISION] ，可以通过命令 helm history [RELEASE]

每次 install, upgrade, rollback 都会更新 REVISOION

$ helm list -A
NAME                        	NAMESPACE  	REVISION	UPDATED                                	STATUS  	CHART                             	APP VERSION
aws-load-balancer-controller	kube-system	1       	2026-02-17 15:47:38.190164778 +0800 HKT	deployed	aws-load-balancer-controller-3.0.0	v3.0.0     
eks-monitor                 	monitoring 	14      	2026-02-21 02:23:09.462138692 +0000 UTC	deployed	kube-prometheus-stack-82.2.0      	v0.89.0

$ helm history eks-monitor -n monitoring
REVISION	UPDATED                 	STATUS    	CHART                       	APP VERSION	DESCRIPTION     
5       	Thu Feb 19 15:21:40 2026	superseded	kube-prometheus-stack-82.1.0	v0.89.0    	Upgrade complete
6       	Thu Feb 19 15:24:23 2026	superseded	kube-prometheus-stack-82.1.0	v0.89.0    	Upgrade complete
7       	Thu Feb 19 15:34:16 2026	superseded	kube-prometheus-stack-82.1.0	v0.89.0    	Upgrade complete
8       	Thu Feb 19 15:37:33 2026	superseded	kube-prometheus-stack-82.1.0	v0.89.0    	Upgrade complete
9       	Thu Feb 19 15:40:24 2026	superseded	kube-prometheus-stack-82.1.0	v0.89.0    	Upgrade complete
10      	Thu Feb 19 15:46:54 2026	superseded	kube-prometheus-stack-82.1.0	v0.89.0    	Upgrade complete
11      	Thu Feb 19 17:29:21 2026	superseded	kube-prometheus-stack-82.1.0	v0.89.0    	Upgrade complete
12      	Sat Feb 21 02:00:26 2026	superseded	kube-prometheus-stack-82.2.0	v0.89.0    	Upgrade complete
13      	Sat Feb 21 02:10:58 2026	superseded	kube-prometheus-stack-82.2.0	v0.89.0    	Upgrade complete
14      	Sat Feb 21 02:23:09 2026	deployed  	kube-prometheus-stack-82.2.0	v0.89.0    	Upgrade complete

$ helm rollback eks-monitor -n monitoring 13

要在更新（upgrade）或者回滚（rollback）后强制重建 Pod，可以使用选项 --recreate-pods

查看已添加的的 Repo

$ helm repo ls
NAME          	URL                                              
rancher-stable	https://releases.rancher.com/server-charts/stable
jetstack      	https://charts.jetstack.io                       
hashicorp     	https://helm.releases.hashicorp.com

查看已安装的 Repo 中可用的 Charts

$ helm search repo hashicorp/vault -l
NAME                            	CHART VERSION	APP VERSION	DESCRIPTION                               
hashicorp/vault                 	0.25.0       	1.14.0     	Official HashiCorp Vault Chart            
hashicorp/vault                 	0.24.1       	1.13.1     	Official HashiCorp Vault Chart            
hashicorp/vault                 	0.24.0       	1.13.1     	Official HashiCorp Vault Chart            
hashicorp/vault                 	0.23.0       	1.12.1     	Official HashiCorp Vault Chart            
hashicorp/vault                 	0.22.1       	1.12.0     	Official HashiCorp Vault Chart            
hashicorp/vault                 	0.22.0       	1.11.3     	Official HashiCorp Vault Chart

$ helm search repo 
NAME                                              	CHART VERSION	APP VERSION	DESCRIPTION                                       
prometheus-community/alertmanager                 	1.33.1       	v0.31.1    	The Alertmanager handles alerts sent by client ...
prometheus-community/alertmanager-snmp-notifier   	2.1.0        	v2.1.0     	The SNMP Notifier handles alerts coming from Pr...
prometheus-community/jiralert                     	1.8.2        	v1.3.0     	A Helm chart for Kubernetes to install jiralert   
prometheus-community/kube-prometheus-stack        	82.2.0       	v0.89.0    	kube-prometheus-stack collects Kubernetes manif...
prometheus-community/kube-state-metrics           	7.1.0        	2.18.0     	Install kube-state-metrics to generate and expo...
prometheus-community/prom-label-proxy             	0.17.2       	v0.12.1    	A proxy that enforces a given label in a given ...
prometheus-community/prometheus                   	28.9.1       	v3.9.1     	Prometheus is a monitoring system and time seri...
prometheus-community/prometheus-adapter           	5.3.0        	v0.12.0    	A Helm chart for k8s prometheus adapter

helm search hub 可以搜索 Artifact Hub 中公开可用的 Charts

$ helm search hub wordpress
URL                                                 CHART VERSION APP VERSION DESCRIPTION
https://hub.helm.sh/charts/bitnami/wordpress        7.6.7         5.2.4       Web publishing platform for building blogs and ...
https://hub.helm.sh/charts/presslabs/wordpress-...  v0.6.3        v0.6.3      Presslabs WordPress Operator Helm Chart
https://hub.helm.sh/charts/presslabs/wordpress-...  v0.7.1        v0.7.1      A Helm chart for deploying a WordPress site on ...

不指定名称搜索 helm search hub 将会列出 Artifact Hub 上所有可用的 Charts 链接（不是具体的 Helm Reop），要展示 Helm Repo 可以使用选项 helm search hub --list-repo-url

查看 Release 状态

$ helm list -A
NAME                        	NAMESPACE  	REVISION	UPDATED                                	STATUS  	CHART                             	APP VERSION
aws-load-balancer-controller	kube-system	1       	2026-02-17 15:47:38.190164778 +0800 HKT	deployed	aws-load-balancer-controller-3.0.0	v3.0.0     
eks-monitor                 	monitoring 	14      	2026-02-21 02:23:09.462138692 +0000 UTC	deployed	kube-prometheus-stack-82.2.0      	v0.89.0    

$ helm status eks-monitor -n monitoring
NAME: eks-monitor
LAST DEPLOYED: Sat Feb 21 02:23:09 2026
NAMESPACE: monitoring
STATUS: deployed
REVISION: 14
TEST SUITE: None
NOTES:
kube-prometheus-stack has been installed. Check its status by running:
  kubectl --namespace monitoring get pods -l "release=eks-monitor"

Get Grafana 'admin' user password by running:

  kubectl --namespace monitoring get secrets eks-monitor-grafana -o jsonpath="{.data.admin-password}" | base64 -d ; echo

Access Grafana local instance:

  export POD_NAME=$(kubectl --namespace monitoring get pod -l "app.kubernetes.io/name=grafana,app.kubernetes.io/instance=eks-monitor" -oname)
  kubectl --namespace monitoring port-forward $POD_NAME 3000

Get your grafana admin user password by running:

  kubectl get secret --namespace monitoring -l app.kubernetes.io/component=admin-secret -o jsonpath="{.items[0].data.admin-password}" | base64 --decode ; echo


Visit https://github.com/prometheus-operator/kube-prometheus for instructions on how to create & configure Alertmanager and Prometheus instances using the Operator.


$ helm status aws-load-balancer-controller -n kube-system
NAME: aws-load-balancer-controller
LAST DEPLOYED: Tue Feb 17 15:47:38 2026
NAMESPACE: kube-system
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
AWS Load Balancer controller installed!

查看 Chart 的具体信息

使用命令 helm show chart 或则 helm show all 查看 Chart 详细信息，里面包含了关于 Chart 配置的详细信息和结构。

$ helm show chart prometheus-community/prometheus
annotations:
  artifacthub.io/license: Apache-2.0
  artifacthub.io/links: |
    - name: Chart Source
      url: https://github.com/prometheus-community/helm-charts
    - name: Upstream Project
      url: https://github.com/prometheus/prometheus
apiVersion: v2
appVersion: v3.9.1
dependencies:
- condition: alertmanager.enabled
  name: alertmanager
  repository: https://prometheus-community.github.io/helm-charts
  version: 1.33.*
- condition: kube-state-metrics.enabled
  name: kube-state-metrics
  repository: https://prometheus-community.github.io/helm-charts
  version: 7.1.*
- condition: prometheus-node-exporter.enabled
  name: prometheus-node-exporter
  repository: https://prometheus-community.github.io/helm-charts
  version: 4.51.*
- condition: prometheus-pushgateway.enabled
  name: prometheus-pushgateway
  repository: https://prometheus-community.github.io/helm-charts
  version: 3.6.*
description: Prometheus is a monitoring system and time series database.
...


Chart 结构

当你想要自己写 Chart 时，你会看到这样的文件夹结构（使用 helm create my-chart 生成）：

my-chart/
├── Chart.yaml          # 项目信息（版本、描述）
├── values.yaml         # 默认配置（最核心文件！所有的变量都写在这里）
├── charts/             # 依赖的其他子 Chart
└── templates/          # YAML 模板文件夹
    ├── deployment.yaml # K8s 资源模板
    └── service.yaml    # 暴露服务的模板

发表于 更新于 上层目录 ，

AWS 虚拟私有云 VPC

在进入具体的网络配置前，必须理解 AWS 的地理隔离：

  • 区域 (Region) ：地理上的独立区域（如新加坡、弗吉尼亚）。区域之间完全隔离。

  • 可用区 (Availability Zone, AZ) ：一个区域内由多个物理机房组成。AZ 之间通过高速、低延迟光纤连接。高可用架构必须跨 AZ 部署。跨 AZ 之间的流量需要付费。

VPC 是你在 AWS 云中的逻辑隔离网络。你可以完全控制其 IP 地址范围、子网、路由表和网络网关。

核心组件：

  • CIDR 范围 ：你为 VPC 定义的私有 IP 地址块（如 10.0.0.0/16 ）。

  • 子网 (Subnets) ：将 VPC 划分为更小的网段。子网必须位于特定的可用区内。

  • 公有子网 (Public Subnet) ：路由指向互联网网关 (IGW)，实例可以有公网 IP。

  • 私有子网 (Private Subnet) ：没有指向 IGW 的直接路由，通常通过 NAT 网关 访问外网 。

公有子网 和 私有子网 在配置上几乎一摸一样，唯一区别在于： 该子网关联的路由表（Route Table）中默认路由（0.0.0.0/0）是如何配置的。

  • 公有子网 (Public Subnet) 其路由表中默认路由（0.0.0.0/0）指向 互联网网关 (Internet Gateway, ID 格式通常为 igw-xxxxxx) 。由于它直接连接到互联网大门，且子网内的实例拥有公网 IP，因此外部用户可以主动访问它，它也可以直接访问外部。
  • 私有子网 (Private Subnet) 其路由表中默认路由（0.0.0.0/0）指向 NAT 网关 (NAT Gateway, ID 格式通常为 nat-xxxxxx)，或者干脆没有任何去往外网的路由 。它没有直通互联网的大门。它通过 NAT 网关（单向出口）实现“能出不能进”的效果。
    下图所示子网为 公有子网

  • 路由表（Route Tables） 分为主路由表和自定义路由表
    • 主路由表（Main route table） 随 VPC 自动生成，它控制未与任何其他路由表显式关联的所有子网的路由，也就是 VPC 中的默认路由。
    • 自定义路由表 为新建的路由表。
    • 一个子网只能关联一个路由表，一个路由表可以关联多个子网

流量如何进出

VPC 与外界互联网通信可以使用以下方式：

组件 作用 流量方向 用法说明｜
Internet Gateway (IGW，互联网网关) 允许 VPC 连接互联网。 双向 (In/Out) 实例必须分配公网 IP 或弹性 IP (EIP)
NAT Gateway (NAT 网关) 允许私有实例上外网，但防止外部主动连接。 单向 (Outbound only) 仅需私有 IP
VPC Peering （对等连接） 连接两个不同的 VPC，使其像在一个网络内通信。 跨 VPC
Transit Gateway 充当“中央枢纽”，连接数千个 VPC 和本地网络。 复杂网络拓扑
Virtual Private Gateway 用于建立 VPN 连接。 混合云

部署 NAT Gateway 网关并关联子网

通过 NAT Gateway 可以实现子网中的实例的对外互联网出口 IP 都是 NAT Gateway 绑定的 EIP，子网中的实例对互联网不可见。NAT Gateway 典型使用场景：

  • 为了安全，生产环境通常将 EKS 工作节点、RDS 数据库 或 缓存服务器（Redis） 放在私有子网中，这些资源不需要（也不应该）被互联网直接访问。
  • 应用需要调用外部服务（如支付网关、银行接口或第三方 API）时，对方的防火墙通常需要你提供一个白名单 IP。由于 EKS 节点是动态变化的，IP 并不固定。
  • 减少受攻击面，防止外部扫描。

以下为创建 NAT Gateway 并关联子网的相关步骤：

正确的整体架构
VPC
├── Public Subnet
│   ├── NAT Gateway（有 EIP）
│   └── Route Table (Public RT)
│       └── 0.0.0.0/0 → Internet Gateway
│
└── Private Subnet
    ├── EC2 / ECS / EKS Node
    └── Route Table (Private RT)
        └── 0.0.0.0/0 → NAT Gateway

关键点：

  • NAT Gateway 必须在公有子网
  • 私有子网的默认路由指向 NAT Gateway

  1. 确认 Public Subnet 存在

    VPC 默认的 Main Route Table 已经满足这个条件，其默认网关为 Internet Gateway

  2. 创建 NAT Gateway

    在 NAT gateways 标签页面中，点击 Create NAT gateway ， Connectivity type 选择 Public ， Elastic IP (EIP) association 选择 手动分配 EIP（Manual）

    创建完成后，状态应为 Available 。在路由表（Route Tables）中，这时会多一个路由表，其 Edge associations（边缘关联） 关联到了刚刚创建的 NAT Gateway

  3. 创建一个新的子网（私有、Private Subnet）

    在 VPC → Subnets → Create subnet 标签页面中创建新的子网， 不要勾选 Auto-assign public IPv4 ，如此处于此子网中的实例，不会为其分配公网地址

  4. 创建 Private Route Table

    在 VPC → Route tables → Create route table 标签页面中创建新的路由表，本示例名为 private-rt

  5. 配置路由规则

    选择刚刚创建的新路由表 private-rt，在 Routes 中 编辑路由（Edit Routes） ，添加一条路由规则： 

    | Destination | Target          |
    | ----------- | --------------- |
    | 0.0.0.0/0   | NAT Gateway |

  6. 关联 Private Subnet

    选择刚刚创建的新路由表 private-rt，在 Subnet associations(子网关联) 中 Edit subnet associations（编辑子网关联） ，选择目标子网进行关联

  7. 最终的 VPC 整体路由可以在 VPC 的 Resource map 中进行检查

EKS 中的授权机制

Kubernetes 原生提供 RBAC（Role-Based Access Control） 来控制集群中的 用户和服务账户（ServiceAccount） 对资源的访问权限。

对象 描述
Role 命名空间级别（Namespace）权限，指定某个命名空间内允许的操作和资源类型。
ClusterRole 集群级别权限，可以跨命名空间使用。
RoleBinding 将 Role 绑定到一个用户或 ServiceAccount。
ClusterRoleBinding 将 ClusterRole 绑定到一个用户或 ServiceAccount。

核心字段

  • apiGroups ：资源所属 API 组，例如 "" 代表 core API 。

  • resources ：允许访问的资源类型，如 pods、deployments。

  • verbs ：允许的操作，如 get, list, create, delete 。

RBAC 示例：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: dev
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: dev
subjects:
  - kind: ServiceAccount
    name: my-serviceaccount
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

  • RBAC 控制的是 Kubernetes 资源访问权限 。

  • RBAC 对象绑定的是 Kubernetes 用户或 ServiceAccount，而不是 AWS IAM 用户 。

概念 全称 解决的问题 作用范围
RBAC Role-Based Access Control 决定 “用户/进程” 在 K8s 集群内能做什么（如：查看 Pod） K8s 集群内部
Role Kubernetes Role RBAC 的一部分，定义一组具体的集群内操作权限 命名空间 (Namespace)
IRSA IAM Roles for Service Accounts 决定 “Pod 里的应用” 对 AWS 外部资源（如 S3/RDS）的访问权限 AWS 云环境

AWS IAM Role 是 AWS 层面的权限机制，用于授权 AWS 资源访问，例如 S3、DynamoDB、Secrets Manager 等。

AWS IAM Role 的特点：

  • 可以被 IAM 用户、服务或 EC2/EKS Pod 假设（Assume）。

  • 权限通过 IAM Policy 定义。

AWS IAM Role 在 EKS 中的应用:

  • 管理集群本身访问 AWS 资源，例如节点组（NodeGroup）访问 S3。

  • 可以通过 IAM 用户/Role 管理集群级别的操作权限，例如 eks:DescribeCluster 。

💡 核心点：IAM Role 本身无法直接控制 Kubernetes 资源，它管理的是 AWS 资源访问。

IRSA（IAM Roles for Service Accounts） 是 AWS EKS 引入的将 Kubernetes ServiceAccount 与 AWS IAM Role 绑定，实现 Pod 级别的 AWS 权限控制的机制。其大致原理如下：

  • EKS 集群开启 OIDC Provider
  • 创建 IAM Role 并信任该 OIDC Provider
  • Role 上定义 IAM Policy（如访问 S3）
  • Kubernetes ServiceAccount 指定注解 eks.amazonaws.com/role-arn。
  • Pod 使用该 ServiceAccount 时自动获取 Role 权限

实践建议：

  • 不要在 Pod 内放 AWS AccessKey，使用 IRSA。

  • 最小权限原则：

    • RBAC：只给 Pod 或用户真正需要的 Kubernetes 权限。

    • IAM Role / IRSA：只给访问 AWS 资源的最小权限。

  • 多集群管理：可以通过 ClusterRole + RoleBinding 管理跨命名空间权限。

  • 审计：

    • 使用 CloudTrail 监控 IRSA 调用。

    • Kubernetes API Server 日志审计 RBAC 权限。

发表于 更新于 上层目录 ，

EKS 集群特性总结

  • 节点的 IP 地址（EXTERNAL-IP 和 INTERNAL-IP）不固定，会变化。特别是在自治模式中，节点被视为 临时资源（Ephemeral） ，可能会频繁地进行节点池优化。

    如果集群需要固定的出口 IP，最推荐，最标准的做法是 使用 NAT 网关 ，将 EKS 节点部署在私有子网中，所有访问外部网络的流量都会经过 NAT 网关

通过 AWS 管理控制台部署 EKS 集群

  • Kubernetes 版本： v1.35

本示例中使用 EKS 自治模式（EKS Auto Mode）

EKS 自治模式 接管了原本需要手动管理的节点、存储和网络配置，因此它需要一组非常具体且强大的权限

EKS 自治模式 有额外的费用，大概比 EC2 价格高 12%

EKS 自治模式 在集群创建完成后可修改（编辑）为非自治模式

EKS 自治模式 中的 Worker Nodes 配置 不能在控制台修改参数、不能自定义 ，具体的配置可以通过 API 接口查看 nodepool 资源

# kubectl describe nodepool general-purpose
Name:         general-purpose
Namespace:    
Labels:       app.kubernetes.io/managed-by=eks
Annotations:  karpenter.sh/nodepool-hash: 4012513481623584108
              karpenter.sh/nodepool-hash-version: v3
API Version:  karpenter.sh/v1
Kind:         NodePool
Metadata:
  Creation Timestamp:  2026-02-06T09:38:18Z
  Generation:          1
  Resource Version:    784637
  UID:                 e85261b9-3a4b-41b0-ac5...
Spec:
  Disruption:
    Budgets:
      Nodes:               10%      # 这是一个安全阀。在同一时间内，由于缩容或更新导致的节点离线比例不能超过 10%。这保证了你的集群不会因为自动优化而导致业务大面积中断。
    Consolidate After:     30s      # 节点达到上述状态 30 秒后，EKS 就会考虑将其关闭，并把上面的 Pod 迁移到更划算的节点上。
    Consolidation Policy:  WhenEmptyOrUnderutilized    # 当节点变为空闲（没有 Pod）或者利用率较低（比如一个大节点只跑了一个小 Pod）时，EKS 会自动触发节点合并。
  limits:      # 资源限制
    cpu: "1000"
    memory: 1000Gi
  Template:
    Metadata:
    Spec:
      Expire After:  336h   # 节点的最大“寿命”是 14 天（336 小时），强制节点定期更换，以确保所有节点都运行在最新的安全补丁和 Bottlerocket 镜像上，防止出现长期未重启的“僵尸节点”。
      Node Class Ref:     # nodeclass 信息，可通过 kubectl get nodeclass 查看
        Group:  eks.amazonaws.com
        Kind:   NodeClass
        Name:   default
      Requirements:        # 节点选择标准 (Requirements)
        Key:       karpenter.sh/capacity-type     # 实例类型，on-demand 为 按需实例
        Operator:  In
        Values:
          on-demand
        Key:       eks.amazonaws.com/instance-category     # 限定了实例系列   c: 计算优化型（适合高并发）； m: 通用型（平衡 CPU 和内存）； r: 内存优化型（适合数据库或缓存）。   
        Operator:  In
        Values:
          c
          m
          r
        Key:       eks.amazonaws.com/instance-generation     # 只使用 4 代以后的机型（如 c5, m6i 等）。这确保了节点拥有较新的硬件特性和性能。
        Operator:  Gt
        Values:
          4
        Key:       kubernetes.io/arch    # CPU 架构。如果你想尝试性价比更高的 ARM 架构（Graviton），需要在这里添加 arm64
        Operator:  In
        Values:
          amd64
        Key:       kubernetes.io/os   # 节点操作系统（OS）类型
        Operator:  In
        Values:
          linux
      Termination Grace Period:  24h0m0s

EKS 自治模式限制资源上限 编辑 NodePool，修改 spec.limits.cpu 和 spec.limits.memory 。这决定了该池子最多能“烧”掉多少 EC2 资源。

强制回收节点 ： 如果你想让 EKS 重新平衡节点（例如你更改了实例限制），可以手动删除节点，Auto Mode 会自动根据 Pod 需求拉起符合新规的新节点

kubectl delete node <node-name>

同时要关注 nodeclass 资源，其中定义了 子网（Subnet）和安全组（Security Group）等信息

# kubectl get nodeclass
NAME      ROLE          READY   AGE
default   eksNodeRole   True    44h


# kubectl  describe nodeclass default
Name:         default
Namespace:    
Labels:       app.kubernetes.io/managed-by=eks
Annotations:  eks.amazonaws.com/nodeclass-hash: 13740036326424352917
              eks.amazonaws.com/nodeclass-hash-version: v2
API Version:  eks.amazonaws.com/v1
Kind:         NodeClass
Metadata:
  Creation Timestamp:  2026-02-06T09:38:18Z
  Finalizers:
    eks.amazonaws.com/termination
  Generation:        2
  Resource Version:  827607
  UID:               5065b0f3-3795-4347-893a-338ae6fa882d
Spec:
  Ephemeral Storage:
    Iops:                     3000
    Size:                     80Gi
    Throughput:               125
  Network Policy:             DefaultAllow
  Network Policy Event Logs:  Disabled
  Role:                       eksNodeRole
  Security Group Selector Terms:
    Id:         sg-058bd1ef...
  Snat Policy:  Random
  Subnet Selector Terms:
    Id:  subnet-07963d9b...
    Id:  subnet-0e359aac...
    Id:  subnet-0e76c601...
阅读全文 »

发表于 更新于 上层目录 ，

AWS OpenSearch 是一个完全开源的搜索和分析引擎，用于日志分析、实时应用程序监控和点击流分析等用例。

AWS OpenSearch（AOS） 和 Elasticsearch 对比

OpenSearch Elasticsearch
背景 AWS 主导的开源分支 Elastic 公司主导
授权 Apache 2.0 SSPL + Elastic License
商业控制 社区驱动 公司控制
K8s 生态 非常友好 也支持
云原生趋势 越来越主流 商业版更强
日志检索 很强 很强
向量搜索 有 更成熟
ML 功能 有 更强
APM 基础 商业版更强
插件生态 少一些 更丰富

原本是同一个项目

2021 年因授权问题分叉

👉 7.10 是最后一个纯开源 Elasticsearch 版本
之后 AWS fork 出：

🔹 OpenSearch

而原厂继续发展：

🔹 Elasticsearch

在 AWS 上，Amazon 托管服务默认是 OpenSearch。

创建 OpenSearch 域 (AOS)

  • AWS OpenSearch Service Version： v 3.3.0

OpenSearch 服务域是 OpenSearch 集群的同义词.域是包含您指定的设置、实例类型、实例计数和存储资源的集群。
登录控制台：前往 Amazon OpenSearch Service。 Domains -> Create domain 。

  • 填写 域（Domain）名称
  • 选择 标准创建
  • 选择实例类型和数量
  • 网络选项包含 2 种，创建集群后不能再变更：
    • VPC 访问，此中方式创建的 Domain 只支持 VPC 内部访问，不支持互联网公开访问，如果要互联网访问，可以通过在 VPC 内部使用 Nginx 代理。
    • 公开访问权限，允许互联网访问

使用 公开访问权限 部署的 AOS，可以直接使用 OpenSearch 控制面板 URL 在互联网访问。如果要控制访问，可以使用以下方法：

  • 修改 集群访问策略 (Access Policy)

    1. 进入 Amazon OpenSearch Service 控制台，点击进入你的 Domain (网域) 。
    2. 点击 Security configuration (安全配置) 选项卡。
    3. 滚动到 Access policy (访问策略) 部分。
    4. 在 JSON 编辑框中，添加基于 IpAddress 的 Condition 。 
      {
        "Version": "2012-10-17",
        "Statement": [
          {
            "Effect": "Allow",
            "Principal": {
              "AWS": "*"
            },
            "Action": "es:*",
            "Resource": "arn:aws:es:ap-southeast-1:你的账号ID:domain/你的域/*",
            "Condition": {
              "IpAddress": {
                "aws:SourceIp": [
                  "1.2.3.4/32",     // 你办公室的公网出口 IP
                  "5.6.7.8/32"      // EKS 节点的公网出口 IP (NAT Gateway EIP)
                ]
              }
            }
          }
        ]
      }
阅读全文 »

发表于 更新于 上层目录

环境信息

  • Docker 26.1.1
  • Confluence Image： haxqer/confluence:9.0.2
  • Jira Image： atlassian/jira-software:9.12.11
  • postgresql 13

配置流程

创建项目所需新目录，用于存储持久化数据

# mkdir -p /opt/devops/{confluence,jira,postgresql}

下载 atlassian-agent.jar 文件，将其分别放置在 ./confluence/atlassian-agent.jar 和 ./jira/atlassian-agent.jar ，用于之后为 Confluence 和 Jira 生成 License

docker-compose.yaml 文件内容如下

docker-compose.yaml
services:
  # --- 数据库服务 ---
  postgres-db:
    image: postgres:13
    container_name: devops-postgres-db
    volumes:
      - ./postgresql:/var/lib/postgresql/data
    environment:
      - POSTGRES_USER=postgres
      - POSTGRES_PASSWORD=<PG_PASSWORD>
      - POSTGRES_DB=confluence
    healthcheck:
      test: ["CMD-SHELL", "pg_isready"]
      interval: 10s
      timeout: 5s
      retries: 5     
    networks:
      - devops-net


  # --- Confluence ---
  confluence:
    image: haxqer/confluence:9.0.2
    container_name: confluence
    depends_on:
      postgres-db:
        condition: service_healthy
    ports:
      - "8090:8090"
      - "8091:8091"
    environment:
      - ATL_JDBC_USER=postgres
      - ATL_JDBC_PASSWORD=<PG_PASSWORD>
      - ATL_JDBC_URL=jdbc:postgresql://postgres-db:5432/confluence
      - ATL_DB_TYPE=postgresql
      - JVM_MINIMUM_MEMORY=2048m
      - JVM_MAXIMUM_MEMORY=4096m
      - TZ='Asia/Shanghai'
    volumes:
      - ./confluence:/var/confluence
    networks:
      - devops-net
  
  # --- Jira ---
  jira:
    image: atlassian/jira-software:9.12.11
    container_name: jira
    depends_on:
      postgres-db:
        condition: service_healthy
    ports:
      - "8080:8080" # Jira 默认端口
    environment:
      - ATL_JDBC_USER=postgres
      - ATL_JDBC_PASSWORD=<PG_PASSWORD>
      - ATL_JDBC_URL=jdbc:postgresql://postgres-db:5432/jira  # 注意这里是指向新创建的 jira 库
      - ATL_DB_TYPE=postgresql
      - JVM_MINIMUM_MEMORY=2048m
      - JVM_MAXIMUM_MEMORY=4096m
      - TZ='Asia/Shanghai'
      - JVM_SUPPORT_RECOMMENDED_ARGS=-javaagent:/var/atlassian/application-data/jira/atlassian-agent.jar
    volumes:
      - ./jira:/var/atlassian/application-data/jira
    networks:
      - devops-net

networks:
  devops-net:
    driver: bridge

启动容器

# docker compose up -d

postgres 数据库启动正常后，执行以下命令为 Jira 创建数据库，Confluece 数据库在容器启动是会自动创建。

docker compose exec -it postgres-db psql -U postgres -c "CREATE DATABASE jira WITH ENCODING='UTF8' LC_COLLATE='en_US.utf8' LC_CTYPE='en_US.utf8' CONNECTION LIMIT=-1;"

Confluence 初始化部署

浏览器访问 http://<IP>:8090 在 Confluence 初始化页面拿到 Server ID

登录 Confluence 容器，执行以下命令获取破解得 License

# docker compose exec -it confluence bash
root@81d2f5a8f7e5:/opt/confluence# java -jar /var/agent/atlassian-agent.jar -d -p conf -m [email protected] -n [email protected]  -o your-org -s B66H-ET1W-2LYR-Q7R2

====================================================
=======     Atlassian Crack Agent v1.3.1     =======
=======           https://zhile.io           =======
=======          QQ Group: 30347511          =======
====================================================

Your license code(Don't copy this line!!!): 

AAABmA0ODAoPeJxtUVuPojAUfu+vINlnFKoLaNJkHWBWZwEZxbk8FjxII7akFBz21y8ik00mk/Sl5
7Tf9UdSNNoT5RrGmuEsZ3g5m2u/w0TDBraQK4EqJrhHFZDbRDdMHWPkt7Rshg3JaVkD8qDOJKuGy
YGX7MIUHLWSZcBr0NJOK5Sq6uV0+rdgJUyYQFt5opzVd5BONFIX8oQywfMJzRRrgSjZAHIFV/3dD
ykryRrKUvy6ClkeJ5m4oBF/TeuChO7VfXxczdPjayzCPG9e/NxN8dP845x4cbxeFc/VWwPTFrfRG
zarNGni0+HP+WotwmhFyJ16r6hUIEdXwyi4kyRdBRG9AHG3Yejv3M0qQL0oroBTnoH/UTHZjTk5C
92w+4PGvxuPBBtv70d6YNrWwrAN++fcdhy0B9mC7NcPlrXW/cR81XHwvtOf7R2+s/eI1AV+0zTkc
YbuBWR9C820jB7Jmc3MT57vRcSNzApaw9cSx/Q+4TDaN+n/Fge2QULUXFKQ2/xQ9y+JbqLeCPnGz
FjVENKXpv4BHKbJjjAtAhRlC24D9XOs3Z9LZwzE3PehVo5lhgIVAIaOykfNKCdhuAZn7PZsJR+qr
edbX02jn

命令参数说明：

-d 调试模式 必选，用于输出生成的许可证信息。

-m 电子邮箱 随便填 ，如 [email protected]。

-n 用户名 随便填 ，如 Organization_Admin。

-p 产品标识 不可乱填 。Confluence 是 conf ，Jira 是 jira ，Bitbucket 是 bitbucket 。

-o 组织/URL 建议填你的访问地址，如 https://wiki.mysite.com 。

-s Server ID 核心参数。必须填 Web 页面上显示的那个 16 位代码 。

License 验证成功后，填写数据库连接信息并测试连接成功

Jira 初始化部署

浏览器访问 http://<IP>：8080 打开 Jira 初始化页面，在 Jira setup 中选择 I'll set it up myself 。因为后面要指定数据库信息，因此要选择自定义。

根据提示填入数据库连接信息，测试无误后，到 Specify your license key 页面，复制 Server ID

登入 jira 容器，使用以下命令为 Jira 生成 License

root@69487899ebea:/var/atlassian/application-data/jira# java -jar /var/atlassian/application-data/jira/atlassian-agent.jar -d -p jira -m [email protected] -n [email protected]  -o your-org -s BYTU-X57R-U6U3-LSIB

====================================================
=======     Atlassian Crack Agent v1.3.1     =======
=======           https://zhile.io           =======
=======          QQ Group: 30347511          =======
====================================================

Your license code(Don't copy this line!!!): 

AAAB5Q0ODAoPeJyNU9GSmjAUfecrmOkzboKuqDOZ6YpYmQW0onb7GPEK2SKhSdDFry8K2+6q43QmL
8ncc+455958+QEbfQxrHWMddQcmGpgd/Zu/0E1kdrVYAGQJz3MQLY9FkElYlDkEdAfEnvq+M7fdJ
0+zBVDFeDaiCsgJaCDTwFi7AxmBjATLTyiyzFK2Y6oSktYAfV3qiVK5HDw8HBOWQotxzacsU5DRL
ALnLWeibLr1+gayqqO9MkHfVTobVlMHnuu7C2ekBcVuDWK6XUoQkhh/xd3hygXfFJFqnS6G5Ft1o
AJaV0R3ammk2B6IEgV8yvLj+x14pYraULkWdWkTz6pqfDJnamGx/hfjucTZ07Q4D4NsaSob+kuiq
YhpxmRdV/JCGFzEms0zVSlzqqRTMoE05V8PXKSbVsR3Nc+V90bRhMqE+PbBHk/i+W8c8mdIO8fiu
UBHvJj23KHnhqun5DvDc0f1VsfZMB6/vqDH/jHocJaUMxQTUrf4z2hCRcXJTm2ymaU7Ip47Cp3A8
LBlIauPeman38GfVuPWNoYg9iAq+PDnYmm8PFpzY9ldtg0vdIfaLyjfE8ddhCzUa7fxra9xvXSzQ
kQJlXD5MT6Cz2PJBZON6Uo+uWGhGc5Z+cVs/gCvg0phMC0CFBCTfaevRY4wQYedPfgvyTwghlJmA
hUAlodnLvDqtFh/z+wXjAncJwqlqNc=X02n3


注意其中的参数 -p jira

根据提示完成其他配置即可开始使用 Jira。

Confluence 迁移

部署好相同版本的 Confluence 和 PostgreSQL 环境，

在开始之前，请确保：

  • 停止旧环境和新环境的 Confluence 容器，以保证数据一致性。
  • 确认新环境的 PostgreSQL 13 已经启动，并创建了一个空的数据库（例如名为 confluence ）。

  1. 迁移 PostgreSQL 数据库

    由于版本一致，直接使用 pg_dump 是最稳妥的方案。

    docker exec -t <旧数据库容器名> pg_dump -U <用户名> <数据库名> > confluence_db.sql

    先删除新环境中的数据库 confluence，再新建

    # psql -h <HOST> -U postgres -d postgres

    postgres=> \l
                                      List of databases
        Name    |  Owner   | Encoding |   Collate   |    Ctype    |   Access privileges   
    ------------+----------+----------+-------------+-------------+-----------------------
     confluence | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 | 
     jira       | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 | 
     postgres   | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 | 
     rdsadmin   | rdsadmin | UTF8     | en_US.UTF-8 | en_US.UTF-8 | rdsadmin=CTc/rdsadmin
     template0  | rdsadmin | UTF8     | en_US.UTF-8 | en_US.UTF-8 | =c/rdsadmin          +
                |          |          |             |             | rdsadmin=CTc/rdsadmin
     template1  | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 | =c/postgres          +
                |          |          |             |             | postgres=CTc/postgres
    (6 rows)

    postgres=> DROP DATABASE confluence;
    DROP DATABASE
    postgres=> 

    postgres=> CREATE DATABASE confluence;
    CREATE DATABASE

    然后导入备份数据，将 confluence_db.sql 拷贝到新服务器，然后执行：

    cat confluence_db.sql | docker exec -i <新数据库容器名> psql -U <用户名> -d <数据库名>

  2. 迁移 Confluence Home 目录

    Confluence 的用户附件、索引、插件配置等都存储在 Home 目录下。进入旧服务器的映射目录，执行

    tar -zcvf confluence_home_backup.tar.gz /path/to/old/confluence_home

    将备份文件传输到新 Confluence 环境 Home 目录并解压

  3. 修改配置文件（如果数据库连接变了）

    如果新环境的数据库 IP、端口或密码与旧环境不同，你需要修改新环境 Home 目录下的配置文件：

    文件路径： <confluence-home>/confluence.cfg.xml

迁移完成后，重启 Confluence，即可加载到旧环境中的数据。

常见问题

迁移后文档无法编辑

迁移完成后，Confluence 打开正常，数据已经恢复，但是编辑文档保存时报错： Something went wrong after loading the editor. Copy your unsaved changes and refresh the page to keep editing.

这个错误通常意味着 Confluence 协作编辑（Collaborative Editing） 服务出现了通讯故障。在 Confluence 9.0.2 中，这通常与 Synchrony（负责实时协作的组件）的配置或网络环境有关。

可以 刷新 Synchrony 状态 解决

  1. 以管理员身份登录 Confluence。

  2. 前往 管理 (Confluence administration) > 协作编辑 (Collaborative editing) 。

  3. 点击 Change mode ，将其切换为 Disabled 。

  4. 等待几秒钟后，重新切换回 Enabled 。

    这会重启 Synchrony 进程并清理过时的锁定状态。

发表于 上层目录 ，

RDS 创建流程

本示例以 PostgreSQL 为例

  1. 创建子网组 (Subnet Group) 。RDS 需要在至少两个可用区（AZ）中运行。
    1. 进入 Aurora and RDS 控制台 -> Subnet groups -> Create DB subnet group
    2. 选择你的 VPC，并添加该 VPC 下位于不同 AZ 的子网。
  2. 创建安全组 (Security Group)
    1. 创建一个名为 rds-ops-sg 的安全组。
    2. 入站规则： 允许来自客户端流量访问 5432 端口（不要暴露给 0.0.0.0/0 ）。
  3. 启动 PostgreSQL 实例
    1. 在 Aurora and RDS 控制台 -> Databases -> Create database
    2. Engine options -> Engine type 选择 PostgreSQL
    3. Templates 生产环境选 Production ，测试选 Dev/Test
    4. Availability and durability 根据需求和场景选择数据库实例的可用性
    5. 设置 DB instance identifier（实例名）、Master username（管理员账户用户名） 等信息
    6. Instance configuration（运行实例配置） ，选择数据库实例运行的环境
    7. Connectivity（连接） ，设置 VPC（配置后不可更改）。 Public access（公网访问） 决定数据库实例是否可以在公网中访问，设置后可更改。
  4. PostgreSQL 实例启动成功后，即可通过 Endpoint & port 连接实例。

发表于 更新于 上层目录

环境信息

  • Centos-7 3.10.0-1062.9.1
  • Docker 19.03.15
  • containerd.io-1.4.13
  • kubectl-1.25.0
  • kubeadm-1.25.0
  • kubelet-1.25.0

kubectl 常用命令汇总

查询命令汇总

kubectl get nodes -o wide

kubectl get pods -A -o wide

kubectl get deployments -A -o wide

kubectl get daemonsets -A -o wide

kubectl get replicasets -A -o wide

kubectl get services -A -o wide

kubectl get endpointslices -A -o wide

kubectl get ingresses -A -o wide

kubectl get ingressclass -A -o wide

kubectl get deployments,replicasets,pods,services,endpointslices,ingresses

kubectl get configmaps -A

kubectl get storageclasses -o wide

kubectl get pv -o wide

kubectl get pvc -o wide

kubectl get pods -l app=nginx,env=prod

# 查看过往相关所有事件，在排查 Pod 重启原因时非常有用
kubectl get events -n default --sort-by='.metadata.creationTimestamp'    

## 启动一个临时测试 Pod ，使用完后自动删除
kubectl run netshoot-tmp --image=nicolaka/netshoot -it --rm -- /bin/bash

## 拷贝文件到容器中
kubectl cp file.tar -n prometheus grafana-766bf65cb7-h92m6:/tmp

删除命令汇总

kubectl delete service -n <namespace> <name>

kubectl delete ingress -n <namespace> <name>

kubeadm 常用命令

kubeadm 命令官方参考文档

创建集群

kubeadm init --pod-network-cidr=10.244.0.0/16 --cri-socket=unix:///var/run/cri-dockerd.sock
选项 说明 示例
--pod-network-cidr 指定 pod 的 cidr，安装 CNI 插件时，配置的 CIDR 要和此处一致
--service-cidr service 使用的 CIDR
--cri-socket 配置集群使用的 CRI，不指定时系统会扫描主机，如果有多个可用 CRI，会出现提示
--apiserver-advertise-address 手动配置 api-server 的 Advertise IP 地址。
不配置的情况下，系统默认选择主机上的默认路由对应网卡上面的 IP
--control-plane-endpoint 配置 api-server 的共享地址，可以是域名或者负载均衡器的 IP
单节点的 Master 后期需要扩展为多节点（高可用）时，需要有此配置，否则不支持(kubeadm)扩展

添加节点到集群

kubeadm join 172.31.10.19:6443 --token 8ca35s.butdpihinkdczvqb --discovery-token-ca-cert-hash sha256:b2793f9a6bea44a64640f99042f11c4ff6 \ 
        --cri-socket=unix:///var/run/cri-dockerd.sock

其中的 token 可以在 master 上使用以下命令查看

$ kubeadm token list
TOKEN                     TTL         EXPIRES                USAGES                   DESCRIPTION                                                EXTRA GROUPS
8ca35s.butdpihinkdczvqb   19h         2022-09-14T02:54:55Z   authentication,signing   The default bootstrap token generated by 'kubeadm init'.   system:bootstrappers:kubeadm:default-node-token

默认情况下，令牌会在 24 小时后过期。如果要在当前令牌过期后将节点加入集群， 则可以通过在控制平面节点上运行以下命令来创建新令牌：

kubeadm token create

如果你没有 --discovery-token-ca-cert-hash 的值，则可以通过在控制平面节点上执行以下命令链来获取它[1]：

openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | \
   openssl dgst -sha256 -hex | sed 's/^.* //'
阅读全文 »

发表于 更新于 上层目录

版本信息

  • Centos-7 3.10.0-1160
  • Docker Engine 19.03.15
  • jenkinsci/blueocean Jenkins 2.346.3

安装步骤

下载镜像

官方镜像仓库 中搜索 jenkinsci/blueocean，下载最新镜像

docker pull jenkinsci/blueocean

启动 jenkins 容器

创建数据目录

mkdir /data/JenkinsData_blueocean
chmod 777 /data/JenkinsData_blueocean

启动 jenkins 容器

docker run -d -p 8080:8080 --name jenkins \
          -v /var/run/docker.sock:/var/run/docker.sock  \
          -v /data/JenkinsData_blueocean/:/var/jenkins_home/ \
          -u root \
          jenkinsci/blueocean
  • -v /var/run/docker.sock:/var/run/docker.sock - 在需要使用 Jenkins 构建 Docker 镜像时，Jenkins 容器中的 docker 客户端需要连接到宿主机的 Docker server
  • -v /data/JenkinsData_blueocean/:/var/jenkins_home/ - 数据持久化到宿主机目录
  • -u root - 容器中使用 root 用户运行，要使用 Jenkins 构建 Docker 镜像时，默认的 jenkins 用户无权限访问 /var/run/docker.sock
阅读全文 »