Application Delivery Management
Application Modernization & Connectivity
CyberRes
IT Operations Management
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:
Concerning NetIQ Access manager, you will come across mostly the following types of objects
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
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:
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
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>
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.