Kubernets(Container Orchestrator)
- Orhestration?
- Managing the lifecycles of containers. These are GUI/tools to automate following tasks: Deployment, Scaling up/down, Movement of containers from one host to another, Load balancing, Health monitoring.
- Examples of Container Orhestrators: Kubernets, Docker swarm, Nomad Kubernets Cluster has different microservices inside it.
<--------------------k8s cluster----------------------------------->
|----control-plane,master-------| |---------Worker node-----|
| micro_service1 | |micro_service2 |
| micro_service4 | | micro_servicen |
|-------------------------------| |-------------------------|
Kubernets Resources,Objects
Kubernets Resource = C++ Class Resource is a blueprint for creating objects.
kubernets Object = C++ Object is Instance created from resource(using yaml,json file), having behaviour, state, metadata, and configuration.
Types of k8 Resources/Objects
1. ClusterRole
Defines set of permissions or access control rules for resources across an entire Kubernetes cluster. it applies to all namespaces in the cluster.
$ test.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata: //Metadata of clusterRole
name: my-cluster-role
annotations: //Annotations: any number of key-value pairs, and can be used to provide additional context
my-annotation: "example"
namespace: "test"
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list", "watch"]
2. ConfigMap. kind: configmap
Object storing configuration of POD. Unlike most Kubernetes objects(Eg: Deployment that have a spec), a ConfigMap has data and binaryData fields. Both the data field and the binaryData are optional
A Kubernetes resource that stores configuration data in key-value pairs.
//Creating a configmap
# cat templates/configmap-tams.yaml
apiVersion: v1
king: ConfigMap
metadata: //Metadata store additional data about the ConfigMap and is typically defined as a key-value pair
name: tams-config
labels:
app: {{ .Values.image.app }} //Pick from values.yaml
data:
jams_config.yaml: |-
servicename: tamsc
kafka:
brokers: {{ .Values.kafka.brokers }} //Pick from values.yaml
topics:
{{- toYaml .Values.kafka.topics | nindent 10 }}
3. Deployment
"Deployment" object defines how an application should be deployed and managed in a cluster.
It defines declarative configuration for running a containerized application and declares desired number of replicas of the application is always running.
$ cat templates/Deployment.yaml
apiVersion: apps/v1 #(Required) Which version of the Kubernetes API you're using to create this object
kind: Deployment #(Required) What kind of object you want to create
metadata: #(Required) Data that helps uniquely identify the object
name: {{ .Values.image.app }} //Taken from values.yaml
spec: #(Required) What state you desire for the object
replicas: {{ .Values.replicaCount }}
volumes: //specifies the storage volumes that should be available to containers within the deployment
- name: tams-cfg-vol
configMap:
name: tamc-config
- name: tams-srx-cfg-vol
$ kubectl apply -f test.yaml
4. Job
This object runs a specific task to completion. will create 1 or more pods and execute continously until job completes.
apiVersion: batch/v1
kind: Job
metadata:
name: pi #Name of Job
spec:
template:
spec:
serviceAccountName: "Test" // Name of ServiceAccount that should be used by the pod that is created to run the Job
containers: //Container configuration for job
- name: pi // Container name to be created by this Job
image: perl:5.34.0
env: //environment variables to set for the container.
- name: DATABASE_HOST //this env variable is set using a SecretKeyRef
valueFrom:
secretKeyRef:
name: {{ .Release.Name }}-test-db
key: host
restartPolicy: Never
backoffLimit: 4
5. RBAC (Role-based Access Control)
refers to the authorization mechanism that allows one Kubernetes service or workload to access another service or resource within a cluster based on predefined roles and permissions(eg: configmaps, secrets etc). The RBAC API declares 4 kinds of Kubernetes object
- a. Role & RoleBindings
- Defines who (subjects) can perform actions/verbs(create, get, update etc) on which resources(eg: pods, deployments, services). Roles specify the permissions, and RoleBindings associate these roles with service accounts, users, or groups
apiVersion: rbac.authorization.k8s.io/v1 //API version of RBAC being defined
kind: Role
rules:
- apiGroups: //Rule1: Grant Permission to create Tokenreviews is granted in group(authentication.k8s.io)
- authentication.k8s.io
verbs:
- create
resources:
- tokenreviews
- apiGroups: //Rule2: Grant Permission to get jobs in group(batch)
- batch
verbs:
- get
resources:
- jobs
- apiGroups: ["coordination.k8s.io"] //Rule3: Grant Permission to perform actions in group(coordination.k8s.io)
resources: ["leases"]
verbs: ["get", "watch", "list", "delete", "update", "create", "patch"]
- b. RoleBinding
- Grants the permissions defined in a role to Subjects. Subjects can be user or set of users. Example: user:jane can read pods in default namespace
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: read-pods
namespace: default
subjects:
- kind: User
name: jane #can read pods in default namespace
apiGroup: rbac.authorization.k8s.io
roleRef: # "roleRef" specifies the binding to a Role / ClusterRole
kind: Role # this must be Role or ClusterRole
name: pod-reader # You need to already have a Role named "pod-reader" in that namespace.
apiGroup: rbac.authorization.k8s.io
- c. CapabilityMapping
- Container will have Runtime(linux), CM can:
- 1. Give capabilities to a process running within linux container, Eg(process to modify n/w config, mouting file system, accessing h/w devices etc)
- 2. TAMS capability mapping When mapping-a is enabled, service can call method1,2. When mapping-b is enabled, service can call method3,4.
6. ServiceAccount
This object allows pod to authenticate and access other parts of cluster using RBAC.
7. Services
In Kubernetes, Service(or microservice) is logical set of Pods. Service exposes REST endpoints(eg: POST) & other services interact by calling these endpoints.
8. Secrets
Kubernets on AWS, Secrets is used to store sensitive information(Eg: passwords, API keys, and other credentials), that should not be exposed in plaintext within Kubernetes manifests or configuration files.
Why secrets object? Secrets can be created independently of the Pods that use them, now there is no risk of the Secret data being exposed during the creating, viewing, and editing Pods
// This yaml file stores sensitive data(eg: passwords or API keys), in an encrypted format within a Kubernetes cluster
kind: Secret
metaData:
name: {{ $name }} //will be replaced with a specific name at deployment time
annotations: //Annotations that indicate these secret should be created before the installation of helm chart, and deleted after chart is uninstalled.
"helm.sh/hook": pre-install
"helm.sh/hook-weight": "-2"
"helm.sh/hook-delete-policy": before-hook-creation
type: opaque //type of secret. Opaque means the data stored in the secret is an arbitrary byte array and the Secret does not have a predefined structure.
data: //key-value pairs of sensitive data that will be stored within the secret.
host: {{ .Values.test.host | b464enc }} //key=host, value=take from values.yaml and encoded in base64 format using the b64enc function
{{ - $previous := {lookup = "v1" "Secret" .Release.Namespace $name }} //key=password
{{ - if .Values.identityDB.password }}
password: {{ .Values.identityDB.password | b64enc }} //if values is in values.yaml file store after encoding in base64 format using the b64enc function
{{ - end - }}