Core Concepts

1. Authenticate user

2. Validate request

3. Retrieve data

4. Update ETCD

5. Scheduler

6. Kubelet

• Note Controller:
  • Responsible for monitoring the status of the nodes.
  • Tests the status of the nodes every 5 seconds through the kube-api server.
  • The node is marked unreachable after 40 seconds, giving it 5 minutes to return.
  • If it doesn’t, then it will remove all the pods assigned to that node and provision them on the healthy node.

• Replication Controller:
  • Responsible for monitoring the status of the replica sets, ensuring that the desired number of pods are available.
  • If a pod dies, it creates another one.

• Other Controllers:
  • Deployment Controller
  • NameSpace Controller
  • EndPoint Controller
  • Job Controller
  • Service Account Controller
  • PV-Protection Controller
  • CronJob Controller
  • Stateful Controller
  • PV-Binder Controller

• a process that runs on each node in the k8s cluster to ensure the communication between pods.

• The kube-proxy job is to look for new services and create the appropriate rules on each node to forward traffic to those services to the backend pods.

• Using iptable rules.

• Pods are the smallest deployable units of computing that you can create and manage within your Kubernetes cluster. However, A pod consists of a group of one or more tightly related containers that share the same node underlying and the same Linux namespace. and

• Imperative way:

  kubectl run nginx --image=nginx:1.14.2
  kubectl get pods

• Declarative way:

  apiVersion: v1
  kind: Pod
  metadata:
    name: nginx
  spec:
    containers:
    - name: nginx
      image: nginx:1.14.2
      ports:
      - containerPort: 80

  kubectl create -f nginx_pod.yml
  kubectl get pods

• ReplicaSets are used to maintain a stable set of pods running at any given time. As such, is used to guarantee the availability of a specified number of identical pods.

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend
  labels:
    app: guestbook
    tier: frontend
spec:
  # modify replicas according to your case
  replicas: 3
  selector:
    matchLabels:
      tier: frontend
  template: #Pod template
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
      - name: php-redis
        image: gcr.io/google_samples/gb-frontend:v3

$ kubectl create -f front-replicas.yml
$ kubectl get rs
$ kubectl describe rs/frontend

• So basically, Deployments ensure the desired number of pods are running and always available. The update process is also wholly recorded, and versioned with options to pause, continue, and roll back to previous versions.

• Deploy a replica set or pod.

• Update pods and replica sets.

• Rollback to the previous version.

• Scale a deployment.

• Pause or continue a deployement.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx 
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

• A service is a method for exposing a network application that is running as one or more Pods in your cluster.

• To understand the need for a service let’s assume that you are using a Deployment to run your app. that Deploymenet can create and destroy Pods dynamically. Each Pod gets its own IP address, the set of Pods running in one moment in time could be different from the set of Pods running that application a moment later. This leads to a problem; if some set of Pods Backends provides functionality to other pods Frontends inside your cluster, how do the frontends find out and keep track of which IP address to connect to, so that the frontend can use the backend part of the workload? ENTER SERVICES.

• ClusterIP:
  • Exposes the Service on the cluster-internal IP → This will make the Service only reachable from within the cluster.

• NodePort:
  • Exposes the Service on each Node’s IP at a static port.

    piVersion: v1
    kind: Service
    metadata:
     name: myapp-service
    spec:
     types: NodePort
     ports:
     - targetPort: 80
       port: 80
       nodePort: 30008

• LoadBalancer:
  • Exposes the service externally using an external load balancer. Note that you should provide one as Kubernetes doesn’t directly offer a load-balancing component.

• ExternalName:
  • Maps the service to the contents of the externalNamefield (e.g. api.foo.bar.example). The mapping configures your cluster’s DNS server to return a CNAME record with that external hostname value.

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app.kubernetes.io/name: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376
#Default Service type is ClusterIP

• Namespaces is a mechanism for isolating groups of resources within a single cluster.

• default

• kube-node-lease: holds Lease objects associated with each node. Node leases allow the Kubelet to send heartbeats so that the control plane can detect node failure.

• kube-public: This namespace is readable by all clients, and is mostly reserved for cluster usage in case some resources should be visible and readable publicly throughout the whole cluster.

• kube-system: used for objects created by the Kubernetes system.

apiVersion: v1
kind: Namespace
metadata:
	name: mynamespace

$ kubectl create ns <namespace>
$ kubectl get ns