GCP Kubernetes workload "Does not have minimum availability"

11/23/2018

Background: I'm trying to set up a Bitcoin Core regtest pod on Google Cloud Platform. I borrowed some code from https://gist.github.com/zquestz/0007d1ede543478d44556280fdf238c9, editing it so that instead of using Bitcoin ABC (a different client implementation), it uses Bitcoin Core instead, and changed the RPC username and password to both be "test". I also added some command arguments for the docker-entrypoint.sh script to forward to bitcoind, the daemon for the nodes I am running. When attempting to deploy the following three YAML files, the dashboard in "workloads" shows bitcoin has not having minimum availability. Getting the pod to deploy correctly is important so I can send RPC commands to the Load Balancer. Attached below are my YAML files being used. I am not very familiar with Kubernetes, and I'm doing a research project on scalability which entails running RPC commands against this pod. Ask for relevant logs and I will provide them in seperate pastebins. Right now, I'm only running three machines on my cluster, as I'm am still setting this up. The zone is us-east1-d, machine type is n1-standard-2.

Question: Given these files below, what is causing GCP Kubernetes Engine to respond with "Does not have minimum availability", and how can this be fixed?


bitcoin-deployment.sh

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  namespace: default
  labels:
    service: bitcoin
  name: bitcoin
spec:
  strategy:
    type: Recreate
  replicas: 1
  template:
    metadata:
      labels:
        service: bitcoin
    spec:
      containers:
      - env:
        - name: BITCOIN_RPC_USER
          valueFrom:
            secretKeyRef:
              name: test
              key: test
        - name: BITCOIN_RPC_PASSWORD
          valueFrom:
            secretKeyRef:
              name: test
              key: test
        image: ruimarinho/bitcoin-core:0.17.0
        name: bitcoin
        ports:
        - containerPort: 18443
          protocol: TCP
        volumeMounts:
          - mountPath: /data
            name: bitcoin-data
        resources:
          requests:
            memory: "1.5Gi"
        command: ["./entrypoint.sh"]
        args: ["-server", "-daemon", "-regtest", "-rpcbind=127.0.0.1", "-rpcallowip=0.0.0.0/0", "-rpcport=18443", "-rpcuser=test", "-rpcpassport=test"]
      restartPolicy: Always
      volumes:
        - name: bitcoin-data
          gcePersistentDisk:
            pdName: disk-bitcoincore-1
            fsType: ext4

bitcoin-secrets.yml

apiVersion: v1
kind: Secret
metadata:
  name: bitcoin
type: Opaque
data:
  rpcuser: dGVzdAo=
  rpcpass: dGVzdAo=

bitcoin-srv.yml

apiVersion: v1
kind: Service
metadata:
  name: bitcoin
  namespace: default
spec:
  ports:
    - port: 18443
      targetPort: 18443
  selector:
    service: bitcoin
  type: LoadBalancer
  externalTrafficPolicy: Local
-- Expectator
bitcoind
docker
google-cloud-platform
google-kubernetes-engine
kubernetes

4 Answers

12/20/2019

I encountered this error within GKE. The reason was the pod was not about to find the configmap due to name mismatch. So make sure all the resources are discoverable by the pod.

-- sonu1986
Source: StackOverflow

11/24/2018

The error message you mentioned isn't directly pointing to a stockout; it's more of resources unavailable within the cluster. You can try again after adding another node to the cluster etc. Also, this troubleshooting guide suggests if your Nodes have enough resources but you still have Does not have minimum availability message, check if the Nodes have SchedulingDisabled or Cordoned status: in this case they don't accept new pods.

-- Asif Tanwir
Source: StackOverflow

11/23/2018

I have run into this issue several times. The solutions that I used:

  1. Wait. Google Cloud does not have enough resource available in the Region/Zone that you are trying to launch into. In some cases this took an hour to an entire day.
  2. Select a different Region/Zone.

An example was earlier this month. I could not launch new resources in us-west1-a. I think just switched to us-east4-c. Everything launched.

I really do not know why this happens under the covers with Google. I have personally experienced this problem three times in the last three months and I have seen this problem several times on StackOverflow. The real answer might be a simple is that Google Cloud is really started to grow faster than their infrastructure. This is a good thing for Google as I know that they are investing in major new reasources for the cloud. Personally, I really like working with their cloud.

-- John Hanley
Source: StackOverflow

9/8/2019

There could be many reasons for this failure:

  1. Insufficient resources
  2. Liveliness probe failure
  3. Readiness probe failure
-- Charlie
Source: StackOverflow