Kubernetes operator

1

I'm very keen on a declarative configuration as discussed in OpenZiti declarative deployments and Declarative configuration with files, specifically using Kubernetes, as my time permits.

This also allows me to develop with Go, which is new for me as a longtime Python and C developer. I started with a spec for CRDs and bootstrapped the project with kubebuilder.

I realise a Kubernetes operator might not be a priority for others right now, but I wanted to share that I'm keen to do this and get some input on what a first version of the Kubernet operator should do. My opinion about the initial scope is captured in the spec linked above.

Additionally, I want to know if you prefer this experiment to continue in my personal repo or if you want me to move it to the OpenZiti GitHub organisation.

2

Hi @rochecompaan, this is something that comes up now and then as you've seen and we started a project around this idea a few months ago. I'm sure tomorrow after today's us holiday @qrkourier would be excited to share what we have and where we ended that effort. It's always a challenge with a small team to prioritize and I'm certain we'll return to these efforts at some point.

I think it'd be great to keep it in your personal repo for now however when the time comes if you're willing to contribute it back to the project it sounds like the sort of thing we would be happy to help maintain. Overall it's a non trivial effort and it will need to be directionally correct for the project, but i think it sounds like something we'll consider. I'll talk to some of the team and we'll get back. Until then, keep us posted as to how far along you get. :joy:

1 Like
3

Thanks, @TheLumberjack. I'm looking forward to hearing what @qrkourier has to say and to the challenges you identified. I'll gladly contribute back any progress I make in the meantime.

4

Hiya @rochecompaan, Iā€™m happy to coordinate efforts with you here in Discourse and in GitHub. :slightly_smiling_face:

Here's an updated map of what's been done, along with some next steps I have in mind.

  • Sidecar injector for transparent workload tunneling
    • ziti-webhook
    • add Helm chart
    • finish testing and release 1.0.0
  • Operator for managing Ziti entities as K8s resources
    • ZitiRouter - provision Ziti routers for node-local and intra-cluster overlay, publishing public edge and link listeners, etc.
    • ZitiWebhook - adapt to refactored webhook config scheme and refine Operator installation, e.g., Helm chart or nfctl CLI
    • ZitiController - adapt to new authN methods and clustered mode
    • add OpenAPI-to-CRD in Operator CI to automate the scaffolding of CRDs from the authoritative spec
    • add controllers for each CRD in Operator

I've planned some features and fixes in the GH Issues, too. :smiling_face:

5

Hey @qrkourier, thanks for the update. I'm glad to see you've already started on this. I'll familiarise myself with the current state of the GitHub repo and get back to you.

1 Like
6

Here's a video tour of the ziti-webhook part that I'm planning to ship as 1.0.0 when I get around to finishing testing: https://youtu.be/_tQo4CspDwk

1 Like
7

I just watched this, and I'm excited to try it out! Awesome to see transparent workload tunnelling!

I haven't had time to review all the progress in the GH repo thoroughly, but I was pleasantly surprised to see how much work has gone into it. When I have time again, I hope to have more usable feedback.

1 Like