Please enable JavaScript.

Coggle requires JavaScript to display documents.

Kubernetes (Object / Resources / Features List all: kubectl api…

- - - - Loadbalance
        Exposes the Service externally using a cloud provider’s load balancer. NodePort and ClusterIP Services, to which the external load balancer routes, are automatically created.
      - NodePort
        Exposes the Service on each Node’s IP at a static port (the NodePort). A ClusterIP Service, to which the NodePort Service routes, is automatically created. You’ll be able to contact the NodePort Service, from outside the cluster, by requesting <NodeIP>:<NodePort>.
      - ClusterIP
        Exposes the Service on a cluster-internal IP. Choosing this value makes the Service only reachable from within the cluster. This is the default ServiceType.
        Cluster IP is the default approach when creating a Kubernetes Service. The service is allocated an internal IP that other components can use to access the pods.
      - ExternalName
        Maps the Service to the contents of the externalName field (e.g. foo.bar.example.com), by returning a CNAME record
        with its value. No proxying of any kind is set up.
    - - Point to a Set of Pods labeled as MyApp using the selector app: MyApp
      - Without a selector
        
        You want to have an external database cluster in production, but in your test environment you use your own databases.
        
        You want to point your Service to a Service in a different Namespace or on another cluster.
        
        You are migrating a workload to Kubernetes. Whilst evaluating the approach, you run only a proportion of your backends in Kubernetes.
        
        to an IP
        
        to a DNS
  - - - Scaling
        
        Autoscalling (Horizontal Pod Autoscaler - HPA)
        
        Via manifest https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/controllers/hpa-rs.yaml
        or CLI
        kubectl autoscale rs frontend --max=10
        
        Via manifest
        https://kubernetes.io/examples/controllers/frontend.yaml
        or CLI
        kubectl scale --replicas=3 rs/frontend
      - When to use
        It's recommended using Deployments instead of directly using ReplicaSets, unless you require custom update orchestration or don’t require updates at all.
        This actually means that you may never need to manipulate ReplicaSet objects: use a Deployment instead, and define your application in the spec section.
    - - Strategies
        
        Reacreate
        It's the simpler strategy. It terminates all pods and recreates them using the new version. It has a drawback, and it's pontentially catastrophic. It results downtime and it should only be used for test deploys.
        
        Rolling Update
        This strategy permit roll-out new version little by little while keeps the old and the new versions at the same time.
        Keep in mind that it's a good idea having backward and forward compatibility.
        
        maxUnavailable
        This parameter determines how many pods can be unavailable during the roll-out. I can be an absolute number or a percentage (more common).
        Percentage ex.:
        100% -> it's the same to Recreate strategy.
        50% -> Replica Set will downsize half of the pods and recreate a half with the new version. Then it drops the rest half of the old version and then recreates the rest of the new version finishing the roll-out.
        0% -> It requires new resources to keep all desired pods. It uses the parameter maxSurge. If for instance, maxSurge is 20% it creates pods using the new version, then terminates the same 20% of old version and goes on.
        
        maxSurge
        Replicaset uses this parameter to create new pods without downsizing the desired state.
        Ex.: Suppose the following scenario, desired state is 10 pods, maxUnavaiable is 0% and maxSurge is 20%. It creates 2 new pods (12 pods). Then 2 pods from old version are terminated (10 pods) and 2 from new version are created (12), it repeats until all 10 pods have the new version.
        If maxSurge is 100% it's similar to blue/green deployment strategy.
- - - - https://forge.sh/
      - https://rancher.com/
    - - https://velero.io/
    - - https://helm.sh/
- - - - Readiness (app is starting up)
        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. When a Pod is not ready, it is removed from Service load balancers.
      - Liveness (app is running)
        The kubelet uses liveness probes to know when to restart a Container. For example, liveness probes could catch a deadlock, where an application is running, but unable to make progress.
        Liveness probes let Kubernetes know if your app is alive or dead.
    - - HTTP
        
        most common type of custom liveness probe
        
        even if your app isn’t an HTTP server, you can create a lightweight HTTP to respond to the liveness probe
        
        pings a path, and if it gets a response in the 200 or 300 range, it marks the app as healthy
      - Command
        
        command runs inside the container. I
        
        if the command returns an exit code 0, the container is marked as healthy. Otherwise, it is marked unhealthy. T
        
        this type of probe is useful when you can’t or don’t want to run an HTTP server
      - TCP
        
        tries to establish a TCP connection on the specified port, if it can establish a connection, the container is considered healthy
        
        come in handy where HTTP or command don’t work well. For example, a gRPC or FTP service is a prime candidate for this type of probe
- - - - Anti-pattern example
        Two containers for Wordpress and MySQL in same Pod
        Reasons
        
        They are not symbiotic. They can live in different machines and communicate over a network.
        
        The Wordpress and MySQL will not scale as a unit. Wordpress will problem scale with more Pods and MySQL is trickier and will require more resource. So, they scale differently.
      - Question: Will these containers work correctly if they land on different machines?
        If the answer is no, a Pod is the correct approach. If the answer is yes, multiple Pods is the solution.
      - Single x Multi Container
        
        Multi
        
        Scale as unit
        
        Communication as localhost
        
        Share mounted volumes
        
        Use Cases for Multi-Container Pods
        Sidecar containers “help” the main container. Some examples include log or data change watchers, monitoring adapters, and so on. A log watcher, for example, can be built once by a different team and reused across different applications. Another example of a sidecar container is a file or data loader that generates data for the main container.
        Proxies, bridges, and adapters connect the main container with the external world. For example, Apache HTTP server or nginx can serve static files. It can also act as a reverse proxy to a web application in the main container to log and limit HTTP requests. Another example is a helper container that re-routes requests from the main container to the external world. This makes it possible for the main container to connect to localhost to access, for example, an external database, but without any service discovery.
        
        Single
        
        Isolation
        
        Scale differently
        
        Restart independently
        
        It's necessary setup a service to communicate over network
      - “one process per container” principle
        This is important because With multiple processes in the same container, it is harder to troubleshoot the container because logs from different processes will be mixed together, and it is harder manage the processes lifecycle, for example to take care of “zombie” processes when their parent process dies. Second, using several containers for an application is simpler, more transparent, and enables decoupling software dependencies. Also, more granular containers can be reused between teams.