经验

背景 在K8s集群中，希望引入Falco进行统一的集群操作审计 这就需要先安装Falco，借助json插件与k8saudit插件创建一个Webhook客户端，专用于接收API Server的操作审计数据 当前已有falco:0.44.0镜像，以及一个Falco的custom_values.yaml： driver: enabled: false collectors: enabled: false controller: kind: deployment services: - name: k8saudit-webhook type: NodePort ports: - port: 9765 protocol: TCP falco: rules_files: - /etc/falco/k8s_audit_rules.yaml - /etc/falco/rules.d plugins: - name: k8saudit library_path: /usr/share/falco/plugins/libk8saudit.so init_config: "" open_params: "http://:9765/k8s-audit" - name: json library_path: /usr/share/falco/plugins/libjson.so init_config: "" load_plugins: - k8saudit - json json_output: true json_include_output_property: true json_include_tags_property: true 关于格式 values文件的格式可参考：https://raw.githubusercontent.com/falcosecurity/charts/refs/heads/master/charts/falco/values.yaml 在机器可以访问外网的情况下，执行helm install falco falcosecurity/falco -n kube-audit -f custom_values.yaml即可将Falco部署到集群 但我们的集群无法访问外网，首先拉取不到Chart，其次也拉取不到falcoctl以及两个插件，甚至连插件的index文件都无法获取 因此，需要考虑离线安装Falco 手动下载Chart 执行： wget https://github.com/falcosecurity/charts/releases/download/falco-9.0.0/falco-9.0.0.tgz 即可获取falco-9.0.0.tgzChart文件，如此一来，Chart的本地化解决 falcoctl离线安装 在Pod启动时，会尝试拉取falcoctl容器镜像，它会被自动配置为Falco Pod的一个Init Container，用于管理安全规则Rules、插件Plugins ...

