Configuring Parameters to Delay the Pod Startup in a CCE Turbo Cluster

Application Scenarios

In a CCE Turbo cluster, the routing rules of the peer pod may take effect slowly in some specific scenarios like cross-VPC and private line interconnections. To avoid this problem, configure parameters to delay the pod startup.

You can also create enterprise routers to connect to the peer VPCs. For details, see Connecting a Cluster to the Peer VPC Through an Enterprise Router.

Constraints

Only the CCE Turbo clusters of the following versions support the configuration of this parameter:

• v1.19: v1.19.16-r40 or later
• v1.21: v1.21.11-r0 or later
• v1.23: v1.23.9-r0 or later
• v1.25: v1.25.4-r0 or later

Using kubectl

You can add annotations to a workload to configure whether to delay the pod startup.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 10
  selector:
    matchLabels:
      app: nginx
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: nginx
      annotations:
        cni.yangtse.io/readiness-delay-seconds: "20"
    spec:
      containers:
        - name: container-0
          image: nginx:alpine
          resources:
            limits:
              cpu: 100m
              memory: 200Mi
            requests:
              cpu: 100m
              memory: 200Mi
      imagePullSecrets:
        - name: default-secret

In this example, the Deployment needs to be configured to access the IP addresses of the cross-VPC VMs. The maximum number of replicas of this Deployment is 10 and the maximum rolling upgrade surge is 25%, which is, the maximum number of pods to be upgraded concurrently is 13. In the annotation, the pod startup delay is set to 20s. This ensures that the cross-VPC network can be accessed normally after the pod is started.