Istio operator with custom gateways

1

Hello!

I’m already using istio installed using helm and I am looking to move forward to using the operator.

At the moment, the operator installs different components (pilot, citadel, mixer, etc.) based on a CR IstioControlPlane and manages the reconciliation. But I think it needs more flexibility when it comes to gateways - now it only supports an ingress and an egress gateway-controller deployment.
I feel like for this part there should be a different CR (maybe IstioGatewayController) to manage a deployment for a specific istio-gateway-controller.

apiVersion: install.istio.io/v1alpha2
kind: IstioGatewayController
metadata:
   name: my-demo-project-ingress
   namespace: demo
spec:
  resources: ...
  ports: ...
  ...

In my use case, each namespace is used by a project (or a team) and I would like to be able to create one or more instances of ingress-controller in each one. I think this way we have a better separation of concerns for every project and it comes with many more advantages.

Is there a way to use the current operator implementation in my scenario? Or are there any plans to improve in this direction?

Thank you!

PS: I’m not sure if I should have posted it here instead

2

Hi, we are planning to change the operator API a bit in 1.5 to fully support user gateways - unfortunately this didn’t make in time to go into 1.4. But we’ve also realized that there’s not any especially convenient workaround till then (you have to copy and paste a bunch of YAML and basically create your own gateway that way). To address that, we’re going to put in a small workaround which should make it fairly easy to generate and add your own gateways. This should be out in a couple of days in 1.4.1 along with the docs.
Martin

3

Thank you for your answer. Are these future changes to the operator API documented anywhere? I would like to know how they would in fit my use case.

4

They’ll show up in istio/api shortly - I’ll make a note to update this thread when they are merged.

1 Like
5

The PR finally merged, the API for gateways is here:


We’ll be implementing this API for 1.5.
For 1.4 there’s a clunky workaround for adding your own gateways:

6

Thanks for the notification. I am curious what do you think about this idea:

7

Before I opine on the idea could you explain the motivation for doing this?

8

As I was previously saying, in my case the cluster is shared between multiple projects/teams. Each of them could own one ore more namespaces, but all of them must be part of one service mesh. Moreover, I want to have one or more ingresses/egresses for each project. I think this scenario is pretty popular as I have noticed in other discussion threads too.

In istio 1.4, using the operator, the cluster administrator can install one service mesh using the IstioControlPlane CR, thus setting up the control plane (pilot, telemtey, policy, etc.).

The motivation of having a new CR for the ingress-gateway deployment is to give the ability to non-cluster admins to create a resource, which, in my opinion, is related to data plane. This approach could be useful for fine-grained control. For example, k8s rbac rules could be applied to IstioGatewayController and each project/team could tune (requests, limits, open ports, cert options) their deployment of ingress without requiring access to the entire control plane configuration (IstioControlPlane CR). In addition, an IstioControlPlane CR could get pretty big if many gateways are added (in a cluster with 20 namespaces, there could be at least 50 ingress gateway deployments).

9

Yes, ingress is related to data plane and in fact the major reason that it’s part of the Istio base install at all is as a convenience (default/demo installs for most users won’t do much without a gateway). Most users would probably want to install and manage their own gateways and treat the resources as user config in the long run. In that case, the problem becomes one of “how can we make it easy for end users to generate and install their own gateways”.
The only exception which I think you’re alluding to might be the case where you want to prevent users from being able to create gateway resources directly for security reasons. Rather than creating a controller for gateways, a simpler solution would be to split the CRD into two: a gateways and everything else part and only give users permissions for the gateways CRD. It does complicate the setup for other cases so I think this would need to be a reasonably common ask to make such a change.
Another possibility that we’ve been thinking about is to create a way to define part of the CRD as read-only, for managed use cases. In that scenario, you could set up two controllers, one for gateways, which would be controller by a CR with permissions restricted to modifying only the gateways fields.