Please enable JavaScript.

Coggle requires JavaScript to display documents.

into GKE (GKE (Cluster types (Regional Clusters (Improves availability and…

- - - - MASTER (the brain):
        
        His components provide the cluster control panel.
        
        They make global decisions about the cluster.
        
        They detect and respond to cluster events.
        
        SCHEDULER
        
        watches for unscheduled pods and binds them to nodes via the /binding pod subresource API, according to the availability of the requested resources, quality of service requirements, affinity and anti-affinity specifications, and other constraints. Once the pod has a node assigned, the regular behavior of the Kubelet is triggered and the pod and its containers are created
        
        ETCD:
        
        As all cluster data is stored in etcd.
        
        Stores the configuration data of the Kubernetes cluster, representing the state of the cluster (what nodes exist in the cluster, what pods should be running, which nodes they are running on, and a whole lot more) at any given point of time.
        
        API SERVER
        
        When you interact with your Kubernetes cluster using the kubectl command-line interface, you are actually communicating with the master API Server
        
        the main management point of the entire cluster.
        
        The API Server is the only Kubernetes component that connects to ETCD; all the other components must go through the API Server to work with the cluster state.
        
        The API Server is also responsible for the authentication and authorization mechanism
        
        The API Server also implements a watch mechanism (similar to etcd) for clients to watch for changes.
        
        CONTROLLER MANAGER
        
        Watches the state of the cluster through the API Server watch feature and, when it gets notified, it makes the necessary changes attempting to move the current state towards the desired state.
        
        COMPONENTS
        
        Replication Controller:
        Responsible for maintaining the correct number of pods for every replication controller object in the system.
        
        Endpoints Controller:
        Populates the Endpoints object (that is, joins Services & Pods).
        
        Node Controller:
        Responsible for noticing and responding when nodes go down.
        
        Service Account & Token Controllers:
        Create default accounts and API access tokens for new namespaces.
      - Kubectl
        
        command line interface for running commands against Kubernetes clusters.
      - ---- Node----
        is a worker machine in Kubernetes, previously known as a minion. A node may be a VM or physical machine, depending on the cluster.
        Each node contains the services necessary to run pods and is managed by the master components.
        
        kube-system namespaces
        
        fluentd-gcp
        
        Logging Using Stackdriver
        
        heapster/metrics-server
        
        Tools for Monitoring Resources
        
        Customer namespaces
        
        ---- POD (have containers)
        
        Definition:
        A Pod is the smallest, most basic deployable object in Kubernetes. It represents a single instance of a running process in the cluster. When a Pod runs multiple containers, the containers are managed as a single entity and share the Pod's resources such as:
        
        Network: Pods are automatically assigned unique IP addresses. Pod containers share the same network namespace, including IP address and network ports. Containers in a Pod communicate with each other inside the Pod on localhost.
        
        Storage: Pods can specify a set of shared storage volumes that can be shared among the containers.
        
        Life of a Pod
        
        Liviness:
        Indicates whether the Container is running. If the liveness probe fails, the kubelet kills the Container, and the Container is subjected to its restart policy. If a Container does not provide a liveness probe, the default state is Success.
        readiness:
        Indicates whether the Container is ready to service requests. If the readiness probe fails, the endpoints controller removes the Pod’s IP address from the endpoints of all Services that match the Pod. The default state of readiness before the initial delay is Failure. If a Container does not provide a readiness probe, the default state is Success.
        
        main(post start hook-- post stop hook):
        Init Containers:
        specialized containers that run before app containers in a Pod . Init containers can contain utilities or setup scripts not present in an app image.
        infra:
        
        Stats:
        
        Running:
        Pod scheduled to a node and all containers have been created by the kubelet
        
        Succeeded:
        All containers in the pod have successfully terminated and will not be restarted
        
        Pending:
        API Server created a pod resource and stored it in etcd, but the pod has neither been scheduled yet nor have container images been pulled from the registry
        
        Failed:
        All containers in the pod have terminated
        At least one container has terminated in failure
        
        Unknown:
        API Server unable to query state of the pod due to error in communicating with the kubelet
        
        SERVICES
        
        act as the unified method of accessing replicated pods. There are 4 major Service Types:
        
        types
        
        ClusterIP (default) - exposes service on a strictly cluster-internal IP
        
        3 more items...
        
        NodePort - service is exposed on each node’s IP on a statically defined port
        
        3 more items...
        
        LoadBalancer - works in combination with a cloud provider to expose a service outside the cluster on a static external IP
        
        3 more items...
        
        ExternalName - used to references endpoints OUTSIDE the cluster by providing a static internally referenced DNS name
        
        INGRESS
        
        In Google Kubernetes Engine, Ingress resource defines L7 load balancer rules and configuration for routing external HTTP(S) traffic to Services. Ingress can be used to expose multiple services on a single IP using a single load balancer.
        When you create an Ingress in your cluster, GKE creates a Google Cloud Platform HTTP(S) load balancer and configures it to route traffic to your application.
        
        PODs Scenario
        
        1 The kubelet uses readiness probes to know when a Container is ready to start accepting traffic. A Pod is considered ready when all of its Containers are ready.
        
        2 One use of this signal is to control which Pods are used as backends for Services.
        
        3 When a Pod is not ready, it is removed from Service load balancers
        
        4 Kubelet runs periodic probe to check readiness of the pod which is defined based on the pod definition. In this case it identified readiness probe failed for pod 1.
        
        5 Based on the result of the probe, kubelet will report the pod status to API server which will then update the status of the pod in the status section of the object which is then stored in etcd.
        
        6 Endpoint controller will watch for any changes to the pod.
        
        7 Whenever endpoint controller identifies a change in the pod status, it will update the respective service.
        
        8 Endpoint controller will update the endpoints object with new pod ip.
        
        9 Kube proxies running in every node will get the change in the endpoint object.
        
        10 Kube-proxy will update the iptable rules in the nodes to point to the new pod ip.
        
        REPLICASETS:
        ensures that a specified number of pod replicas are running at any given time. Below is an example:
        
        Declaration of intent: run N copies of a pod
        
        Simple control loop
        
        One job: ensure N copies
        
        Too few? -> start some
        
        Too many? -> kill some
        
        Layered on top of Pods
        
        DEPLOYMENT
        provides declarative updates for Pods and ReplicaSets.
        You describe a desired state in a Deployment object, and the Deployment controller changes the actual state to the desired state at a controlled rate. You can define Deployments to create new ReplicaSets, or to remove existing Deployments and adopt all their resources with new Deployments.
        
        Manages replica changes
        
        Stable object name
        
        Simply edit the object
        
        Configurable server-side rolling-updates
        
        Can have multiple updates in flight
        
        Layered on top of ReplicaSets
        
        Rolling Update
        
        In order to support rolling update, we need to configure the update strategy first.
        So we add following part into spec:
        minReadySeconds: 5
        
        strategy:
        
        4 more items...
        
        common scenarios:
        
        multi-cloud deployments,
        
        continuous integration/continuous delivery (CI/CD) processes
        
        fronting on-premises data,
        
        JOB
        
        A Job creates one or more pods and ensures that a specified number of them successfully terminate. As pods successfully complete, the job tracks them. When a specified number of successful completions is reached, the job itself is completed. Deleting a Job cleans up the pods it created.
        
        DaemonSets
        
        A DaemonSet runs a Pod on every node or a selected subset of nodes. It is not a fixed number of replicas which are created and deleted as nodes come and go. A DaemonSet is useful for running cluster-wide services such as:
        
        Logging agents
        
        Storage systems
        
        Run a node monitoring daemon on every node, such as Prometheus node exporter
        
        StatefulSets
        
        A StatefulSet is a set of Pods with unique, persistent identities that have stable hostnames that Kubernetes Engine maintains regardless of where they are scheduled. State information and other resilient data is maintained in persistent disk storage. It is n ordinal index for the identity and ordering of their Pods. By default, StatefulSet Pods are deployed in sequential order and are terminated in reverse ordinal order.
        
        Secrets
        
        How to grant a Pod access to a secured something?
        
        Secrets: credentials, tokens, passwords, etc.
        Do not put them in the container image
        
        Inject them as virtual volumes into Pods
        
        Neither baked into images nor pod configs
        Kept in memory so it never touches the disk
        Not coupled to non-portable metadata API
        Manage secrets via the Kubernetes API
        
        ConfigMaps
        
        How to inject a configuration into a pod?
        
        ConfigMaps allow separating the configurations from the Pods and components, which:
        
        Keeps workloads portable
        
        Makes configurations easier to change and manage
        
        Prevents hardcoding configuration data to Pod specifications
        
        They are useful for storing and sharing non-sensitive, unencrypted configuration information.
        
        Horizontal Pod Autoscaler
        
        The Horizontal Pod Autoscaler automatically scales the number of pods as needed based on CPU utilization (at the moment) and will provide custom metrics (coming soon). It provides immediate efficiency and capacity when needed, operates within user-defined minimum/maximum bounds, and allows users to set it and forget it.
        
        POD
        Affinity & Anti-Affinity
        
        You can constrain a Pod to only be able to run on particular Node(s) , or to prefer to run on particular nodes.
        Pod affinity and pod anti-affinity allow the user to specify rules about how pods should be placed relative to other pods.
        
        The rules are defined using
        CUSTOM LABELs on NODEs
        and
        LABEL SELECTOR specified in PODs.
        
        Assign Pod to a Node
        
        Scheduler will automatically do a reasonable placement to:
        
        Spread pods across nodes
        
        Not place the pod on a node with insufficient free resources, etc.
        
        When the user wants more control on a node where a pod lands, so as to:
        
        Ensure a pod ends up on a machine with an SSD attached to it
        
        Co-locate pods from two different services that communicate a lot into the same availability zone
        
        Achieved using NodeSelector
        
        Taints & Tolerations
        
        Taints and tolerations work together to ensure that pods are not scheduled onto inappropriate nodes.
        
        Taints:
        are applied to a NODE, which marks the node should not accept any pods that do not tolerate the taints.
        
        Tolerations:
        are applied to PODs and allow (but do not require) the pods to schedule into nodes with matching taints, which specifies a toleration for a pod in the PodSpec.
        
        vertical pod autoscaling
        
        Vertical Pods Autoscaler (VPA) allocates more (or less) cpu or memory to existing pods. Think of it as giving pods some growth hormones :) It can work for both stateful and stateless pods but it is built mainly for stateful services. However, you can use it for stateless pods as well if you would like to implement an auto-correction of resources you initially allocated for your pods.
        
        Namespace
        
        helps different projects, teams, or customers to share a cluster.
        By default, cluster starts with the following three namespaces
        
        Default
        
        The default namespace for objects with no other namespace
        
        Kube-public
        
        This namespace is created automatically and is readable by all users (including those not authenticated). This namespace is mostly reserved for cluster usage, in case that some resources should be visible and readable publicly throughout the whole cluster. The public aspect of this namespace is only a convention, not a requirement.
        
        Kube-system
        
        The namespace for objects created by the Kubernetes system
        
        Node Draining
        -- kubectl drain <node name>
        
        You can use kubectl drain to safely evict all of your pods from a node before you perform maintenance on the node (e.g. kernel upgrade, hardware maintenance, etc.). Safe evictions allow the pod’s containers to gracefully terminate and will respect the PodDisruptionBudgets you have specified.
        
        When kubectl drain returns successfully, that indicates that all of the pods (except the ones excluded as described in the previous paragraph) have been safely evicted (respecting the desired graceful termination period, and without violating any application-level disruption SLOs).
        It is then safe to bring down the node by powering down its physical machine or, if running on a cloud platform, deleting its virtual machine.
        
        Process:
        
        A SIGTERM signal is sent to the main process (PID 1) in each container, and a “grace period” countdown starts (defaults to 30 seconds)
        
        Upon the receival of the SIGTERM, each container should start a graceful shutdown of the running application and exit
        
        If a container doesn’t terminate within the grace period, a SIGKILL signal will be sent and the container violently terminated
        
        Services
        
        kubelet (handles the Pods)
        
        Is the primary “node agent” that runs on each node. The kubelet works in terms of a PodSpec (( which is a YAML or JSON object that describes a pod.)) The kubelet takes a set of PodSpecs that are provided through various mechanisms (primarily through the apiserver) and ensures that the containers described in those PodSpecs are running and healthy.
        
        Kube-proxy
        
        Reflects services as defined in the Kubernetes API on each node and can do simple TCP, UDP, and SCTP stream forwarding or round robin TCP, UDP, and SCTP forwarding across a set of backends. Service cluster IPs and ports are currently found through Docker-links-compatible environment variables specifying ports opened by the service proxy.
        
        DOCKER
        
        DNS
        
        CoreDNS
        
        CoreDNS is a general-purpose authoritative DNS server that can serve as cluster DNS
        
        kube-DNS
        
        Kube-dns is now available as an optional DNS server since CoreDNS is now the default.
        The running DNS Pod holds 3 containers:
        
        Dnsmasq: Adds DNS caching to improve performance
        
        Sidecar: Perform health checks for dnsmasq and kube-dns
        
        Kube-dns: watches the Kubernetes master for changes in Services and Endpoints, and maintains in-memory lookup structures to serve DNS requests
        
        Conditions
        
        OutOfDisk True if there is insufficient free space on the node for adding new pods, otherwise False
        
        Ready True if the node is healthy and ready to accept pods, False if the node is not healthy and is not accepting pods, and Unknown if the node controller has not heard from the node in the last node-monitor-grace-period (default is 40 seconds)
        
        MemoryPressure True if pressure exists on the node memory – that is, if the node memory is low; otherwise False
        
        PIDPressure True if pressure exists on the processes – that is, if there are too many processes on the node; otherwise False
        
        DiskPressure True if pressure exists on the disk size – that is, if the disk capacity is low; otherwise False
        
        NetworkUnavailable True if the network for the node is not correctly configured, otherwise False
      - https://medium.com/jorgeacetozi/kubernetes-master-components-etcd-api-server-controller-manager-and-scheduler-3a0179fc8186
  - - - A zonal cluster create its cluster master and its nodes in a single compute a that you specify at the time of creation. This is the default type of cluster which gets created unless user indicate a specific type.
    - - Improves availability and resilience
      - Provides single static endpoint for the entire cluster and spreads the cluster's pods across multiple zones of a given region
      - Allows access to cluster's control plane even during an outage or downtime involving one or more (but not all) individual zones
      - The default number of masters, default number of nodes per zone, and default number of zones included are all three
    - - Alpha clusters are short-lived clusters that run stable Kubernetes releases with all Kubernetes APIs and features enabled
      - Limitations:
        
        Alpha clusters are not covered by the Kubernetes Engine SLA
        
        Alpha clusters cannot be upgraded
        
        Alpha clusters are automatically deleted after 30 days
    - - In Kubernetes Engine, a private cluster is a cluster that makes your master inaccessible from the public internet.
      - In a private cluster, nodes do not have public IP addresses, so your workloads run in an environment that is isolated from the internet.
- - - - Node auto upgrades help keep the nodes in the cluster up to date with the latest stable version of Kubernetes. The upgrades use the same update mechanism as manual node upgrades. Some benefits of using auto upgrades are:
        Lower management overhead
        Better security
        Ease of use
        node auto upgrades are not available for Alpha Clusters or clusters running the Ubuntu node image.
    - - Cluster Autoscaler automatically scales the number of nodes as needed based on the scheduler backlog and idleness. It manages current efficiency, adds capacity as needed, operates within user-defined minimum/ maximum bounds, and allows users to set it and forget it.
    - - A node pool is a subset of node instances within a cluster that all have the same configuration and uses a NodeConfig specification. Each node in the pool has a Kubernetes node label, cloud.google.com/gke-nodepool, which has the node pool's name as its value. The user can create, upgrade, and delete node pools individually without affecting the whole cluster using the gcloud container node-pools command.
    - - The user can enable node auto repairing on a per-node pool basis. GKE uses the node's health status to determine if a node needs to be repaired. A node reporting a Ready status is considered healthy. GKE triggers a repair action if a node reports consecutive unhealthy status reports for a given time threshold, such as:
        
        NotReady status on consecutive checks over the given time threshold (approximately 10 minutes)
        
        Not reporting any status at all over the given time threshold (approximately 10 minutes)
        
        Node's boot disk is out of disk space for an extended time period (approximately 30 minutes)
    - - endpoint. The endpoint is the IP address of the Kubernetes API server that kubectl and other services use to communicate with your cluster master.