GCP Kubernetes workload “Does not have minimum availability”












0















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









share|improve this question



























    0















    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









    share|improve this question

























      0












      0








      0








      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









      share|improve this question














      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






      docker kubernetes google-cloud-platform google-kubernetes-engine bitcoind






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Nov 23 '18 at 19:34









      ExpectatorExpectator

      31




      31
























          2 Answers
          2






          active

          oldest

          votes


















          0














          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.






          share|improve this answer































            0














            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.






            share|improve this answer























              Your Answer






              StackExchange.ifUsing("editor", function () {
              StackExchange.using("externalEditor", function () {
              StackExchange.using("snippets", function () {
              StackExchange.snippets.init();
              });
              });
              }, "code-snippets");

              StackExchange.ready(function() {
              var channelOptions = {
              tags: "".split(" "),
              id: "1"
              };
              initTagRenderer("".split(" "), "".split(" "), channelOptions);

              StackExchange.using("externalEditor", function() {
              // Have to fire editor after snippets, if snippets enabled
              if (StackExchange.settings.snippets.snippetsEnabled) {
              StackExchange.using("snippets", function() {
              createEditor();
              });
              }
              else {
              createEditor();
              }
              });

              function createEditor() {
              StackExchange.prepareEditor({
              heartbeatType: 'answer',
              autoActivateHeartbeat: false,
              convertImagesToLinks: true,
              noModals: true,
              showLowRepImageUploadWarning: true,
              reputationToPostImages: 10,
              bindNavPrevention: true,
              postfix: "",
              imageUploader: {
              brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
              contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
              allowUrls: true
              },
              onDemand: true,
              discardSelector: ".discard-answer"
              ,immediatelyShowMarkdownHelp:true
              });


              }
              });














              draft saved

              draft discarded


















              StackExchange.ready(
              function () {
              StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53452120%2fgcp-kubernetes-workload-does-not-have-minimum-availability%23new-answer', 'question_page');
              }
              );

              Post as a guest















              Required, but never shown

























              2 Answers
              2






              active

              oldest

              votes








              2 Answers
              2






              active

              oldest

              votes









              active

              oldest

              votes






              active

              oldest

              votes









              0














              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.






              share|improve this answer




























                0














                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.






                share|improve this answer


























                  0












                  0








                  0







                  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.






                  share|improve this answer













                  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.







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Nov 23 '18 at 19:53









                  John HanleyJohn Hanley

                  15k2528




                  15k2528

























                      0














                      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.






                      share|improve this answer




























                        0














                        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.






                        share|improve this answer


























                          0












                          0








                          0







                          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.






                          share|improve this answer













                          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.







                          share|improve this answer












                          share|improve this answer



                          share|improve this answer










                          answered Nov 24 '18 at 1:55









                          Asif TanwirAsif Tanwir

                          836




                          836






























                              draft saved

                              draft discarded




















































                              Thanks for contributing an answer to Stack Overflow!


                              • Please be sure to answer the question. Provide details and share your research!

                              But avoid



                              • Asking for help, clarification, or responding to other answers.

                              • Making statements based on opinion; back them up with references or personal experience.


                              To learn more, see our tips on writing great answers.




                              draft saved


                              draft discarded














                              StackExchange.ready(
                              function () {
                              StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53452120%2fgcp-kubernetes-workload-does-not-have-minimum-availability%23new-answer', 'question_page');
                              }
                              );

                              Post as a guest















                              Required, but never shown





















































                              Required, but never shown














                              Required, but never shown












                              Required, but never shown







                              Required, but never shown

































                              Required, but never shown














                              Required, but never shown












                              Required, but never shown







                              Required, but never shown







                              Popular posts from this blog

                              Berounka

                              Sphinx de Gizeh

                              Different font size/position of beamer's navigation symbols template's content depending on regular/plain...