依赖 SpringBoot：3.5.12 HttpClient5：5.6.1 发生场景 执行restTemplate.exchange(url, HttpMethod.GET, entity, NodeListResponse.class).getBody()时报错： java.lang.ClassNotFoundException: org.apache.hc.core5.io.IOFunction 修复 查看HttpCore5的版本： $ mvn dependency:tree [INFO] ... [INFO] \- org.apache.httpcomponents.client5:httpclient5:jar:5.6.1:compile [INFO] +- org.apache.httpcomponents.core5:httpcore5:jar:5.3.6:compile [INFO] +- org.apache.httpcomponents.core5:httpcore5-h2:jar:5.3.6:compile [INFO] \- org.slf4j:slf4j-api:jar:2.0.17:compile [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 10.139 s [INFO] Finished at: 2026-04-24T19:20:35+08:00 [INFO] ------------------------------------------------------------------------ 可以看到HttpCore5是由HttpClient5引入的，版本为5.3.6 查询资料后得知Core的5.3.6版本最好配套Client5的5.5.2版本 最终确定的版本： HttpCore5：5.3.6 HttpClient5：5.5.2

背景 K8s中的插件local-path-provisioner能够动态创建PV，使用local-pathPV时，无需手动建立PV，只需建立一个PVC，在其中指定storageClassName: local-path即可，插件会自动为其分配PV和存储目录 这个插件的好处是： 用户无需手动配置PV，只需创建PVC绑定即可； 在非文件共享的场景下，用户也无需关心服务Pod被调度至哪个节点，因为插件会自动根据Pod所在节点分配存储区 现在我误删了所有PV，结果是执行kubectl get pv命令时，看到了状态是Terminating的PV，这说明PV处于正在被删除的状态 但当我执行命令kubectl get pvc -n authen查看PVC时，却发现绑定了PV的PVC是正常Bound的状态 原因分析 之所以被删除时的PV表现为Terminating状态而非直接消失，是因为该PV存在**finalizer字段**，这个字段的作用就是在集群删除PV时，不立刻清除PV，而是将其标记起来，呈现Terminating状态，这是为了确保一些重要的清理动作在资源被物理删除前完成，此时，PVC仍然是可用的 我现在存在两个Terminating状态的PV，它们各自的名称是： pvc-539fd3b7-12ed-488b-9c86-59e07de28b05 pvc-63a03d24-f078-43af-ae6c-0ce2328ba54e 查看其中一个PV的信息： master@master:~/authen/pvc$ kubectl get pv pvc-539fd3b7-12ed-488b-9c86-59e07de28b05 -o yaml apiVersion: v1 kind: PersistentVolume metadata: annotations: local.path.provisioner/selected-node: master pv.kubernetes.io/provisioned-by: rancher.io/local-path creationTimestamp: "2025-10-10T07:46:40Z" deletionGracePeriodSeconds: 0 deletionTimestamp: "2025-10-22T06:34:12Z" finalizers: - kubernetes.io/pv-protection name: pvc-539fd3b7-12ed-488b-9c86-59e07de28b05 resourceVersion: "30449839" uid: bea50dbb-7f29-4e21-bb22-d9e61ce13cec spec: accessModes: - ReadWriteOnce capacity: storage: 10Gi claimRef: apiVersion: v1 kind: PersistentVolumeClaim name: ldap-config-pvc namespace: authen resourceVersion: "27503744" uid: 539fd3b7-12ed-488b-9c86-59e07de28b05 hostPath: path: /opt/local-path-provisioner/pvc-539fd3b7-12ed-488b-9c86-59e07de28b05_authen_ldap-config-pvc type: DirectoryOrCreate nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: - master persistentVolumeReclaimPolicy: Delete storageClassName: local-path volumeMode: Filesystem status: phase: Bound 可以看到，在metadata下确实存在finalizers字段，正是它导致了PV始终处于Terminating状态 ...

安装 先创建一个命名空间：kubectl create namespace authen 设置PVC： # vi openldap-pvc.yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: ldap-data-pvc namespace: authen spec: accessModes: - ReadWriteOnce resources: requests: storage: 10Gi storageClassName: local-path --- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: ldap-config-pvc namespace: authen spec: accessModes: - ReadWriteOnce resources: requests: storage: 10Gi storageClassName: local-path 执行kubectl apply -f open-ldap-pvc.yaml创建PVC即可 设置初始化时需要插入的信息： # vi ldap-init.ldif dn: ou=People,dc=example,dc=com ou: People objectClass: organizationalUnit dn: ou=Group,dc=example,dc=com ou: Group objectClass: organizationalUnit 执行kubectl create configmap openldap-init --from-file=./ldap-init.ldif -n authen生成ConfigMap，供之后LDAP初始化时读取 创建部署文件： # vi openldap-deployment.yaml kind: Deployment apiVersion: apps/v1 metadata: name: openldap namespace: authen labels: app: openldap annotations: app.kubernetes.io/alias-name: LDAP app.kubernetes.io/description: 认证中心 spec: replicas: 1 selector: matchLabels: app: openldap template: metadata: labels: app: openldap spec: containers: - name: go-ldap-admin-openldap args: - --copy-service image: 'osixia/openldap:1.5.0' ports: - name: tcp-389 containerPort: 389 protocol: TCP - name: tcp-636 containerPort: 636 protocol: TCP env: - name: TZ value: Asia/Shanghai - name: LDAP_ORGANISATION value: "orgldap" - name: LDAP_DOMAIN value: "example.com" - name: LDAP_ADMIN_PASSWORD value: "123456" - name: LDAP_BACKEND value: mdb resources: limits: cpu: 500m memory: 500Mi requests: cpu: 100m memory: 100Mi volumeMounts: - name: ldap-config-pvc mountPath: /etc/ldap/slapd.d - name: ldap-data-pvc mountPath: /var/lib/ldap - name: openldap-init mountPath: /container/service/slapd/assets/config/bootstrap/ldif/custom/init.ldif subPath: init.ldif volumes: - name: ldap-config-pvc persistentVolumeClaim: claimName: ldap-config-pvc - name: ldap-data-pvc persistentVolumeClaim: claimName: ldap-data-pvc - name: openldap-init configMap: name: openldap-init --- apiVersion: v1 kind: Service metadata: name: openldap-svc namespace: authen labels: app: openldap-svc spec: ports: - name: tcp-389 port: 389 protocol: TCP targetPort: 389 - name: tcp-636 port: 636 protocol: TCP targetPort: 636 selector: app: openldap 执行kubectl apply -f ldap-deployment.yaml即可将LDAP部署为一个Pod ...

在基于Keycloak开发调试自定义SPI时，为了使其运行，通常需要： 手动将项目打包为jar文件 将其放入Keycloak的/providers目录中 在命令行重启Keycloak服务 对于需要观察运行状态、乃至打断点的调试来说十分不便 考虑使用JVM远程调试 + HotSwap实现对Keycloak的实时调试 JVM配置 首先需要让JVM在5005端口上监听调试请求，所以在终端设置参数（以Windows为例）： set JAVA_OPTS_APPEND=-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005 然后在同一个终端下加载jar包、运行服务： bin\kc.bat start-dev 注意 使用set命令设置的环境变量仅在当前终端窗口生效，所以需要在同一个终端下运行以上两条命令；或者可以手动在系统设置中配置环境变量，然后打开一个新终端直接运行Keycloak 服务启动后终端显示大概如下： IDEA配置 打开IDEA，在右上角找到调试下拉框（就是正常运行、调试代码的部分），进入编辑配置页面后点击页面左上角加号添加新调试，在左侧选择添加【远程JVM调试】 接下来配置该调试的各参数，名称随意，注意主机和端口要正确填写： 完成后点击调试按钮，即可看到IDEA下方调试栏中提示：已连接到地址为 ''localhost:5005'，传输: '套接字'' 的目标虚拟机，则环境配置成功 HotSwap 在已连接的情况下，对代码进行修改时，代码编辑框体的右上角会出现Code changed提示与按钮，点击后即可实现JVM对class的热更新 如此一来，每次修改代码、需要调试时，无需重新打包、导入自定义SPI的繁复操作，点击按钮即可自动编译项目、更新JVM中运行的class文件 局限 由于HotSwap只能对编译生成的class文件热更新，所以本文章的方法并不能对前端FTL文件进行实时调试，每当修改了FTL文件时，仍然需要重新打包并导入Keycloak；另外，HotSwap也不支持对类名、类增减以及方法增减的热更新