Please enable JavaScript.

Coggle requires JavaScript to display documents.

KUBERNETES ARCHITECTURE, Gateway Proxy, Master and Worker Node Example…

- - - - Api
      - UI
      - kubectl
- - - - Integration Kit
        
        Build
      - KnativeService / Deployment
        
        pods
        
        System B
        
        System A
- - - - Pod Net Ns
        
        Veth
    - - Veth
      - Veth
    - - Pod Net Ns
        
        Veth
- - - - One way to create a Deployment using a .yaml file like the one above is to use the kubectl apply command in the kubectl command-line interface, passing the .yaml file as an argument.
      - kubectl apply -f dep-file.yaml
    - - Completed state
      - failed state
      - progressing state
- - - - node_exporter being a daemonset
        is component which runs on every worker node of kubernetes
- - - - application
    - - Virtual Service
- - - - Controller
        
        Non-terminating control loops that regulate the state of the Kubernetes cluster is managed by the Control Manager. Now, each one of these control loops knows about the desired state of the object it manages, and then they look at their current state through the API servers.
      - Scheduler
        
        schedules the work to different worker nodes. It has the resource usage information for each worker node. Then the scheduler schedules the work in terms of pods and services.
      - Worker 1
        
        Pod 1
        Containers
        
        The pods are scheduled on the worker nodes, which have the necessary tools to run and connect them
        By default, the Pod is only accessible by its internal IP address within the Kubernetes cluster
        
        Vulnerability in the configuration of a pod can let the attacker get into a container and probe for weaknesses in a network, process, controls or file system.
        
        conatainer 1
        :6666
        
        container inherits the IP given to the pod that belongs to
        
        container 2
        :7777 of the pod localhost
        
        localhost | pod IP 10.0.30.40
        
        containers within same pod communicate with each other through the localhost
        
        container accross diffrent pods communicate using the IP they inherited within through pod network
        
        Pod 2
        Containers
        
        container 1
        :5555
        
        localhost | pod IP 10.0.30.50
        
        Pod Network
        
        container 2
        :8888
        
        kube proxy
        
        It listens to the API server for each service point creation or deletion. For each service point, kube-proxy sets the routes so that it can reach to it.
        
        kubelet
        
        Kubelet is basically an agent that runs on each worker node and communicates with the master node making sure the containers are running in a pod
        
        Kubelets expose HTTPS endpoints which grant powerful control over the node and containers and by default Kubelets allow unauthenticated access to this API.
        
        A worker node is a virtual or physical server that runs the applications and is controlled by the master node.
      - API Server performs all the administrative tasks on the master node. A user sends the rest commands to the API server, which then validates the requests, then processes and executes them.
      - Worker 2
  - - - kubectl cluster-info
        create a deployment that manages a pod
        example >
        kubectl create deployment hello-node --image=k8s.gcr.io/echoserver:1.4
        kubectl get pods
        kubectl get events
        kubectl config view
      - retrieving yaml files from deployments/statefulets..
        example
        kubectl get statefulset
        kubectl describe statefulset deplymentName > file.yaml
        kubectl get configType configName -o yaml > file.yaml
  - - - running on the same address as the kubernetes master
        has a proxy namespace specifier (kube-dns)
        The domain name service (DNS) is typically used for scheduling purposes (e.g. at Pods or Service level) within the cluster.
    - - runs on the same address as the master but with a fully qualified namespace (kubernetes-dashboard) to uniquely distinguish it from the other services currently running.
    - - Create a service
        By default, the Pod is only accessible by its internal IP address within the Kubernetes cluster.
        to make the pod/container accessible from outside the kubernetes virtual net > we have to expose as kubernetes service
- - - - Controller
        
        Non-terminating control loops that regulate the state of the Kubernetes cluster is managed by the Control Manager. Now, each one of these control loops knows about the desired state of the object it manages, and then they look at their current state through the API servers.
      - Scheduler
        
        schedules the work to different worker nodes. It has the resource usage information for each worker node. Then the scheduler schedules the work in terms of pods and services.
      - Worker 1
        
        Pod 1
        Containers
        
        The pods are scheduled on the worker nodes, which have the necessary tools to run and connect them
        By default, the Pod is only accessible by its internal IP address within the Kubernetes cluster
        
        Pod 2
        Containers
        
        kube proxy
        
        It listens to the API server for each service point creation or deletion. For each service point, kube-proxy sets the routes so that it can reach to it.
        
        kubelet
        
        Kubelet is basically an agent that runs on each worker node and communicates with the master node making sure the containers are running in a pod
        
        Kubelets expose HTTPS endpoints which grant powerful control over the node and containers and by default Kubelets allow unauthenticated access to this API.
        
        A worker node is a virtual or physical server that runs the applications and is controlled by the master node.
        
        sidecar container
        
        are the containers that should run along with the main container in the pod. This sidecar pattern extends and enhances the functionality of current containers without changing them.
      - API Server performs all the administrative tasks on the master node. A user sends the rest commands to the API server, which then validates the requests, then processes and executes them.
      - Worker 2
- - - - Controller
        
        Non-terminating control loops that regulate the state of the Kubernetes cluster is managed by the Control Manager. Now, each one of these control loops knows about the desired state of the object it manages, and then they look at their current state through the API servers.
      - Scheduler
        
        schedules the work to different worker nodes. It has the resource usage information for each worker node. Then the scheduler schedules the work in terms of pods and services.
        
        scheduler cert.
      - Worker 1
        
        Pod 1
        Containers
        
        The pods are scheduled on the worker nodes, which have the necessary tools to run and connect them
        By default, the Pod is only accessible by its internal IP address within the Kubernetes cluster
        
        Pod 2
        Containers
        
        kube proxy
        
        It listens to the API server for each service point creation or deletion. For each service point, kube-proxy sets the routes so that it can reach to it.
        
        kubelet
        
        Kubelet is basically an agent that runs on each worker node and communicates with the master node making sure the containers are running in a pod
        
        Kubelets expose HTTPS endpoints which grant powerful control over the node and containers and by default Kubelets allow unauthenticated access to this API.
        
        kubelet cert.
        
        A worker node is a virtual or physical server that runs the applications and is controlled by the master node.
        
        sidecar container
        
        are the containers that should run along with the main container in the pod. This sidecar pattern extends and enhances the functionality of current containers without changing them.
      - API Server performs all the administrative tasks on the master node. A user sends the rest commands to the API server, which then validates the requests, then processes and executes them.
      - Worker 2
      - apiserver cert
- - - - clusterIP
        (iptables)
        
        pods
      - ClusterIP
        (iptables)
        
        pods
- - - - Sidecar
        proxy
        
        Mixer
        
        application
      - application
- - - - clusterIP
        (iptables)
        
        pods
        
        NodePort
      - ClusterIP
        (iptables)
        
        pods
- - - - clusterIP
        (iptables)
        
        pods
        
        LoadBalancer
      - ClusterIP
        (iptables)
        
        pods
- - - - clusterIP
        (iptables)
        
        pods
      - ClusterIP
        (iptables)
        
        pods
- - - - Mixer