Rework architecture diagram for v4

[r0ckarong]

Relates to:

#571
#716
#717

Replace the old diagram:

[r0ckarong]

Collecting some info here: https://confluence.suse.com/display/~mnapp/Architecture+Diagram+overhaul

[r0ckarong]

@flavio @ereslibre @kkaempf This is the current state. Is this any better? Are we missing something?

[ereslibre]

Some comments:

• I would put etcd out of System workloads. It could be inside the Control Plane group. The apiserver connects to it.

• kube-proxy is a DaemonSet in reality, so I would place it into System workloads in all nodes.

• kubelet talks to CRI-O.

• The load-balancer is not very clear from my perspective. It should connect to every apiserver on every control plane node. It should not connect to kubelet, or SSH. I would completely remove a layer in front of any SSH connection, we are targeting nodes directly, except for very specific customer setups where they could be using bastion nodes (I wouldn't draw this case).

• I don't fully understand what "Invoke Kubernetes" means, where it is coming from, and what is its purpose, going through "Internet".

• kubectl does not talk to the kubelet, but to the loadbalancer, that in turn, talks to the apiserver on every control plane node.

[r0ckarong]

* I don't fully understand what "Invoke Kubernetes" means, where it is coming from, and what is its purpose, going through "Internet".

This was some orphaned line from a previous user item. I've changed it now.

* `kubectl` does not talk to the `kubelet`, but to the `loadbalancer`, that in turn, talks to the `apiserver` on every control plane node.

Changed

[r0ckarong]

@Martin-Weiss Any thoughts on this ...

[Martin-Weiss]

@Martin-Weiss Any thoughts on this ...

Looks great - but yes - there is something missing that is mandatory for all enterprise customers with on-premise deployments.. -> airgap and staging is missing.

SUSE provides RPMs via SCC -> SMT/RMT/SUSE Manager
SUSE provides Images -> skopeo to on premise registry (docker-distribution-registry+portus - connected to LDAP/AD)
SUSE provides Helm Charts -> helm fetch / copy file to web-server -> helm index

For all there things we have to have staging and different namespaces for test/reference/production.

And then all internal components fetch their things from the internal sources based on the environment..

Some other thoughts:

• The LDAP server should not be hosted on the admin machine - this is external / fault tolerant and probably Active-Directory
• The load balancer should also be separated from the admin machine - this is external / fault tolerant and probably HAPROXY or F5 or similar
• The storage should not be "within the master / worker" as this is an external connected service - most often NFS to NetApp or SLES, or external Ceph or VSphere provisioner

[r0ckarong]

* The LDAP server should not be hosted on the admin machine - this is external / fault tolerant and probably Active-Directory

* The load balancer should also be separated from the admin machine - this is external / fault tolerant and probably HAPROXY or F5 or similar

It's not, there are two boxes, one is "Customer Infrastructure" and the smaller one is "Management Workstation" neither LDAP nor load balancer are in the smaller box.

* The storage should not be "within the master / worker" as this is an external connected service - most often NFS to NetApp or SLES, or external Ceph or VSphere provisioner

Moved the storage service in the new version.

For all there things we have to have staging and different namespaces for test/reference/production.

I don't think I can produce anything meaningful by representing namespaces in the same diagram as high level component overview. Staging setup and cluster specific namespaces are two entirely different levels of diagrams that are not in scope of this task.

The airgap diagram is still in the works, I'm trying to find the right level of detail between "airgap" as a concept and "all components" as with the detailed component diagram.