YAML basics in Kubernetes (K8s), examples and debugging

1 Likes
over 1 year ago

YAML (Yet Another Markup Language) is a superset of JSON, which means that it has all the functionality of JSON, but it also extends this functionality to some degree. It is very strict about the indentations

YAML Configuration File is the main tool for creating and configuring components in the Kubernetes cluster.  There are a few required fields in every Kubernetes YAML file:

  • apiVersion - Which version of the Kubernetes API you're using to create this object?
  • kind - What kind of object you want to create?
  • metadata - Data that helps uniquely identify the object, including a name string, UID, and an optional namespace.
  • spec - What state you desire for the object?

Concerning NetIQ Access manager, you will come across mostly the following types of objects

  • kind: StatefulSet
  • kind: Service
  • kind: Pod
  • kind: PersistentVolume
  • kind: PersistentVolumeClaim
  • kind: Secret

Service specification (spec): We define a selector which makes a connection between the service and the deployment. Service must know which pods belong to that service and the selector of the label helps here.

Pod specification (spec): We define

  • Which image pod should be based on?
  • Which port it should open?
  • What is going to be the name of a container? etc

The way the connection is established is by using labels and selectors. In metadata, we supply components like deployment or pod a key-value pair. The metadata part contains the labels and the specification part contains selectors.

Here are some of the properties you will see for a container:

  • name
  • image
  • command
  • args
  • workingDir
  • ports
  • env
  • resources
  • volumeMounts
  • livenessProbe/ readinessProbe

 Let us look at an example of a StatefulSet governed by a Service
 

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: statefulset-name
spec:
  selector: #Which pods are managed by this StatefulSet service?
    matchLabels: #This must match the labels we set on the pod
      app: app-name
 
serviceName: "service-name"
 
replicas: 3 #How many copies of each pod do we want?
 
updateStrategy: #How do want to update the pods?
    type: RollingUpdate
 
template: #This template field is a regular pod configuration 
    metadata:
      labels: #Set labels on the pod
        app: app-name
   
spec:
      containers:
      - name: container-name
       
image: ...
        ports:
        - containerPort: 80
         
name: port-name
       
volumeMounts:
        - name: pvc-name
         
mountPath: ...
  volumeClaimTemplates:
  - metadata:
      name: pvc-name
     
annotations:
        ...
    spec:
      accessModes: [ "ReadWriteOnce" ]
     
resources:
        requests:
          storage: 1Gi #Capacity of the volume  

Debugging:

Using the following commands I will get the resulting or the updated configuration of the deployment. All these configurations are automatically added and updated constantly by Kubernetes. For example, it says how many replicas are running, what the state of those replicas, and some other information. This part can also be helpful when debugging whether the current state of the deployment is matching from the expected YAML configuration file we deployed on the K8s cluster.

If the deployment is not part of default namespace, you will have to add -n <namespace> in all the commands. For example kubectl get pods -n <namespace>

  • Statefulsets (sts) : kubectl get statefulsets <name> -o yaml
  • Service (svc) : kubectl get svc <service-name> -o yaml
  • PersistentVolume (pv) : kubectl get pv <name> -o yaml
  • PersistentVolumeClaim (pvc) : kubectl get pvc <name> -o yaml
  • Pod: kubectl get pod <pod-name> -o yaml

If you are wondering how to get the name of the required object, you can use kubectl get <object> command.

I have taken out snippets from NetIQ Access Manager docker deployment by running the above-mentioned commands for better understanding but these are just for illustration as the docker support is under heavy development.

Service (svc)
spec:
clusterIP: None
ports:
- name: port-8443
port: 8443
protocol: TCP
targetPort: 8443
selector:
app.kubernetes.io/name: am-idp

PersistentVolume (pv) 
spec:
accessModes:
- ReadWriteOnce
capacity:
storage: 256Mi
claimRef:
apiVersion: v1
kind: PersistentVolumeClaim
name: idp-storage-access-manager-am-idp-0
namespace: development
hostPath:
path: /mnt/am-idp/
persistentVolumeReclaimPolicy: Retain

PersistentVolumeClaim (pvc)
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 256Mi
selector:
matchLabels:
group: am-idp-storage
volumeMode: Filesystem
volumeName: am-idp-volume-0
status:
accessModes:
- ReadWriteOnce
capacity:
storage: 256Mi

Pod
containers:
- env:
- name: admin_name
valueFrom:
secretKeyRef:
key: admin_name
name: admin-credentials
- name: admin_password
valueFrom:
secretKeyRef:
key: admin_password
name: admin-credentials
- name: ac_ip
valueFrom:
configMapKeyRef:
key: ac_ip
name: am-config
image: security-accessmanager-docker.demo/am-idp:5.0.0.0-475
imagePullPolicy: Always
volumeMounts:
- mountPath: /opt/novell/devman/jcc/conf/runtime
name: idp-storage
subPath: config/jcc
- mountPath: /var/run/secrets/kubernetes.io/serviceaccount
name: default-token-g922m
readOnly: true
dnsPolicy: ClusterFirst
enableServiceLinks: true
hostNetwork: true
hostname: access-manager-am-idp-0
nodeName: namk8s-w3
subdomain: access-manager-am-idp
terminationGracePeriodSeconds: 30
volumes:
- name: idp-storage
persistentVolumeClaim:
claimName: idp-storage-access-manager-am-idp-0
- name: default-token-g922m
secret:
defaultMode: 420
secretName: default-token-g922m
name: am-idp
ready: true
restartCount: 1
started: true
state:
running:
startedAt: "2020-08-29T08:56:47Z"
hostIP: 10.1.1.1
phase: Running
podIP: 10.1.1.1
podIPs:
- ip: 10.1.1.1

To conclude:  Many applications require multiple resources to be created, such as a Deployment and a Service. Management of multiple resources can be simplified by grouping them in the same file (separated by --- in YAML).

I have added links to a couple of large configuration files. These YAML files are intuitive and also quite logically structured.

  1. Kubernetes Dashboard  
  2. Kubernetes Metrics Server 

Labels:

How To-Best Practice
Education-Training
Comment List
Anonymous
Related Discussions
Recommended