看起来你在AKS上部署Jira时碰到了两个头疼的问题：手动重启后配置全丢，还有同步用户目录到Confluence/Bitbucket时的403错误。我来拆解下问题根源，再给你一步步的解决方案：

核心问题拆解 #

• 手动启停脚本导致配置丢失：Kubernetes是靠声明式配置管理容器生命周期的，你在Pod里直接跑./start-jira.sh或./stop-jira.sh会打乱K8s的管控逻辑。更关键的是，如果没给Jira配置持久化存储，容器里的临时数据（包括你的所有配置、备份）在Pod重启后就会被清空。
• 137错误：这个错误码基本意味着容器被K8s强制杀死了，大概率是内存不足（OOMKilled）——你用的D8 v3节点有32G内存，但如果Jira的JVM堆内存没调好，或者Pod的资源限制设得不合理，就容易触发这个问题。

分步解决步骤 #

1. 用Kubernetes的正确方式重启Jira #

别再在Pod里手动启停了！直接删除Pod，让K8s的Deployment/StatefulSet自动重建一个新Pod：

# 替换成你的Jira Deployment的标签，比如app=jira-software
kubectl delete pod -l app=jira-software

这样重建的Pod会自动挂载你配置的持久化存储，配置和数据都不会丢。

2. 确认持久化存储配置正确 #

不管是用官方镜像还是Helm Chart部署，必须确保Jira的核心数据目录挂了持久卷（PV/PVC）：

• Jira默认的核心数据目录是/var/atlassian/application-data/jira
• 检查你的Helm values或者Deployment YAML，确认这个目录已经绑定了PVC：

  volumes:
    - name: jira-data
      persistentVolumeClaim:
        claimName: jira-pvc
  volumeMounts:
    - name: jira-data
      mountPath: /var/atlassian/application-data/jira
  

如果没配持久化，Pod一重启所有配置就没了，这是很多人踩的坑！

3. 调整内存配置解决137错误 #

针对OOM问题，你需要做两个调整：

• 设置Jira的JVM堆内存：通过环境变量或者Helm values配置，比如给Jira分配8G初始堆、16G最大堆（根据D8 v3的32G内存合理分配，别占满节点内存）：

  env:
    - name: JVM_MINIMUM_MEMORY
      value: "8g"
    - name: JVM_MAXIMUM_MEMORY
      value: "16g"
  

• 配置Pod的资源请求和限制：让K8s给Jira预留足够的资源，避免被强制杀死：

  resources:
    requests:
      memory: "8Gi"
      cpu: "2"
    limits:
      memory: "16Gi"
      cpu: "6"
  

4. 验证IP白名单是否生效 #

重启Pod后，去Jira后台确认你加的AKS节点/Atlassian产品Pod的IP已经在白名单里：

• 进入Jira管理后台 → 系统 → 安全设置 → 允许的IP地址
• 确保包含Confluence、Bitbucket所在Pod的IP段，或者AKS节点的内网/公网IP

5. 进一步排查403同步问题 #

如果重启后还是403，再检查这几点：

• 确认用来同步的Jira账号有全局权限，比如“访问用户目录”的权限
• 检查Confluence/Bitbucket调用Jira API时用的协议（HTTP/HTTPS）是否和Jira的配置一致
• 去Jira的日志目录（在持久化存储的logs文件夹里）找403请求的具体日志，看看是权限不足还是CSRF之类的问题

内容的提问来源于stack exchange，提问作者Callum Gadd