Reply Server liveness and readiness probes

1-regular-probes.yaml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: respond-server
  namespace: reply
spec:
  replicas: 12
  strategy:
    rollingUpdate:
      maxSurge: 2
      maxUnavailable: 0
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: respond-server
    spec:x
      containers:
      - name: respond-server
        image: gcr.io/respond-next/respond-server:server-v2.10.1
        resources:
          requests:
            cpu: 200m
            memory: 300Mi
          limits:
            cpu: 300m
            memory: 400Mi
        ports:
        - containerPort: 8100
        livenessProbe:
          httpGet:
            # What endpoint will return a 200 response when the server is up and running correctly?
            path: /api
            port: 8100
            scheme: HTTP
          # When should we start pinging the service to check liveness?
          initialDelaySeconds: 15
          # How long to wait in between liveness pings?
          periodSeconds: 10
          # Choose how many sucessful pings will mark a failing pod stable/live again
          successThreshold: 2
          # We can control how long of a timeout is considered a failure
          timeoutSeconds: 1
          # How many failed pings do we need until Kubernetes will force the pod to restart?
          failureThreshold: 2
        readinessProbe:
          httpGet:
            path: /api
            port: 8100
            scheme: HTTP
          # 10 seconds gives the express app time to start up before we ping it for the first time
          initialDelaySeconds: 10
          # We wait 5 seconds in between pings - when we have 3 successful pings the pod will be marked "Ready"
          periodSeconds: 5
        env:
        - name: APP_STAGE
          value: production
        - name: AWS_ACCESS_KEY
          value: AKIAIR5KK44NYT62SCWA

2-named-ports.yaml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: respond-server
  namespace: reply
spec:
  replicas: 12
  strategy:
    rollingUpdate:
      maxSurge: 2
      maxUnavailable: 0
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: respond-server
    spec:x
      containers:
      - name: respond-server
        image: gcr.io/respond-next/respond-server:server-v2.10.1
        resources:
          requests:
            cpu: 200m
            memory: 300Mi
          limits:
            cpu: 300m
            memory: 400Mi
        ports:
        - containerPort: 8100
          name: my-http-port # we can name the port if we want to make it easier below
        livenessProbe:
          httpGet:
            # It's usually convenient to separate the endpoint so we can:
            # - filter the pings out of logs & Datadog metrics
            # - have a dedicated endpoint in the codebase that's sole purpose is to return if the svc is healthy or not
            path: /health-check
            # You can use the name here if you want:
            port: my-http-port
            scheme: HTTP
          initialDelaySeconds: 15
          periodSeconds: 10
          successThreshold: 2
          timeoutSeconds: 1
          failureThreshold: 2
        readinessProbe:
          httpGet:
            path: /health-check
            port: my-http-port
            scheme: HTTP
          initialDelaySeconds: 10
          periodSeconds: 5
        env:
        - name: APP_STAGE
          value: production
        - name: AWS_ACCESS_KEY
          value: AKIAIR5KK44NYT62SCWA