what

你的日志显示是：端口 2049 冲突。

日志中关键的错误信息是：

Cannot bind to IP 10.0.19.203 port 2049: [Errno 98] Address already in use
ERROR: TCP Port(s) '10.0.19.203:2049,0.0.0.0:9000' required for haproxy already in use

原因分析

1. Ingress (HAProxy) 试图绑定到 2049 端口（这是 NFS 的标准端口，用于对外提供服务）。
2. 但是，后端的 NFS 守护进程 (nfs.nfs-cephfs...) 当前也配置为监听 2049 端口，并且它已经正在运行中。
3. 因为端口已被 NFS 守护进程占用，HAProxy 无法启动。

解决方案

你需要将后端的 NFS 服务修改为监听一个非标准端口（例如 12049），把 2049 端口让给 Ingress (HAProxy) 使用。

按照以下步骤操作：

第一步：导出当前的 NFS 服务配置

找到你的后端 NFS 服务名称（通常是 nfs.nfs-cephfs，根据你的 ceph orch ps 输出）：

ceph orch ls --service-name nfs.nfs-cephfs --export > nfs_backend.yaml

第二步：修改配置文件

使用文本编辑器（如 vi 或 nano）打开 nfs_backend.yaml。
你需要添加或修改 spec 下的 port 字段。将其设置为一个非 2049 的端口（例如 12049）。

修改后的文件应该类似这样：

service_type: nfs
service_id: nfs-cephfs
service_name: nfs.nfs-cephfs
placement:
  count: 1
spec:
  port: 2049

第三步：应用新配置

将修改后的配置应用到集群：

ceph orch apply -i nfs_backend.yaml

第四步：验证 NFS 是否重启

应用配置后，Ceph 编排器会重启后端的 NFS 守护进程。
运行以下命令，确认 NFS 守护进程现在是否正在监听新端口（PORTS 列应该显示 *:12049）：

ceph orch ps --service_name nfs.nfs-cephfs

第五步：验证 Ingress 是否恢复

一旦后端 NFS 释放了 2049 端口，Ingress 服务（HAProxy）应该会自动尝试重启并成功绑定。

运行以下命令查看状态：

ceph orch ps --service_name ingress.nfs.nfs-cephfs-ha

或者查看列表：

ceph orch ls --service-name ingress.nfs.nfs-cephfs-ha

如果 RUNNING 列显示 2/2，说明问题已解决。

总结

Ingress 架构是：
客户端 (2049) -> HAProxy (监听 2049) -> NFS Ganesha (监听 12049)

你目前两个都试图监听 2049，所以必须把后面那个改成别的端口。

这个错误是 Ceph NFS 的经典“权限覆盖”问题，核心意思是：

现在用 nfs-cephfs 这个名字重新创建 NFS 集群时，系统发现旧的 client（nfs.nfs-cephfs.2）的 caps 还在，但因为旧集群已经被彻底删掉，mgr 想重新给它写 caps，结果发现这个 client 的 key 或者 caps 已经被锁死/残留，导致 Failed to update caps。

一句话：旧的 nfs.nfs-cephfs.* 这个 client 身份还活着，挡住了你用同一个名字重建。

一键彻底解决（3 条命令，30 秒搞定）

# 1. 把残留的 client 身份彻底干掉（重点！）
ceph auth del client.nfs.nfs-cephfs.2

# 2. 如果还有其他残留的 nfs-cephfs.* client，也一起删（一般就这一个）
ceph auth list | grep -A 5 nfs.nfs-cephfs | grep entity | awk '{print $2}' | xargs -I {} ceph auth del {}

# 3. 现在再创建，就绝对成功了
ceph nfs export create cephfs nfs-cephfs /ceph myFs --path=/

刷新 Ceph 缓存：

ceph mgr module disable nfs  # 临时禁用 NFS 模块
ceph mgr module enable nfs   # 重新启用，强制刷新

之后，你在查看一下，应该是缓存

最后，你在运行 ceph df 检查空间是否释放（残留对象通常很小，但可能影响 PG 平衡）。

排查顺序：

ceph nfs cluster ls
ceph nfs export ls cephnfs
ceph fs subvolume ls myFs
ceph fs subvolume info myFs <name>
ceph orch ps | grep nfs

另外：敲重点!!!
如果你是通过Dashboard页面编辑的子目录，是不行的，你需要删除重建这种，为什么我也不太清楚，因为我编辑更改了子目录是不生效的，也许是某个ceph版本的bug吧。

感谢，ip确实是错的，因为我是容器启动的，这个ip被别的容器占用了。

对应的是pod的.metadata.uid：

