Problems with deployin an AI Agent when using a pre-existing Ingress Controller

[marticardus]

Hello

I configured Okteto following the following manuals and documentation, resulting in the helm values ​​file I’ve added at the end as well.

I can access the Okteto web interface, but I’m unable to run any environment:

• We’re using GitLab and can only clone via the web; there’s no SSH access. From what I can see, this doesn’t seem to be a problem for IA Agents, but it might be for normal deployments.
• IA Agents fail when trying to connect to automatically created VScode instances. They are calling vscode-XXXX.dev.ourdomain.tld, but the certificate is only valid for ingress.local: Error: failed to deploy Agent(xt7pfzlc6mq2): failed to wait for Agent chat endpoint: request failed: Get “https:// vscode-0aceee46-agent-xt7pfzlc6mq2.dev.ourdomain.tld”: tls: failed to verify certificate: x509: certificate is valid for ingress.local, not vscode-0aceee46-agent-xt7pfzlc6mq2.dev.ourdomain.tld

Could you help me resolve these issues?

Thanks

How Do I configure Okteto with cert-manager and AWS Route53?

How do I configure the Okteto wildcard certificate with cert-manager and Route53?

How do I configure my own Ingress Controller?

You can disable the installation of the Okteto Nginx Ingress Controller with the following snippet in your Helm values file: ingress-nginx: enabled: false okteto-nginx: enabled: false defaultBackend: enabled: false In that case, configure the following fields in the ingress section: ingress.oktetoIngressClass with the ingress class you want to use for all the ingresses created during the Okteto installation. ingress.class with the ingress class you want to use for all the ingresses…

license: "..."
subdomain: "dev.ourdomain.tld"

registry:
  storage:
    filesystem:
      enabled: true
      persistence:
        enabled: true
        accessMode: ReadWriteOnce
        storageClass: "ebs-gp3"
        size: 40Gi

ingress-nginx:
  enabled: false

okteto-nginx:
  enabled: false

okteto-ingress:
  enabled: false

defaultBackend:
  enabled: false

wildcardCertificate:
  create: false
  name: okteto-wildcard

ingress:
  oktetoIngressClass: nginx
  class: nginx
  ip: 172.20.237.72

buildkit:
  persistence:
    enabled: true
    class: "ebs-gp3"
    size: 100Gi
    cacheRatio: 0.5
    accessModes: ["ReadWriteOnce"]

[ramiro]

hey @marticardus , welcome to our community!

We’re using GitLab and can only clone via the web; there’s no SSH access. From what I can see, this doesn’t seem to be a problem for IA Agents, but it might be for normal deployments.

IA Agents reach out via a GIT token, as long as you give them that, you should be good to go. For developers, you need to give Okteto SSH access to your gitlab instance. Every Okteto installation has a unique SSH private key, you can use that to grant access. This docs have more information on it.

IA Agents fail when trying to connect to automatically created VScode instances.

For the second issue you mentioned, if you are seeing ingress.localthat points to a potential issue with your certificate configuration. I notice that you set wilcardCertificate.create:false. With that value, the expectation is that you ‘bring your own ceritificate’. Did you do that? Our documentation has more information on this.

[marticardus]

Hi @ramiro

@ramiro

IA Agents reach out via a GIT token, as long as you give them that, you should be good to go. For developers, you need to give Okteto SSH access to your gitlab instance. Every Okteto installation has a unique SSH private key, you can use that to grant access.

We have deployed a self-hosted gitlab without SSH acces, only with HTTPS access, is there any option with this setup?

@ramiro

For the second issue you mentioned, if you are seeing ingress.localthat points to a potential issue with your certificate configuration. I notice that you set wilcardCertificate.create:false. With that value, the expectation is that you ‘bring your own ceritificate’. Did you do that?

I have configured certificate with lets-encrypt following these instructions: How Do I configure Okteto with cert-manager and AWS Route53? - #2 by pchico83 I can see our certificate configurated, and I can enter okteto dev page, but when I try to start an environment, its create a ingress entry without any TLS option or certificate reference.

Thanks

[ramiro]

We have deployed a self-hosted gitlab without SSH acces, only with HTTPS access, is there any option with this setup?

The only option would be to include the token on the URL of the repository, but we don’t recommend this due to security, the risk of leaking the token is too big.

[ramiro]

@marticardus

I have configured certificate with lets-encrypt following these instructions:

Could you share your support bundle with us? Diagnostics | Okteto Documentation has instructions on how to generate it.

[marticardus]

Hi Ramiro,

Our support-bundle https://drive.google.com/file/d/1np3uKqdWEfGnj7bz5_31USHKvnsz8Zrm/view?usp=sharing

[ramiro]

Okteto needs the NGINX Controller that you are using to have a valid default certificate configured.

I tested this on my personal cluster by using the configuration below when installing NGINX Ingress Controller.

controller:
  allowSnippetAnnotations: true
  config:
    annotations-risk-level: "Critical"

  extraArgs:
        # tells NGINX to use this as the default certificate
        default-ssl-certificate: "ingress-nginx/okteto-wildcard"
  service:
    annotations:
      service.beta.kubernetes.io/aws-load-balancer-type: nlb
      service.beta.kubernetes.io/aws-load-balancer-scheme: "internet-facing"

ingress-nginx/okteto-wildcard is a secret that contains a valid certificate for *.dev.ourdomain.tld. Once I made this configuration change, Okteto AI (and the rest of the Okteto components) worked as expected when installed with the configuration your shared.

We will update our documentation and the community question you linked to make this requirement clearer.