reactjs - Kubernetes 不等待 reactjs 加载

Question

我有一个 GKE 集群。我正在尝试部署一个 reactjs 前端应用程序，但似乎 kubernetes 在它完全加载之前重新启动了 pod。我可以使用 docker 手动运行容器并成功加载应用程序，但加载时间很长(10 分钟)，我想是因为我使用的是 GCP 中最基本的服务器。
我正在尝试使用 kubernetes 探测器等待应用程序运行。我无法让它工作。还有其他方法可以告诉kubernetes等待应用程序启动吗？谢谢

这是我的部署文件:

kind: Deployment
metadata:
  labels:
    app: livenessprobe
  name: livenessprobe
spec:
  replicas: 1
  selector:
    matchLabels:
      app: livenessprobe
  template:
    metadata:
      labels:
        app: livenessprobe
    spec:
      containers:
      - image: mychattanooga:v1
        name: mychattanooga
        livenessProbe:
          httpGet:
            path: /healthz
            port: 3000
          initialDelaySeconds: 99
          periodSeconds: 30
        resources: {}

pod 每 5 秒左右重启一次，然后我得到 crashLoopBackOff 并再次重启......

kubectl 获取事件:

assigned default/mychattanooga-85f44599df-t6tnr to gke-cluster-2-default-pool-054176ff-wsp6
13m         Normal    Pulled                         pod/mychattanooga-85f44599df-t6tnr               Container im
age "#####/mychattanooga@sha256:03dd2d6ef44add5c9165410874cee9155af645f88896e5d5cafb883265c
3d4c9" already present on machine
13m         Normal    Created                        pod/mychattanooga-85f44599df-t6tnr               Created cont
ainer mychattanooga-sha256-1
13m         Normal    Started                        pod/mychattanooga-85f44599df-t6tnr               Started cont
ainer mychattanooga-sha256-1
13m         Warning   BackOff                        pod/mychattanooga-85f44599df-t6tnr               Back-off res
tarting failed container

kubectl 描述 pod:

 Name:           livenessprobe-5f9b566f76-dqk5s
Namespace:      default
Priority:       0
Node:           gke-cluster-2-default-pool-054176ff-wsp6/10.142.0.2
Start Time:     Wed, 01 Jul 2020 04:01:22 -0400
Labels:         app=livenessprobe
                pod-template-hash=5f9b566f76
Annotations:    kubernetes.io/limit-ranger: LimitRanger plugin set: cpu request for container mychattanooga
Status:         Running
IP:             10.36.0.58
IPs:            <none>
Controlled By:  ReplicaSet/livenessprobe-5f9b566f76
Containers:
  mychattanooga:
    Container ID:   docker://cf33dafd0bb21fa7ddc86d96f7a0445d6d991e3c9f0327195db355f1b3aca526
    Image:          #####/mychattanooga:v1
    Image ID:       docker-pullable://gcr.io/operational-datastore/mychattanooga@sha256:03dd2d6ef44add5c9165410874
cee9155af645f88896e5d5cafb883265c3d4c9
    Port:           <none>
    Host Port:      <none>
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Completed
      Exit Code:    0
      Started:      Wed, 01 Jul 2020 04:04:35 -0400
      Finished:     Wed, 01 Jul 2020 04:04:38 -0400
    Ready:          False
    Restart Count:  5
    Requests:
      cpu:        100m
    Liveness:     http-get http://:3000/healthz delay=999s timeout=1s period=300s #success=1 #failure=3
    Environment:  <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-zvncw (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             False
  ContainersReady   False
  PodScheduled      True
Volumes:
  default-token-zvncw:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-zvncw
    Optional:    false
QoS Class:       Burstable
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:
  Type     Reason     Age                     From                                               Message
  ----     ------     ----                    ----                                               -------
  Normal   Scheduled  4m46s                   default-scheduler                                  Successfully assi
gned default/livenessprobe-5f9b566f76-dqk5s to gke-cluster-2-default-pool-054176ff-wsp6
  Normal   Pulled     3m10s (x5 over 4m45s)   kubelet, gke-cluster-2-default-pool-054176ff-wsp6  Container image "
#######/mychattanooga:v1" already present on machine
  Normal   Created    3m10s (x5 over 4m45s)   kubelet, gke-cluster-2-default-pool-054176ff-wsp6  Created container
 mychattanooga
  Normal   Started    3m10s (x5 over 4m45s)   kubelet, gke-cluster-2-default-pool-054176ff-wsp6  Started container
 mychattanooga
  Warning  BackOff    2m43s (x10 over 4m38s)  kubelet, gke-cluster-2-default-pool-054176ff-wsp6  Back-off restarti
ng failed container

这是我的 Dcoker 文件:

FROM node:latest

# Copy source code
COPY source/ /opt/app

# Change working directory
WORKDIR /opt/app

# install stuff
RUN npm install

# Expose API port to the outside
EXPOSE 3000

# Launch application
CMD ["npm", "start"]

Answer 1

来自文档 here您可以使用启动探测器来保护启动缓慢的容器。

有时，您必须处理遗留应用程序，这些应用程序在首次初始化时可能需要额外的启动时间。在这种情况下，在不影响对激发此类探测的死锁的快速响应的情况下设置 active 探测参数可能很棘手。诀窍是使用相同的命令、HTTP 或 TCP 检查设置启动探测，并使用足够长的 failureThreshold * periodSeconds 来覆盖最坏情况下的启动时间

startupProbe:
  httpGet:
    path: /healthz
    port: liveness-port
  failureThreshold: 30
  periodSeconds: 10