From a2b67b226f4177bbf18b55eeb0c4175d830d7d8a Mon Sep 17 00:00:00 2001 From: antoinetran Date: Fri, 31 Jan 2025 11:42:03 +0100 Subject: [PATCH] doc 06-enable-service-accounts --- .../guides/06-enable-service-accounts.mdx | 373 ++++++++++++++++++ 1 file changed, 373 insertions(+) create mode 100644 docs/docs/guides/06-enable-service-accounts.mdx diff --git a/docs/docs/guides/06-enable-service-accounts.mdx b/docs/docs/guides/06-enable-service-accounts.mdx new file mode 100644 index 00000000..46c60b75 --- /dev/null +++ b/docs/docs/guides/06-enable-service-accounts.mdx @@ -0,0 +1,373 @@ +--- +sidebar_position: 6 +--- +import ThemedImage from '@theme/ThemedImage'; +import useBaseUrl from '@docusaurus/useBaseUrl'; + +# Enable service accounts + +By default, InterLink does not translate Kubernetes Service Accounts from Pod into Plugin. That means workload that needs to interact with Kubernetes API like Argo will not work. + +However after following deployment and configuration in this guide, InterLink will give means for Plugin for that. A test has been done with InterLink Slurm Plugin and Argo. + +There are two parts on this guide: how to deploy means to access Kubernetes API service from external cluster network, and how to configure InterLink so that Plugin can access it. + +The prerequisite of this guide are: +- provide an external way to access Kubernetes API service (out of scope of InterLink, but an example is written below) +- provide certificates (that can be self-signed), and its CA root certificate (also out of scope of InterLink, but an example is written below) + +## Provide an external way to access Kubernetes API service + +By default, InterLink Plugin containers cannot access Kubernetes internal network. Thus they cannot access Kubernetes API service (`kubernetes.default.svc.cluster.local`). Kubernetes offers ways to access internal services (see https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types): +- LoadBalancer +- NodePort +- ... + +Because this is highly dependent of the Kubernetes cluster infrastructure, this deployment is out of scope of InterLink automatic deployment. However, below are examples of how and what to deploy, using ingress. This requires a bit of Ingress knowledge as prerequisite. + +### Design of ingress use + +The Kubernetes cluster can already contain an Ingress resource to let external access to web services. However it is a best-practice to separate internal (meaning flow between Kubernetes and Plugin infrastructure, like Slurm machines) and external flows (meaning flow between Kubernetes and the world). + +This guide will thus deploy as an example another ingress separate from the already existing ingress, if it exist. This also works if there is no ingress yet. + +Here is a diagram (generated with https://asciiflow.com) with Interlink Slurm Plugin as example. This Kubernetes cluster is deployed next to a Slurm cluster, but it can also be deployed on cloud. + +Because Ingress can only serve services in the same namespace, and because Kubernetes API is in default namespace, different from the Ingress "ingress-nginx-internal", a reverse-proxy NGINX HTTPS is instantiated to make Kubernetes API available to Ingress. + +``` + ┌───────────────────────────┐ + │ │ + │ Kubernetes cluster │ + │┌────────┐ ┌───────────┐ │ + ││K8S API ├───┤Nginx HTTPS│ │ + │└────────┘ └─────┬─────┘ │ + │ │ │ Slurm cluster + └─┬─────────────────┼───────┘ │ + │Ingress │Ingress ──────────┴───────── + │TCP 80, 443 │TCP 6080, 60443 Slurm network + ┌─────┴────┐ ┌───┴──────┐ ──────────┬───────── + │ External │ │ Internal │ │ + │ Firewall │ │ Firewall │ │ + └─────┬────┘ └───┬──────┘ ┌────────┐ │ + │ └──────────────┤ Router ├─────┘ + xxxxxxxxx xxxx └────────┘ + x xxx xxx + xx x + xx Internet x +x xxxxx +x x xx +xxxxxxx xxx + xxxxxxxxx +``` + +### NGINX HTTPS + +This deploys a reverse-proxy. + +``` +cat <