FATAL failed waiting for Kubernetes API: Get "https://api.milan46.conlab.ocp:6443/version?timeout=32s": Service Unavailable #4643
Comments
|
Your issue is either with your DNS configuration for the API URL or with your load balancer. The cluster does not need the API URL in order to install successfully, which is why the cluster installation succeeds despite your not being able to access the cluster via the API URL. |
|
Thanks for the update.
Could you please help me out here on what changes I need to do on my end?
The workaround you had mentioned is for my original issue?
Also you had mentioned this,* "whatever ${CLUSTER_ETCD_OPERATOR_IMAGE}
points to, it probably needs to be updated to use different ciphers"*
Could you please be more specific on how do I check the image and where I
need to change to.
Also how do I update the ciphers.
Would really appreciate your help here.
Regards,
Kareem
…On Mon, Feb 15, 2021 at 12:30 AM John Fortin ***@***.***> wrote:
looks like this part of boot-kube.sh is failing:
then
echo "Waiting for CEO to finish..."
bootkube_podman_run \
--volume "$PWD:/assets:z" \
"${CLUSTER_ETCD_OPERATOR_IMAGE}" \
/usr/bin/cluster-etcd-operator \
wait-for-ceo \
--kubeconfig /assets/auth/kubeconfig
fi
# Workaround for opencontainers/runc#1807
touch /opt/openshift/.bootkube.done
echo "bootkube.service complete"
whatever ${CLUSTER_ETCD_OPERATOR_IMAGE} points to, it probably needs to be
updated to use different ciphers
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#4643 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ASZ7UKHLT6JSQZ54UGH74MTS7AMWNANCNFSM4XOQSXFA>
.
|
I don't know where this advice is coming from. You do not need to do anything with the etcd operator image.
|
This is my fault. I was seeing the same issue and went down a rabbit hole due to warnings about ciphers connecting to the ETCD cluster in boot-kube.sh... I deleted the comment earlier about the ciphers... The issue I experienced was due to issues setting up /etc/resolv.conf in a systemd-resolved configuration #4654 |
|
I have the tried to use the dig command on all the nodes and below is the response, Regarding your comment,"Check that your load balancer is forwarding https communication to your 3 control plane nodes via https to port 6443." The ports are open, Could you please let me know how to forward the ports and check? Would appreciate it. |
|
@staebler, updating the log bundle here. |
|
|
Yes that's right. It is the proxy IP. I just wanted some help to overcome this. I will dig more on to why the dig had no answers when trying to communicate with the |
|
Can you run |
|
Here is a output of curl command from one of the control plane node =================
|
|
Sorry, wrong curl command. It should have been |
|
Here is the output of curl command: |
|
OK. The curl command made it all the way to the api server and back. Can you run |
|
|
Try the following where you connect directly to one of the masters instead of going through your load balancer. Your load balancer is the one that is returning the 503 Service Unavailable. It has not found a backend server that it thinks is available. You are missing the configuration in your haproxy openshift-api-server backend to perform the health check against the /readyz endpoint. Instead you have the load balancer configured to do an HTTP check against the / endpoint, and that endpoint does not accept HTTP connections. Add the following to your openshift-api-server backend configuration. |
|
Thanks for looking into it. It is surprising to know that it is missing in the haproxy configuration. let me update the haproxy and try again. |
|
I am not terribly versed in haproxy, but that seems right on a cursory glance. |
|
Sure thanks! Will give it a try and get back to you! |
|
Issues go stale after 90d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle stale |
openshift-ci
bot
added
the
lifecycle/stale
|
Stale issues rot after 30d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle rotten |
openshift-ci
bot
added
lifecycle/rotten
|
Rotten issues close after 30d of inactivity. Reopen the issue by commenting /close |
|
@openshift-bot: Closing this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Trying to create Openshift 4.6 setup on baremetal using UPI method.
1 load balancer
1 bootstrap machine
3 master node
2 worker node
Bootstrap machine logs:
Wait for bootstrap logs:
Version
Platform:
What happened?
Trying to create Openshift 4.6 setup on baremetal using UPI method.
1 load balancer
1 bootstrap machine
3 master node
2 worker node
The bootstrap machine is completed successfully. But for some reason the kubernetes API service is unavailable.
Am not able to figure out why it is throwing this error since everything looks fine.
If some proxy/dns settings were misconfigured, the bootstrap would have been in completed state.
but here the proxy/dns is configured properly.
Would be glad to some help in this issue since i have been stuck in this issue for a while
Thanks in advance
Wait for bootstrap logs:
Bootstrap machine logs:
What you expected to happen?
The kubernetes API service should be available and the bootstrap complete process should proceed ahead.
How to reproduce it (as minimally and precisely as possible)?
Followed the baremetal installation steps. https://docs.openshift.com/container-platform/4.6/installing/installing_bare_metal/installing-bare-metal.html
With below test machines
1 load balancer
1 bootstrap machine
3 master node
2 worker node
$ your-commands-hereAnything else we need to know?
Enter text here.
References
The text was updated successfully, but these errors were encountered: