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

Have one Ingress controller per network or one only if they are the same #1796

Closed
nootal opened this issue Sep 27, 2019 · 0 comments
Closed
Labels
complexity:medium Something that requires one or few days to fix topic:networking Networking-related issues

Comments

@nootal
Copy link
Contributor

nootal commented Sep 27, 2019

Component:

'network', 'kubernetes', 'ingress'

Why this is needed:

Because we want to expose different services using Ingress objects that belong to different networks. For example, we have the K8S API and the Metalk8s UI (when #1602 will be done) that are hosted on the control plane network, and the Grafana UI (and probably the Solution UIs) that are hosted on the workload plane network.

Right now we already have one Ingress controller on the workload plane network if I'm correct. So we want to have a second one on the control plane network if it's a different network (because it will bind on a different IP address). But if both networks are the same, then we can have only one controller otherwise both will try binding the same IP address and the same port and that can not work.

What should be done:

Some information is available here: https://kubernetes.github.io/ingress-nginx/user-guide/multiple-ingress/

Implementation proposal (strongly recommended):

Each Ingress controller is responsible for an Ingress class that Ingress objects should declare in their annotations so an Ingress controller knows which Ingress objects it is supposed to expose.
As described in the Important note in here https://kubernetes.github.io/ingress-nginx/user-guide/multiple-ingress/#multiple-ingress-nginx-controllers it could be interesting to have the Ingress controller used for the workload plane network to have the default class, so any Ingress object not directly targeting the Ingress class related to the control plane network would end up in the workload plane network.

Test plan:

  • Make sure that if networks are different then we have two Ingress controllers
  • Make sure that if networks are the same then we have one Ingress controller
@nootal nootal added topic:networking Networking-related issues moonshot complexity:medium Something that requires one or few days to fix labels Sep 27, 2019
NicolasT added a commit that referenced this issue Sep 27, 2019
This provisions an ingress controller for the `nginx-control-plane`
class, which will run on all `master` nodes, and be exposed on port 8443
off the control-plane IP address of the `bootstrap` node. We can add
addresses of other `master` nodes later.

The `chart.sls` file was generated using

```
./charts/render.py nginx-ingress-control-plane metalk8s-ingress charts/nginx-ingress-control-plane.yaml charts/nginx-ingress/ > salt/metalk8s/addons/nginx-ingress-control-plane/deployed/chart.sls
```

Fixes: #1796
See: #1796
See: #1800
NicolasT added a commit that referenced this issue Sep 30, 2019
This provisions an ingress controller for the `nginx-control-plane`
class, which will run on all `master` nodes, and be exposed on port 8443
off the control-plane IP address of the `bootstrap` node. We can add
addresses of other `master` nodes later.

The `chart.sls` file was generated using

```
./charts/render.py nginx-ingress-control-plane metalk8s-ingress charts/nginx-ingress-control-plane.yaml charts/nginx-ingress/ > salt/metalk8s/addons/nginx-ingress-control-plane/deployed/chart.sls
```

Fixes: #1796
See: #1796
See: #1800
@bert-e bert-e closed this as completed in ee9a552 Oct 3, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
complexity:medium Something that requires one or few days to fix topic:networking Networking-related issues
Projects
None yet
Development

No branches or pull requests

1 participant