Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Profile - Move to per-product namespaces #212

Open
3 tasks
olebhansen opened this issue Oct 3, 2024 · 0 comments
Open
3 tasks

Profile - Move to per-product namespaces #212

olebhansen opened this issue Oct 3, 2024 · 0 comments
Assignees
Labels
area/infrastructure Issue originates as changes to infrastructure kind/chore Non functional, often repeating tasks

Comments

@olebhansen
Copy link

olebhansen commented Oct 3, 2024

Description

Profile should be moved out of the default namespace. We want to collect namespace changes across multiple applications in order to update as many as possible in one go. New namespace should be profile.

Kubernetes uses ndots:5 in DNS search:
https://pracucci.com/kubernetes-dns-resolution-ndots-options-and-why-it-may-affect-application-performances.html

This means the DNS address we use to access profile should preferably have 5 dots. eg:
http://altinn-profile.profile.svc.cluster.local.
Notice the dot at the end.

In the values file for Notifications this would look like this:

    - name: PlatformSettings__ApiProfileEndpoint
      value: http://altinn-profile.profile.svc.cluster.local./profile/api/v1/

Deploy

Profile cannot be moved into a new namespace in the existing AKS service without some downtime. There are two issues:

  1. We can't run Profile in two namespaces at the same time without running into routing limitations. Traefik wouldn't know where to send requests and will probably stop us from setting it up.
  2. Multiple other applications use local DNS address in order to send requests to profile. With the change of namespace the address will change. This can be mitigates by having other applications use the public address instead. This would have consequences for performance, but would be for a limited time.

While we have a workaround for issue number 2, issue number 1 is forcing us to use blue-green deploy of platform. We want to update as many applications as possible on a new instance of AKS for then to switch between the AKS instances.

Tasks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/infrastructure Issue originates as changes to infrastructure kind/chore Non functional, often repeating tasks
Projects
None yet
Development

No branches or pull requests

2 participants