#+TODO: TODO(t) NEXT(n) WAITING(w) SOMEDAY(s) DELEGATED(g) PROJ(p) PLANNED(l) | DONE(d) FORWARDED(f) CANCELLED(c)
|
#+startup: beamer
|
#+LaTeX_CLASS: beamer
|
#+LaTeX_CLASS_OPTIONS: [a4paper]
|
#+LaTeX_CLASS_OPTIONS: [captions=tableheading]
|
#+LATEX_HEADER: \usetheme{Warsaw} \usepackage{courier}
|
#+LATEX_HEADER: \usepackage{textpos}
|
#+LATEX_HEADER: \RequirePackage{fancyvrb}
|
#+LATEX_HEADER: \DefineVerbatimEnvironment{verbatim}{Verbatim}{fontsize=\tiny}
|
# +LATEX_HEADER: \setbeamercolor{title}{fg=green}
|
# +LATEX_HEADER: \setbeamercolor{structure}{fg=black}
|
# +LATEX_HEADER: \setbeamercolor{section in head/foot}{fg=green}
|
# +LATEX_HEADER: \setbeamercolor{subsection in head/foot}{fg=green}
|
# +LATEX_HEADER: \setbeamercolor{item}{fg=green}
|
#+LATEX_HEADER: \setbeamerfont{frametitle}{family=\ttfamily}
|
# logo
|
# +LATEX_HEADER: \addtobeamertemplate{frametitle}{}{ \begin{textblock*}{100mm}(0.85\textwidth,-0.8cm) \includegraphics[height=0.7cm,width=2cm]{niit-logo.png} \end{textblock*}}
|
#+OPTIONS: toc:nil ^:nil
|
#+LANGUAGE: en
|
#+TITLE: Diving into OpenShift
|
|
|
|
* Helpful tools on the way
|
- *jq(1)* is a JSON query tool for the command line, a must have
|
- *yq* is a python script that does YAML queries
|
- yes, there's also *xq* for XML but that's for the JAVA folks ;)
|
- *jo* to produce JSON output on the shell
|
|
How to get?
|
- jq: it's very likely shipped as a package with your distribution
|
- yq: install via =pip install --user yq=
|
- xq: install via =pip install --user xq=
|
- jo: get the sources from https://github.com/jpmens/jo
|
|
* jq
|
The most basic usage is filter down a JSON for a specific attributes value.
|
#+begin_src js
|
{
|
"kind": "ServiceAccount",
|
"apiVersion": "v1",
|
"metadata": {
|
"name": "foobar",
|
"creationTimestamp": null
|
}
|
}
|
#+end_src
|
|
To get the name of the ServiceAccount you would run
|
|
=jq .metadata.name=
|
|
If you have a list, and want to see all items, use [], for example:
|
|
=jq .items[]=
|
|
If you want to get a specific list entry by index, run
|
|
=jq .items[5]= to get the sixth entry
|
|
* yq
|
*yq* works very similar in the basic usage as *jq*, however per default it outputs - confusing enough - JSON (because it's a wrapper for jq).
|
If you use the =-y= option, it will output YAML.
|
|
I find this very handy for reading data from =ConfigMaps=:
|
|
#+begin_example
|
$ oc get cm foobar -o yaml | yq -y .data
|
key: value
|
text: hello world
|
#+end_example
|
|
* jo
|
*jo* is a very special tool that can be very interesting if you have shell commands producing output that
|
should be converted into JSON. More examples can be found here: https://jpmens.net/2016/03/05/a-shell-command-to-create-json-jo/
|
|
#+begin_example
|
$ ps -fo uid,pid,ppid,stime,tty,time,args | nawk '$NF~/ksh/ {
|
> printf("uid=%s pid=%s ppid=%s stime=%s tty=%s cputime=%s comm=%s\n"
|
> , $1, $2, $3, $4, $5, $6, $7)}' | while read line; do jo ${line}
|
> done | jo -pa
|
[
|
{
|
"uid": 4100,
|
"pid": 4880,
|
"ppid": 4001,
|
"stime": "Jan_01",
|
"tty": "pts/2",
|
"cputime": "00:00",
|
"comm": "-ksh"
|
},
|
{
|
"uid": 4100,
|
"pid": 20599,
|
"ppid": 4880,
|
"stime": "23:46:19",
|
"tty": "pts/2",
|
"cputime": "00:00",
|
"comm": "-ksh"
|
}
|
]
|
#+end_example
|
|
* oc get -o jsonpath
|
If you use *oc* or *kubectl* to retreive JSON data, you can also filter down with JSONPATH
|
instead of using *jq*. The basic syntax is simple, imagine you want the hostname of a route,
|
which is in the =host= key under the =spec=:
|
|
#+begin_example
|
$ oc get -o jsonpath='{"http://"}{.spec.host}{"\n"}' route hi
|
http://hi-olbohlen-demo.apps-crc.testing
|
#+end_example
|
|
And because we are clever, we will create a shell alias from it:
|
#+begin_example
|
$ alias gr='oc get -o jsonpath="{\"http://\"}{.spec.host}{\"\n\"}" route '
|
[crc@lol cookie-operator]$ gr hi
|
http://hi-olbohlen-demo.apps-crc.testing
|
$ curl $(gr hi)
|
<html>
|
<head>
|
<title>hello php</title>
|
[...]
|
#+end_example
|
|
* Declarative versus Imperative
|
|
It's important to understand that Kubernetes works declarative.
|
What does that mean?
|
|
Traditionally we work imperative with computers, we tell them what and how to execute.
|
The problem here is, that the result is undefined, there are so many side-cases to catch.
|
|
If we work declarative, we declare our will to the computer and rely on algorithms that
|
shall fulfill our will. Of course this still can fail, but ideally the code results in "failed" or "completed".
|
|
* Controller Scheme
|
#+begin_src ditaa :file ocp-workshop1.png :cmdline -E -s 0.8
|
|
+---------------------------+ +-----------------------+ +-------------------------+
|
|{s} | | Kube API Server | | Kube Controller Manager |
|
| etcd | | | | |
|
| | <---> |etcd connector | <---> | watches API for updates |
|
|/kubernetes.io/pods/ns/pod | | | | if update: run code |
|
| | | REST Connector | | |
|
+---------------------------+ +-----------------------+ +-------------------------+
|
^
|
| HTTP(S)/REST
|
| (JSON)
|
v
|
+-----------------------+
|
| REST Client |
|
| |
|
| oc/kubectl |
|
| (converts JSON to |
|
| output format) |
|
| |
|
+-----------------------+
|
#+end_src
|
|
* Syntactic sugar
|
OpenShift's *oc* client, but also *kubectl* have various sub-commands to make the start with Kubernetes easier.
|
Especially in the beginning the idea to declare everything in JSON or YAML doesn't sound convincing.
|
|
But if you look under the hood, commands like *oc new-app* or *kubectl create* will send declarations.
|
|
You can validate that by doing a dry-run:
|
|
#+begin_example
|
$ oc create --dry-run=client -o yaml sa foobar
|
apiVersion: v1
|
kind: ServiceAccount
|
metadata:
|
creationTimestamp: null
|
name: foobar
|
#+end_example
|
|
* Dry-Runs
|
There are two ways of dry-runs: =client= and =server=
|
|
If we do a client dry-run, nothing gets sent to the kubernetes API, so we basically only test
|
if we can convert the local YAML into JSON. Illegal values, missing required keys or immutable values cannot be detected.
|
|
if you however use a =server= dry-run, your declaration gets sent to the API, but it will not get persisted into the ETCD.
|
|
#+begin_example
|
$ oc create --dry-run=server -o yaml sa foobar
|
apiVersion: v1
|
kind: ServiceAccount
|
metadata:
|
creationTimestamp: "2023-01-02T20:33:23Z"
|
name: foobar
|
namespace: kitchen
|
uid: 3bfc1a4c-9a87-4bfa-9dd7-c0941a98ec1f
|
$ oc get sa foobar
|
Error from server (NotFound): serviceaccounts "foobar" not found
|
#+end_example
|
|
As you can see, you get an =uid= and a =creationTimestamp= back. However, it will not actually be created.
|
|
* Client Side debugging
|
Turn on the debugging in *oc* / *kubectl* with =--loglevel=x=, the higher the value, the more verbose.
|
If you want to see a lot of details, =--loglevel=9= is very helpful.
|
|
For example if you want to validate how server side dry-runs work, run:
|
#+begin_example
|
$ oc --loglevel=9 create --dry-run=server -o yaml sa foobar
|
I0102 21:39:10.590303 1993958 loader.go:372] Config loaded from file: /home/crc/.kube/config
|
[...]
|
I0102 21:39:10.818643 1993958 request.go:1073] Request Body: {"kind":"ServiceAccount",
|
"apiVersion":"v1","metadata":{"name":"foobar","creationTimestamp":null}}
|
I0102 21:39:10.818703 1993958 round_trippers.go:466] curl -v -XPOST
|
-H "Content-Type: application/json" -H "Accept: application/json, */*"
|
-H "User-Agent: oc/4.11.0 (linux/amd64) kubernetes/1928ac4"
|
-H "Authorization: Bearer <masked>" 'https://api.crc.testing:6443/api/v1/namespaces/kitchen/
|
serviceaccounts?dryRun=All&fieldManager=kubectl-create&fieldValidation=Ignore'
|
I0102 21:39:10.822375 1993958 round_trippers.go:553] POST https://api.crc.testing:6443/api/
|
v1/namespaces/kitchen/serviceaccounts?dryRun=All&fieldManager=kubectl-create&
|
fieldValidation=Ignore 201 Created in 3 milliseconds
|
[...]
|
#+end_example
|
|
Very handy is that with =--loglevel=9=, *oc* will also print a *curl* command line that could be used to
|
simulate that call.
|
|
* Use curl to modify K8s resources
|
|
Using the log output from the previous slide, we can now try to create a =ServiceAccount= via *curl*.
|
We need of course the JSON declaration...thankfull we can generate that with a client dry-run:
|
|
#+begin_example
|
$ oc create --dry-run=client -o json sa foobar >/tmp/sa-foobar.json
|
$ curl -k -s -XPOST -d "@/tmp/sa-foobar.json" -H "Content-Type: application/json" \
|
> -H "Accept: application/json, */*" -H "User-Agent: oc/4.11.0 (linux/amd64) kubernetes/1928ac4" \
|
> -H "Authorization: Bearer $(oc whoami -t)" \
|
> 'https://api.crc.testing:6443/api/v1/namespaces/api-access/serviceaccounts?fieldManager=\
|
> kubectl-create&fieldValidation=Ignore'
|
$ oc get sa foobar
|
NAME SECRETS AGE
|
foobar 1 11s
|
#+end_example
|
|
And how to delete the =ServiceAccount=? Simple:
|
#+begin_example
|
$ curl -k -XDELETE -H "Content-Type: application/json" -H "Accept: application/json, */*" \
|
> -H "User-Agent: oc/4.11.0 (linux/amd64) kubernetes/1928ac4" \
|
> -H "Authorization: Bearer $(oc whoami -t)" \
|
> 'https://api.crc.testing:6443/api/v1/namespaces/api-access/serviceaccounts/foobar'
|
{"kind":"ServiceAccount","apiVersion":"v1","metadata":{"name":"foobar",
|
"namespace":"api-access","uid":"94a1c0b4-2177-41b7-bbe2-0ff5e3932785","resourceVersion":"1258915",
|
"creationTimestamp":"2023-01-02T20:57:35Z"},"secrets":[{"name":"foobar-dockercfg-brshk"}],
|
"imagePullSecrets":[{"name":"foobar-dockercfg-brshk"}]}
|
$ oc get sa foobar
|
Error from server (NotFound): serviceaccounts "foobar" not found
|
#+end_example
|
|
* Weird effects with the K8s API
|
|
- the API will ignore unkown keys, so you could put a "=Olaf: was here=" key-value pair anywhere you want, the API will happily ignore it!
|
- that means, if you *oc edit* a resource and damage the name of a key or dictionary which is not mandatory, it will throw away those definitions (=OAuth/cluster.spec.IdentityProviders=)
|
- You can create dependent resources on non-existing objects, i.e. you can give non-existing users privileges: ETCD does not support referential integrity, so no forein key constraints
|
- your declaration will be processed after your client terminated the REST connection, so always check the results!
|
|
* Short Refresh on RBAC
|
Kubernetes supports Role Based Access Controls (RBAC)
|
|
We have five different resources here:
|
- =Users=
|
- =Groups=
|
- =ServiceAccounts=
|
- =Roles= / =ClusterRoles=
|
- =RoleBindings= / =ClusterRoleBindings=
|
|
* Users and Groups
|
=Users= are a resource that have an access token, to talk to the external API.
|
|
=Groups= bundle =Users=, as you would expect.
|
|
There are also system Users (they contain colons..) which are *hard coded* and there is no way to list them via the API.
|
The same is true for system Groups!
|
|
System Users cannot authenticate via the external API.
|
|
* ServiceAccounts
|
If =Pods= would run under the User who created the =Pod=, others probably couldn't operate on them.
|
For that reason we need =ServiceAccounts=, they bundle permissions (=Roles=, =SCCs=), specific secrets (for pulling Images, etc)
|
and they have an API Access Token that we can use within the =Pod= to talk to the Kubernetes API.
|
|
* Roles / ClusterRoles
|
Where is the difference between =Roles= and =ClusterRoles=?
|
|
It just says if the resource itself is scoped in a =Namespace= or if it's available for the whole Cluster.
|
If you want to define a Role for all Namespaces in your Cluster, you create a =ClusterRole=.
|
If you need a local Role just for a specific Namespace, you create a =Role=.
|
|
* How does a ClusterRole look like?
|
A =Role= contains a list of =Rules=, specifying what is allowed if you own that =Role=.
|
The most simple one is the =cluster-admin= =ClusterRole=.
|
|
#+begin_example
|
$ oc get clusterrole cluster-admin -o yaml
|
apiVersion: rbac.authorization.k8s.io/v1
|
kind: ClusterRole
|
metadata:
|
annotations:
|
rbac.authorization.kubernetes.io/autoupdate: "true"
|
creationTimestamp: "2022-12-06T10:10:16Z"
|
labels:
|
kubernetes.io/bootstrapping: rbac-defaults
|
name: cluster-admin
|
resourceVersion: "75"
|
uid: d6fd1146-5bc7-4815-8170-3905ae1e2856
|
rules:
|
- apiGroups:
|
- '*'
|
resources:
|
- '*'
|
verbs:
|
- '*'
|
- nonResourceURLs:
|
- '*'
|
verbs:
|
- '*'
|
#+end_example
|
So you can issue any command verb on any resource in any apiGroup. (iddqd)
|
|
* And what is a RoleBinding?
|
#+begin_src ditaa :file rbac.png :cmdline -E -s 0.8
|
+------+ +------+
|
| User | | Role |
|
| |--------+ +--------------------+ +-----| |
|
+------+ +------->| RoleBinding | <---+ +------+
|
| |
|
+----------------+ +--->| |
|
| ServiceAccount |--+ +--------------------+
|
| | ^
|
+----------------+ |
|
|
|
+-------+ |
|
| Group |----------------------+
|
| |
|
+-------+
|
#+end_src
|
|
#+begin_example
|
$ oc get rolebinding admin -o yaml
|
apiVersion: rbac.authorization.k8s.io/v1
|
kind: RoleBinding
|
metadata:
|
creationTimestamp: "2023-01-02T20:55:05Z"
|
name: admin
|
namespace: api-access
|
resourceVersion: "1258364"
|
uid: a59f1f83-86b1-47eb-97ea-985f13d03102
|
roleRef:
|
apiGroup: rbac.authorization.k8s.io
|
kind: ClusterRole
|
name: admin
|
subjects:
|
- apiGroup: rbac.authorization.k8s.io
|
kind: User
|
name: kubeadmin
|
#+end_example
|
|
* And a ClusterRoleBinding?
|
|
Well, a =ClusterRoleBinding= binds on a Cluster-scope, so the permissions take effect cluster-wide.
|
Note here that there is no =metadata.namespace:= attribute
|
#+begin_example
|
$ oc get clusterrolebinding cluster-admin -o yaml
|
apiVersion: rbac.authorization.k8s.io/v1
|
kind: ClusterRoleBinding
|
metadata:
|
annotations:
|
rbac.authorization.kubernetes.io/autoupdate: "true"
|
creationTimestamp: "2022-12-06T10:10:17Z"
|
labels:
|
kubernetes.io/bootstrapping: rbac-defaults
|
name: cluster-admin
|
resourceVersion: "159"
|
uid: b971b2ac-e3a8-4db9-ba91-f017ec0a7a5f
|
roleRef:
|
apiGroup: rbac.authorization.k8s.io
|
kind: ClusterRole
|
name: cluster-admin
|
subjects:
|
- apiGroup: rbac.authorization.k8s.io
|
kind: Group
|
name: system:masters
|
#+end_example
|
|
* I need a cookie receipt database!
|
|
...and because it makes total sense, we are going to abuse the K8s API for it.
|
|
- thankfully we can extend K8s with Custom Resource Definitions (CRDs)
|
- but how does it work?
|
- =CustomResourceDefinitions= are themselves a =Resource=, based on a =ResourceDefinition=
|
|
#+begin_example
|
$ oc api-resources | egrep "(NAME|CustomResourceDefinition)"
|
NAME SHORTNAMES APIVERSION NAMESPACED KIND
|
customresourcedefinitions crd,crds apiextensions.k8s.io/v1 false CustomResourceDefinition
|
$ oc explain crds
|
KIND: CustomResourceDefinition
|
VERSION: apiextensions.k8s.io/v1
|
|
DESCRIPTION:
|
CustomResourceDefinition represents a resource that should be exposed on
|
the API server. Its name MUST be in the format <.spec.name>.<.spec.group>.
|
[...]
|
#+end_example
|
|
* Preparing the cookiereceipts CRD
|
|
Let's create the CRD from https://www.eenfach.de/gitblit/blob/~olbohlen!cookie-operator.git/master/cookie-crd.yaml
|
|
#+begin_example
|
$ oc new-project kitchen
|
Now using project "kitchen" on server "https://api.crc.testing:6443".
|
$ oc create -f cookie-crd.yaml
|
Error from server (Forbidden): error when creating "cookie-crd.yaml":
|
customresourcedefinitions.apiextensions.k8s.io is forbidden: User "developer"
|
cannot create resource "customresourcedefinitions" in API group "apiextensions.k8s.io"
|
at the cluster scope
|
|
$ oc login -u kubeadmin
|
$ oc create -f cookie-crd.yaml
|
customresourcedefinition.apiextensions.k8s.io/cookiereceipts.de.eenfach.olbohlen created
|
$ oc login -u developer
|
#+end_example
|
|
Now the cluster knows about the CRD and we could store receipts!
|
|
* Storing some sample receipts
|
|
We try to store sample cookie receipts...but:
|
|
#+begin_example
|
$ oc create -f sample-cookie.yaml
|
Error from server (Forbidden): error when creating "sample-cookie.yaml":
|
cookiereceipts.de.eenfach.olbohlen is forbidden: User "developer" cannot create
|
resource "cookiereceipts" in API group "de.eenfach.olbohlen" in the namespace "kitchen"
|
Error from server (Forbidden): error when creating "sample-cookie.yaml":
|
cookiereceipts.de.eenfach.olbohlen is forbidden: User "developer" cannot create
|
resource "cookiereceipts" in API group "de.eenfach.olbohlen" in the namespace "kitchen"
|
#+end_example
|
|
We need to set up some RBAC resources first:
|
- a =ClusterRole= that allows viewing receipts
|
- a =ClusterRole= that allows editing receipts
|
- and a =ClusterRoleBinding= that allows that for authenticated users
|
|
* Creating RBAC resources
|
|
Apply the RBAC definitions from: https://www.eenfach.de/gitblit/blob/~olbohlen!cookie-operator.git/master/cookie-rbac.yaml
|
#+begin_example
|
$ oc login -u kubeadmin
|
$ oc create -f cookie-rbac.yaml
|
clusterrole.rbac.authorization.k8s.io/cookiereceipt-edit created
|
clusterrole.rbac.authorization.k8s.io/cookiereceipt-view created
|
clusterrolebinding.rbac.authorization.k8s.io/cookiereceipt-edit created
|
#+end_example
|
|
The =ClusterRoleBinding= "cookiereceipt-edit" allows =system:authenticated:oauth=
|
group members to edit =cookiereceipts=.
|
=system:authenticated:oauth= contains all users that logged in via the OAuth
|
service (via an =IdentityProvider=).
|
|
* Storing some sample receipts (hopefully this time!!)
|
|
Now we should be able to create the sample receipts:
|
|
#+begin_example
|
$ oc login -u developer
|
$ oc create -f sample-cookie.yaml
|
cookiereceipt.de.eenfach.olbohlen/vintage-chocolate-chip created
|
cookiereceipt.de.eenfach.olbohlen/double-dipped-shortbread created
|
$ oc get cookiereceipt
|
NAME AGE
|
double-dipped-shortbread 17s
|
vintage-chocolate-chip 17s
|
#+end_example
|
|
There is no functionality here - we just stored the receipts in the etcd via the K8s API.
|
|
* Can we validate that in the ETCD?
|
|
Yes, we can use *etcdctl* to look into the db
|
|
#+begin_example
|
$ oc login -u kubeadmin
|
$ oc rsh -n openshift-etcd -c etcdctl \
|
> etcd-crc-pbwlw-master-0 etcdctl get / --prefix --keys-only | grep -i cookie
|
/kubernetes.io/apiextensions.k8s.io/customresourcedefinitions/cookiereceipts.de.eenfach.olbohlen
|
/kubernetes.io/apiserver.openshift.io/apirequestcounts/cookiereceipts.v1.de.eenfach.olbohlen
|
/kubernetes.io/clusterrolebindings/cookiereceipt-edit
|
/kubernetes.io/clusterroles/cookiereceipt-edit
|
/kubernetes.io/clusterroles/cookiereceipt-view
|
/kubernetes.io/de.eenfach.olbohlen/cookiereceipts/kitchen/double-dipped-shortbread
|
/kubernetes.io/de.eenfach.olbohlen/cookiereceipts/kitchen/vintage-chocolate-chip
|
/kubernetes.io/secrets/openshift-machine-config-operator/cookie-secret
|
#+end_example
|
|
The =etcd pod= in the =openshift-etcd= project has a sidecar container called =etcdctl=
|
which contains the *etcdctl* utility and the correct environment.
|
The data hierarchy starts with =/= and with =--keys-only= we don't get the values.
|
|
* Let's look into a receipt
|
|
Check if we can *etcdctl get* on a known receipt:
|
#+begin_example
|
$ oc rsh -n openshift-etcd -c etcdctl etcd-crc-pbwlw-master-0 etcdctl \
|
> get /kubernetes.io/de.eenfach.olbohlen/cookiereceipts/kitchen/vintage-chocolate-chip
|
/kubernetes.io/de.eenfach.olbohlen/cookiereceipts/kitchen/vintage-chocolate-chip
|
{"apiVersion":"de.eenfach.olbohlen/v1","kind":"CookieReceipt","metadata":{
|
"creationTimestamp":"2023-01-02T15:18:49Z","generation":1,"managedFields":
|
[{"apiVersion":"de.eenfach.olbohlen/v1","fieldsType":"FieldsV1",
|
|
[...]
|
#+end_example
|
With *etcdctl put*, we could also update the entry and *etcdctl watch* allows us to
|
see updates to reosurces.
|
|
#+begin_example
|
$ oc rsh -n openshift-etcd -c etcdctl etcd-crc-pbwlw-master-0 etcdctl watch \
|
> --prefix /kubernetes.io/de.eenfach.olbohlen/cookiereceipts
|
PUT
|
/kubernetes.io/de.eenfach.olbohlen/cookiereceipts/kitchen/double-dipped-shortbread
|
{"apiVersion":"de.eenfach.olbohlen/v1","kind":"CookieReceipt","metadata":{"annotations":
|
{"kubectl.kubernetes.io/last-applied-configuration":"{\"apiVersion\":
|
\"de.eenfach.olbohlen/v1\",\"kind\":\"CookieReceipt\",\"metadata\":{
|
[...]
|
#+end_example
|
(run an *oc* apply/replace/create/delete in another terminal)
|
|
* Now can we do anything with our receipts?
|
Of course we can *oc get -o yaml* for example on them and filter:
|
|
#+begin_example
|
$ oc get cookiereceipt vintage-chocolate-chip -o yaml | yq -y .spec.ingredients[0]
|
amount: 150
|
name: salted butter
|
remarks: softened
|
unit: grams
|
#+end_example
|
|
This is handy, as we can extract exactly the data which we need at a time.
|
|
But...it's a lot of manual work...
|
|
* I'm an operator with my pocket calculator
|
|
Operators were introduced as "Kubernetes Native Applications" and that actually
|
means nothing. Operators are in the end just =Pods=.
|
|
These Pods run one or more containers, but one container should run a =Controller=
|
that can interprete your =CustomResources=.
|
|
So let's write a CookieReceipt Operator. In shell-script... :)
|
|
Of course this Operator is not compatible with the =OperatorLifecycyleManager= (=OLM=),
|
so we have to install it manually.
|
|
* What do we need?
|
|
We need:
|
- a ContainerImage
|
- and therefore probably a *Containerfile*
|
- Controller code
|
|
Then we are going to build the Operator ContainerImage and push it to a Registry.
|
|
* Let's review the Containerfile
|
|
The Containerfile is here:
|
|
https://www.eenfach.de/gitblit/blob/~olbohlen!cookie-operator.git/master/Containerfile
|
|
the base image is a "kshbase" image, which itself is based upon ubi9 containing also a ksh93
|
and an oc client.
|
|
* Have a look at the Controller
|
|
The controller is written in KornShell 93 (ksh93), which is mostly bash compatible :)
|
|
The code is here:
|
|
https://www.eenfach.de/gitblit/blob/~olbohlen!cookie-operator.git/master/receipt-processor.ksh
|
|
* Now let's also have a look at the deployment
|
|
Note: this deployment does not use an =ImageStream=, so it would work also on native k8s
|
|
https://www.eenfach.de/gitblit/blob/~olbohlen!cookie-operator.git/master/cookie-operator-deployment.yaml
|
|
This deployment requires a =ServiceAccount= called "cookieprocessor", this =ServiceAccount= provides
|
a Token to authenticate against the API (which we use in the controller script).
|
|
* The ServiceAccount
|
|
We need a =ServiceAccount=, but that alone will not help. The =ServiceAccount= is NOT member
|
of =system:authenticated:oauth=, so it can't read =cookiereceipts= based on the =ClusterRoleBinding= we created earlier.
|
For that reason we also create a =RoleBinding= (namespaced!) that allows reading receipts:
|
|
https://www.eenfach.de/gitblit/blob/~olbohlen!cookie-operator.git/master/cookieprocessor-sa.yaml
|
|
* Building the stuff together
|
|
#+begin_example
|
$ oc create -f cookieprocessor-sa.yaml
|
serviceaccount/cookieprocessor created
|
rolebinding.rbac.authorization.k8s.io/cookiereceipt-view created
|
#+end_example
|
|
The registry docker.eenfach.de requires login credentials, so we need to set up a secret and link it.
|
First login to the registry with *podman login*, then pick the resulting auth.json:
|
|
#+begin_example
|
$ podman login -u olbohlen docker.eenfach.de
|
Password:
|
Login Succeeded!
|
$ oc create secret generic docker-eenfach-de \
|
> --from-file=.dockerconfigjson=${XDG_RUNTIME_DIR}/containers/auth.json \
|
> --type kubernetes.io/dockerconfigjson
|
secret/docker-eenfach-de created
|
$ oc secrets link cookieprocessor docker-eenfach-de --for pull
|
#+end_example
|
|
* Deploying the Operator
|
|
Now that we have everything in place, we will just deploy the Operator Pod:
|
|
#+begin_example
|
$ oc create -f cookie-operator-deployment.yaml
|
deployment.apps/receipt-processor created
|
$ oc get pod
|
NAME READY STATUS RESTARTS AGE
|
receipt-processor-7f9969697b-qt9lv 1/1 Running 0 17s
|
$ oc logs -f receipt-processor-7f9969697b-qt9lv
|
|
|
New receipt found: double-dipped-shortbread
|
--------------------------------------------------------------------------
|
|
Pre: we heat up the oven to 180 degrees Celsius
|
|
Fetching ingredients from receipt:
|
----------------------------------
|
Fetching 200grams of salted butter (softened)
|
[...]
|
#+end_example
|
|
The Operator will process both sample receipts.
|
|
* Test the Operator
|
|
We should test if the Operator notices new receipts, so let's create a third
|
receipt from
|
https://www.eenfach.de/gitblit/blob/~olbohlen!cookie-operator.git/master/oaty-hazelnut-cookies.yaml
|
|
#+begin_example
|
$ oc create -f oaty-hazelnut-cookies.yaml
|
cookiereceipt.de.eenfach.olbohlen/oaty-hazelnut created
|
#+end_example
|
|
After a few seconds, we should see in the Operator log:
|
#+begin_example
|
New receipt found: oaty-hazelnut
|
--------------------------------------------------------------------------
|
|
Pre: we heat up the oven to 180 degrees Celsius
|
[...]
|
#+end_example
|
|
* Test for updated receipts
|
|
But what if we update a resource?
|
Keep the *oc logs -f* on the Operator Pod open, and in another terminal let's patch a receipt.
|
|
#+begin_example
|
$ oc patch cookiereceipts double-dipped-shortbread --type merge \
|
> -p '{"spec":{"temperature":172}}'
|
cookiereceipt.de.eenfach.olbohlen/double-dipped-shortbread patched
|
#+end_example
|
|
And again in the log you should see
|
|
#+begin_example
|
New receipt found: double-dipped-shortbread
|
--------------------------------------------------------------------------
|
|
Pre: we heat up the oven to 172 degrees Celsius
|
|
Fetching ingredients from receipt:
|
----------------------------------
|
[...]
|
#+end_example
|
|
* Thank You
|
|
Thank you for your attention.\\
|
\\
|
Do you have any questions?\\
|
\\
|
Feel free to ask now or contact me later:
|
|
[[mailto:olaf.bohlen@niit.com][olaf.bohlen@niit.com]]
|
