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

Type Description
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 

//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 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 This object allows pod to authenticate and access other parts of cluster using RBAC.
In Kubernetes, Service(or microservice) is logical set of Pods. Service exposes REST endpoints(eg: POST) & other services interact by calling these endpoints.
7. 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.
In Kubernetes, Service(or microservice) is logical set of Pods. Service exposes REST endpoints(eg: POST) & other services interact by calling these endpoints.
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 - }}
9. POD A basic unit of deployment in Kubernetes that runs one or more containers.