I recommend that you get more familiar with Okteto Self-Hosted before you proceed. Okteto Self-Hosted is not your application. At a very high level, Okteto Self-Hosted is just like Okteto Cloud, but instead of running in Okteto’s clusters, it runs on your Kubernetes cluster. I’m not sure what you are trying to accomplish, but Okteto Self-Hosted doesn’t sound like the best alternative for your use case.
I understand instead of hosting on cloud.okteto.com, it is hosting internally with AKS but using okteto CLI
This typically means that you didn’t create a DNS entry for your Okteto Self-Hosted instance. Azure Kubernetes Service (AKS) | Okteto Documentation has the instructions for AKS. Please open another thread if you have questions about this, so it’s easier to follow it.
You’ll need to fix this before being able to use your Okteto Self-Hosted instance.
When using Okteto Self-hosted, think of Okteto Self-Hosted as becoming a proxy for accessing your Kubernetes cluster. When you run okteto deploy, what happens is something like: okteto deploy → okteto self-hosted API → kubernetes API (it’s more complicated than that, but I’m over-simplifying). This allows Okteto to create HTTPS endpoints automatically, being compatible with Docker-Compose or build your containers remotely in the cluster.
To be able to access the okteto self-hosted API, you need to authenticate first. This is what okteto context use https://okteto.$SUBDOMAIN does. That’s why you need to pass the URL to your Okteto Self-Hosted instance (so it knows where to find the API) instead of the name of your Kubernetes cluster.
Yes but $DOMAIN is not yet created? Is that the correct assumption. It seems to me we need to authenticate to a $DOMAIN to define the context but $DOMAIN is not there ? if $DOMAIN was created could you let me know when or which command created it? Or it does not need to pre-exist?
EDIT:
Now getting:
Couldn’t authenticate to okteto cluster: authentication timeout
Try to set the context using the ‘token’ flag: Okteto CLI | Okteto Documentation
So okteto context is not selecting which AKS cluster to work in? I would have thought it was hence showing one of few clusters available to select
okteto.$SUBDOMAIN is not dynamic. This is the URL of your Okteto Self-Hosted instance. You should replace $SUBDOMAIN with the domain you are using.
In my Okteto Self-Hosted instance, the value of $DOMAIN is ramiro.dev. I run okteto context use https://okteto.ramiro.dev to authenticate.
You have to create DNS entries as part of installing Okteto Self-Hosted. Azure Kubernetes Service (AKS) | Okteto Documentation has instructions on how to do this.
Could you comment out the actual name as it is not public yet thanks, I will take screen shot
Yes I already created the DNS entries
*.NAME_OF_SUBDOMAIN
buildkit.NAME_OF_SUBDOMAIN
If you are having DNS resolution issues, please post a separate question. It’s easier to give you help that way. As part of the question, please paste the output of nslookup okteto.example.com (replacing example.com with the domain you used when creating the DNS entries).
nslookup okteto.$SUBDOMAIN
Server: 192.XXX.XX.X
Address: 192.XXX.XX.X #53
** server can’t find okteto.$SUBDOMAIN: NXDOMAIN
Could this be that DOMAIN already exists outside of Azure AKS, but trying to create a SUBDOMAIN out of an existing DOMAIN that is not controlled by the same Azure AKS?
Does this show it is resolved:
nslookup okteto.arthur-paf.example.org.uk ns1-02.azure-dns.com.Server: ns1-02.azure-dns.com.
Address: 40.90.4.2#53Name: okteto.arthur-paf.example.org.uk
Address: 20.108.75.97
Yes, that looks correct. What happens when you browse to https://okteto.$SUBDOMAIN?
Fails, can’t be reached. Or we need to follow Bring your own Cert section?
Hi @ramiro after working with host provider nslookup to add subdomain resolves it to a public IP address created in Azure
nslookup arthur-paf.example.org.uk
Server: 192.168.XX.1
Address: 192.168.XX.1#53
Non-authoritative answer:
Name: arthur-paf.example.org.uk
Address: 20.XX.XX.XXX
But ok context → Create new context → https://okteto.arthur-paf.example.org.uk --token
https://arthur-paf.example.org.uk —token Authentication will continue in your default browser
You can also open a browser and navigate to the following address:
https://okteto.arthur-paf.example.org.uk/auth/authorization-code?redirect=http%3A%2F%2F127.0.0.1%3A62215%2Fauthorization-code%2Fcallback%3F…
Then “This site can’t be reached”
Is the reason this fail to do with subdomain created by host provider does not have the SSL etc certificate?
Does nslookup need to resolve
arthur-paf.example.org.uk
or
okteto.arthur-paf.example.org.uk
as well as with SSL?
A "This site can’t be reached” error normally means that your DNS is not configured correctly. Is the IP that nslookup resolves accessible from the network that you are using?
@ramiro what does this IP address need to have to resolve AKS self-host? https correct? Would this IP address need to be part of the AKS cluster or any IP address?
When you install Okteto, you need to set up the following DNS entries:
- A DNS entry for
*.$SUBDOMAIN(where $SUBDOMAIN is the subdomain you gave Okteto during the installation). This entry should point to the External IP of your Ingress Controller. - A DNS entry for
buildkit.$SUBDOMAIN. This entry should point to the External IP of the Buildkit service (This only applies if you are running the Buildkit with a load balancer. This is not the default option)
Azure Kubernetes Service (AKS) | Okteto Documentation has more information on how to retrieve the IP addresses, and how to create the DNS configuration.