Harrison 
Kubernetes objects are persistent entities that represent the state of your cluster. These describe what you have deployed or want to deploy, such as a simple pod, network configuration, or application deployment with all mappings, resources, and policies. Kubernetes documentation uses the term “record of intent,” but what if you want to validate, modify, or manipulate this record before Kubernetes deploys?
For this purpose, you can code your own dynamic admission controller to validate or manipulate objects. For this reason, we don’t use the human-friendly Kubernetes request object that we’re used to. Instead, it presents the object as a JSON object, just as Kubernetes sees it.
If you look under the hood
Let’s take a look at a simple pod request written as we would write:
apiVersion: v1
kind: Pod
metadata:
name: nginx-pod
spec:
containers:
- name: nginx
image: docker.io/nginx:latest
However, this is not something Kubernetes is aware of. When Kubernetes actually manipulates objects, it looks like this:
kind: 'AdmissionReview',
apiVersion: 'admission.k8s.io/v1',
request:
uid: 'c83425ea-084c-47ae-939c-af0f34c038dd',
kind: group: '', version: 'v1', kind: 'Pod' ,
resource: group: '', version: 'v1', resource: 'pods' ,
requestKind: group: '', version: 'v1', kind: 'Pod' ,
requestResource: group: '', version: 'v1', resource: 'pods' ,
name: 'nginx-pod',
namespace: 'default',
operation: 'CREATE',
userInfo:
username: 'kubernetes-admin',
uid: 'aws-iam-authenticator:187383671122:AIDASXIHP5FJDYSGIGR7L',
groups: [Array],
extra: [Object]
,
object:
kind: 'Pod',
apiVersion: 'v1',
metadata: [Object],
spec: [Object],
status:
,
oldObject: null,
dryRun: false,
options:
kind: 'CreateOptions',
apiVersion: 'meta.k8s.io/v1',
fieldManager: 'kubectl-client-side-apply',
fieldValidation: 'Strict'
and this This is the object you need to manipulate in your code and is retrieved via the console log using a reference request named body. However, you will notice how some of the JSON data is compressed. Check how values are included in properties such as metadata and specifications. [object]. This is not a literal sentence. ”[object]” but instead you’ll see more JSON data filtered out in the console log.
However, that doesn’t mean you can’t access that data, you absolutely can. Instead of calling the entire body object to achieve this, you can call each subparameter such as body.request.object.spec or body.request.object.metadata into the body. You can refer to it as These are two of the most important objects. , when modifying or validating your deployment.
body.request.object.metadata contains metadata objects such as labels and names. Generally works to validate or modify labels and tagging. When expanded, it looks like this:
{
name: 'tester',
namespace: 'default',
creationTimestamp: null,
annotations:
'kubectl.kubernetes.io/last-applied-configuration': '"apiVersion":"v1","kind":"Pod","metadata":"annotations":,"name":"tester","namespace":"default","spec":"containers":["image":"docker.io/nginx:latest","name":"nginx"]n'
,
managedFields: [
manager: 'kubectl-client-side-apply',
operation: 'Update',
apiVersion: 'v1',
time: '2023-04-17T16:41:36Z',
fieldsType: 'FieldsV1',
fieldsV1: [Object]
]
}
Changes to Add Labels If you are creating a webhook (missing above as we did not add anything in the first pod description), you will need to inject the data here. This is done in this JSON format, as when creating a YAML object, rather than as if it were a YAML object (you also need to base64 encode the object, but that’s off topic) .
For example, the following Node.js code adds a label to the metadata while still being JSON (it won’t work because it’s not encoded, but you can see it):
res.send(
apiVersion: 'admission.k8s.io/v1',
kind: 'AdmissionReview',
response:
uid: uid,
allowed: true,
patchType: "JSONPatch",
patch: "["op": "add", "path": "/metadata/labels", "value": "env": "dev"]",
,
);
Of course, we don’t always change the data. Especially when working within a body.request.object.spec that contains deployment information such as container information, you may need to manipulate multiple parameters. when starting the pod. For this purpose, I would like to consider how to analyze the data.
Consider the body.request.object.spec of the pod deployment example.
volumes: [ name: 'kube-api-access-9fs5n', projected: [Object] ],
containers: [
name: 'nginx',
image: 'docker.io/nginx:latest',
resources: ,
volumeMounts: [Array],
terminationMessagePath: '/dev/termination-log',
terminationMessagePolicy: 'File',
imagePullPolicy: 'Always'
],
restartPolicy: 'Always',
terminationGracePeriodSeconds: 30,
dnsPolicy: 'ClusterFirst',
serviceAccountName: 'default',
serviceAccount: 'default',
securityContext: ,
schedulerName: 'default-scheduler',
tolerations: [
key: 'node.kubernetes.io/not-ready',
operator: 'Exists',
effect: 'NoExecute',
tolerationSeconds: 300
,
key: 'node.kubernetes.io/unreachable',
operator: 'Exists',
effect: 'NoExecute',
tolerationSeconds: 300
],
priority: 0,
enableServiceLinks: true,
preemptionPolicy: 'PreemptLowerPriority'
If you want to access multiple values from a container parameter, consider writing your code to iterate through the array of data and refer to each as something like container.name or container.image instead of a long body. is recommended. .request.object.spec.containers.name or body.request.object.spec.containers.image. Consider this Node.JS example. Here we call the body object’s parameters four times in different ways.
const uid = req.body.request.uid;
const object = req.body.request.object;
for (var container of object.spec.containers)
if (container.image.endsWith('latest'))
...<code truncated>...
else
...<code truncated>...
The first two objects (body.request.uid and body.request.object) directly call the required object field. In this case, the UID of the request and the entire request.object. You can call this on your shorthand object. Such reallocation makes it much easier to manipulate objects across objects in your code.
A further example of this is a for loop. This further iterates over object.spec.containers (actually body.request.object.spec.containers) so you can do things like reference body.request.obect.spec. Inside the loop we create containers.image as simple containers.image.
Starting to manipulate Kubernetes objects in your code can be intimidating, especially if you’re used to the human-readable YAML approach Kubernetes is commonly used with. But all of our JSON objects are just that: JSON. The same information is provided in both files, with JSON providing a detailed overview of what happens when you run kubectl apply on your test pod (or any pod, deployment, etc.).
To see this sample code (and others) in action, be sure to check out the course it came from: Designing a Dynamic Kubernetes Admission Controller to start extending your Kubernetes architecture. please.
