134
edits
Equipment/Blanton/Kubernetes: Difference between revisions
From London Hackspace Wiki
no edit summary
Mich181189 (talk | contribs) |
Mich181189 (talk | contribs) No edit summary |
||
| Line 40: | Line 40: | ||
MetalLB is configured to allocate IP addresses in the ranges 10.0.21.128/25 and 2a00:1d40:1843:182:f000::/68 - it uses layer 2 ARP to advertise these on the LAN. | MetalLB is configured to allocate IP addresses in the ranges 10.0.21.128/25 and 2a00:1d40:1843:182:f000::/68 - it uses layer 2 ARP to advertise these on the LAN. | ||
= Accessing the cluster = | |||
= Instructions Braindump = | '''Currently (useful) access is limited to those in the Admins ldap group'''. After a bit more testing though, I'd like to create a members namespace for members to play in. | ||
First, go get kubectl (preferably version 1.22.4 which, at the time of writing this, is the version the cluster runs) https://kubernetes.io/docs/tasks/tools/ | |||
Now go get the binary for your OS from https://github.com/londonhackspace/kube-auth-handler/releases/ and put it somewhere on your PATH as <code>ldap-kube-auth</code> | |||
'''Note: This is only tested on Linux so far, but should work on any OS supported by kubectl, possibly with some tweaks.''' | |||
Now stick the following in $HOME/.kube/config (if you already have a config in there, you'll need to merge them) | |||
<pre> | |||
apiVersion: v1 | |||
clusters: | |||
- cluster: | |||
certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUM1ekNDQWMrZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRJeE1EVXdOVEUyTXpFeE5sb1hEVE14TURVd016RTJNekV4Tmxvd0ZURVRNQkVHQTFVRQpBeE1LYTNWaVpYSnVaWFJsY3pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBTnZQClVia1htT21JcnRiSHhZZHdBd3ZIaUoxVmhORUFkMXpiNlVKdXI5MFJSNHJ1VTlIRjZIaWpVd3Z3YzQ4MGh0K1UKY3F0dlZ6TG55L29OWTBNM01DQkxTRU90VndiMlQ0RXB3SUtVQ3drdENOcXV0MTA4eGhvRjlFOUp5NnhPWG9FMQp6c0xMeWQwcm1WNzFmU1NsUGg1RG9SRWoxSnNUZFdKQitJL21MNDhDd2k2aENEaXdnU25ZeFBEWitCaEFvTkVNCkxiMm1rdDVFdXVXUmVhME40bGl0cThpWktYZy9VcEh2aUJvaGxWLzMvemJWWnZnY3RyTlBrcWJvZDdUM2pYa1oKZnNwR1VjU1g1aVRKMUJpUHowZ0dlNEJ0SndvT2tVdGNjRUk0M0o1aXhQMi9hWVYwcURCd1B3MWpmVUFDaGZ5RAptbkdUVUVCSUNzYWVnY3UweFVVQ0F3RUFBYU5DTUVBd0RnWURWUjBQQVFIL0JBUURBZ0trTUE4R0ExVWRFd0VCCi93UUZNQU1CQWY4d0hRWURWUjBPQkJZRUZGNlZkVFFoOWVGdzUzMWEydEh4S3ZmWkxqMDZNQTBHQ1NxR1NJYjMKRFFFQkN3VUFBNElCQVFDWVpBcDRqdWl5MjdoK041aXl5RVczNFYzMExRc2pxOHpWdlF5OHFORVJtUS9IRDVnQQpQQkFlWFpPdXZHaklHcVB2TS9BeWZYempPL25MK09aS1Vvay91eWFVUkxHYU1rSzBqVzVMb3ZOU28zVFMwTEU4CnJBQlRjeUdLYW40Tk9zN2FoSWM4SGdxa2lNOUR2cVhiRGlwbC9pbG95VnJCRDh3bzZ3RVBPSG1tUGZJdUJZYnUKUzNZY0JXRW90bVpSNWlxTWxWdDRIUXR0MUYzMmZyS21lcmFPNFdUM2hIMkRWNTQ3enlSYmF4cktOZ1VJL0FJQgoycG53dktYNlUyNFM0Z0lUbW8zTUZzNDNoTzk4NDU2YXYrVExrTkNrYVhCVktMaUtMU2NZMXJnQlFzN0JvSHp4CnR1aU5nQ241dnVLRTBWU0diK2FhTTgzdVl6Q001TjVuVm9xbAotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg== | |||
server: https://kube-master.lan.london.hackspace.org.uk:6443 | |||
name: lhs | |||
contexts: | |||
- context: | |||
cluster: lhs | |||
namespace: default | |||
user: lhsuser | |||
name: lhs | |||
current-context: lhs | |||
kind: Config | |||
preferences: {} | |||
users: | |||
- name: lhsuser | |||
user: | |||
exec: | |||
command: /usr/local/bin/ldap-kube-auth | |||
env: | |||
- name: AUTH_CLUSTER | |||
value: LHS | |||
- name: AUTH_URL | |||
value: https://kube-auth.lan.london.hackspace.org.uk/getToken | |||
interactiveMode: Always | |||
apiVersion: "client.authentication.k8s.io/v1" | |||
</pre> | |||
now you should be able to run commands: | |||
<pre> | |||
$ kubectl get pods | |||
kubectl LDAP login helper | |||
Logging into LHS | |||
Press enter for defaults | |||
Username (michael): mich181189 | |||
Password: NAME READY STATUS RESTARTS AGE | |||
dockerreg-8568799fdb-vwtgg 1/1 Running 0 173m | |||
</pre> | |||
== The slightly gory details == | |||
Kubernetes does not natively support LDAP authentication, so we use webhook tokens (https://kubernetes.io/docs/reference/access-authn-authz/authentication/#webhook-token-authentication). To make this easier to use, there is an credential plugin (https://kubernetes.io/docs/reference/access-authn-authz/authentication/#client-go-credential-plugins) | |||
The sources for the server and client implementations of this are on Github: https://github.com/londonhackspace/kube-auth-handler | |||
Tokens are valid for 6 hours, and get cached in $HOME/.kube/LHS_cache (assuming the above config is used) - delete this file if you think the cache is causing you problems. The caching is very necessary otherwise you get a prompt (or sometimes multiple prompts!) per command. Server-side, while JWTs might be popular, this service just generates random strings and stashes them in redis for later lookup | |||
Kubernetes is configured to check these tokens against a web service running in the cluster. This is done with the following chunk of kubeadm-config | |||
<pre> | |||
apiVersion: v1 | |||
data: | |||
ClusterConfiguration: | | |||
apiServer: | |||
extraArgs: | |||
authentication-token-webhook-config-file: /etc/kubernetes/auth/ldap-auth.yaml | |||
authentication-token-webhook-version: v1 | |||
</pre> | |||
and a patch passed to kubeadm to get it to mount /etc/kubernetes/auth into the apiserver container. If this patch is not used, it will cause the API server to refuse to start! (see the upgrade instructions below for how to specify the patch directory to kubeadm upgrade) | |||
The server deployment is in the (private) github repo kubernetes-config - this is just a fairly standard kubernetes service deployment. | |||
= Instructions Braindump For Admins = | |||
== Adding a node == | == Adding a node == | ||
