首页 > 解决方案 > Kubernetes 不等待 reactjs 加载

问题描述

我有一个 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: {}

吊舱每 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

这是我的 Dcokerfile:

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"]

标签: reactjsdockerkubernetesgoogle-kubernetes-engine

解决方案


从此处的文档中,您可以使用启动探针保护启动缓慢的容器。

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

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

推荐阅读