for d in /var/lib/kubelet/pods/*; do
  p_u=$(basename "$d")
  kubectl get po -A -o json | \
    jq --arg pod_uuid "$p_u" -r '.items[] 
      | select(.metadata.uid == $pod_uuid) 
      | "uuid \($pod_uuid) is \(.metadata.name)"'
done

类似如下输出：

"Labels": {
    "annotation.io.kubernetes.container.hash": "e44bee94",
    "annotation.io.kubernetes.container.restartCount": "4",
    "annotation.io.kubernetes.container.terminationMessagePath": "/dev/termination-log",
    "annotation.io.kubernetes.container.terminationMessagePolicy": "File",
    "annotation.io.kubernetes.pod.terminationGracePeriod": "30",
    "io.kubernetes.container.logpath": "/var/log/pods/kube-system_storage-provisioner_b4aa3b1c-62c1-4661-a302-4c06b305b7c0/storage-provisioner/4.log",
    "io.kubernetes.container.name": "storage-provisioner",
    "io.kubernetes.docker.type": "container",
    "io.kubernetes.pod.name": "storage-provisioner",
    "io.kubernetes.pod.namespace": "kube-system",
    "io.kubernetes.pod.uid": "b4aa3b1c-62c1-4661-a302-4c06b305b7c0",
    "io.kubernetes.sandbox.id": "3950ec60121fd13116230cad388a4c6c4e417c660b7da475436f9ad5c9cf6738"
}

在Kubernetes中，无状态应用通常指的是应用程序的设计方式，使其在集群中的任何节点上都能够无缝运行，而不依赖于特定节点的本地存储或状态信息。这种设计有助于实现高可用性、伸缩性和容错性。Kubernetes是一个开源的容器编排平台，用于自动化容器化应用程序的部署、扩展和管理。

无状态应用在Kubernetes中的主要特征包括：

1. 无状态容器： 应用程序的组件被打包为容器，并设计为无状态的。容器应该包含所有应用程序所需的依赖项，并且不应该依赖于本地存储或节点上的任何状态信息。

2. 自动伸缩： 无状态应用可以更容易地实现自动伸缩。Kubernetes可以根据负载情况自动调整应用程序的副本数量，以满足性能需求。

3. 高可用性： 由于无状态应用不依赖于本地状态，因此它们可以在集群中的任何节点上运行。如果某个节点故障，Kubernetes可以重新调度应用程序的副本到其他健康的节点上，实现高可用性。

4. 简化部署： 无状态应用的部署更为简单，因为它们不需要在节点之间同步状态信息。这使得应用程序更易于扩展和更新。

在Kubernetes中，无状态应用通常指的是应用程序的设计方式，使其在集群中的任何节点上都能够无缝运行，而不依赖于特定节点的本地存储或状态信息。这种设计有助于实现高可用性、伸缩性和容错性。Kubernetes是一个开源的容器编排平台，用于自动化容器化应用程序的部署、扩展和管理。

无状态应用在Kubernetes中的主要特征包括：

1. 无状态容器： 应用程序的组件被打包为容器，并设计为无状态的。容器应该包含所有应用程序所需的依赖项，并且不应该依赖于本地存储或节点上的任何状态信息。

2. 自动伸缩： 无状态应用可以更容易地实现自动伸缩。Kubernetes可以根据负载情况自动调整应用程序的副本数量，以满足性能需求。

3. 高可用性： 由于无状态应用不依赖于本地状态，因此它们可以在集群中的任何节点上运行。如果某个节点故障，Kubernetes可以重新调度应用程序的副本到其他健康的节点上，实现高可用性。

4. 简化部署： 无状态应用的部署更为简单，因为它们不需要在节点之间同步状态信息。这使得应用程序更易于扩展和更新。

这是 Lettuce 的一项安全功能，目的是防止通过集群节点（CLUSTER NODES）重定向到（尚未）已知的节点。如果拓扑结构发生变化，而客户端有不同的视图，就会出现这种状态。

Redis在扩容/缩容过程中，当实例分片数发生变化时，存在节点拓扑关系和Slot对应信息的变化，需要客户端进行拓扑关系的自动更新，否则可能造成请求路由失败或者路由位置错误等，造成客户端访问报错。

1、开启Cluster集群自动刷新拓扑配置。

spring:
  redis:
    cluster:
      refresh:
        adaptive: true
        period: 30000    # 30秒自动刷新一次

2、关闭“验证集群节点成员资格开关”，关闭方式如下：

spring:
  redis:
    cluster:
      validate-cluster-node-membership: false

Calico的问题。
从 v3.26.0 升级到 v3.26.1 解决了这个问题。

你这么做是对的。

通常情况下，如kubectl scale deploy my-awesome-deployment --replicas=0，这样就不需要指定特定文件了，但如果对你来说更方便，使用文件也没有错。