I read Kubernetes Complete Guide and will leave some notes here. I’m summarizing commands and mechanisms that I wasn’t usually conscious of.

  • If you want to create small images, base them on scratch or alpine
  • When both ENTRYPOINT and CMD are set, $ENTRYPOINT $CMD is executed
  • Multi-stage build: You can process only in a build-specific container and copy the artifacts to an execution-specific container
  • CNCF sets project maturity in three stages: “Graduated”, “Incubating”, and “Sandbox”
  • When building on-premises, instance sizes on AWS or GCP can be used as a guide
  • Flannel: Configures an overlay network between nodes
  • There is a kubernetes playground provided by Docker, Inc.
  • kubernetes resources are broadly divided into 5 types
    • Workloads, Discovery &LB, Config & Storage, Cluster, Metadata
    • Metadata in particular is a resource for manipulating other resources in the cluster (such as HorizontalPodAutoscaler)
    • There is a hierarchical structure: Deployment/CronJob > ReplicationController/ReplicaSet/DaemonSet/StatefulSet/Job > Pod
    • kubectl get all: Get a list of almost all resources
    • Stateful Set: The 0th Pod is created first and deleted last
  • kubeconfig
    • Set three types: clusters, users, contexts (multiple registrations are possible for all)
    • If switching context or namespace is redundant, it might be good to use kubectx or kubens
    • You can output cluster and namespace to prompt using kube-ps1
    • You can use zsh/bash completion with source <(kubectl completion bash) etc.
  • Conway’s Law: The organization chart is similar to manifest management methods and microservice architectures
  • kubectl scale: Scaling with ReplicaSet, ReplicationController, Deployment, StatefulSet, Job, CronJob
  • kubectl apply --prune: Detects resources deleted from the manifest at runtime and automatically deletes them
    • In CI/CD, you just need to keep throwing this command
    • kubectl apply --prune --all: It’s dangerous because if you don’t load all manifests that exist in the cluster, missing resources will disappear
    • kubectl apply --prune -l system=a: Basically specify labels
  • Debugging
    • kubectl cp: File transfer between container and local machine
    • kubectl port-forward: Port forwarding between container and local machine
    • kubectl -v: Debug output
  • Service Discovery
    • spec.hostAliases: Rewrites /etc/hosts for all containers in the Pod
    • From within a Pod, services in the same namespace can be checked from environment variables
    • Service A records are registered with {service name}.{namespace}.svc.cluster.local
    • Setting spec.externalTrafficPolicy=Local does not perform load balancing across Nodes
    • Using Headless Service performs load distribution by DNS round robin instead of load balancing of traffic via VIP
    • ExternalIP Service can be used to forward traffic received at a specific Node’s IP address:port number to the outside
    • ExternalName Service: Returns a pre-configured CNAME
  • Ingress
    • Ingress: Provides L7 load balancer. It’s positioned differently from Service, so it’s an independent resource
    • When deploying Ingress Pods: Create a Loadbalancer Service for Ingress Pods and perform L7 load balancing from there
    • Nginx Ingress: The Ingress Controller itself is also a Pod that performs L7-equivalent processing (even though it’s called a controller)
  • Manifests with defined Secrets can be encrypted using kubesec when uploading to a Git repository
  • Using Dynamic Provisioning, when a PersistentVolumeClaim is issued, a PersistentVolume is dynamically created and assigned
  • Scheduling
    • Requests are the lower limit of resources, Limit is the upper limit of resources
    • Keep the difference between these two small
    • Basically schedule based on Requests
    • You can check with kubectl describe resourcequota
    • Beyond CPU: horizontal pod autoscaling with custom metrics in Google Kubernetes Engine is a good reference
    • postStart/preStop: Can execute arbitrary commands after container startup and just before stopping
    • However, if you want to perform charitable processing reliably, it’s better to use initContainers
    • Scheduling where Taints (dirt) are attached to Nodes, and Pods Tolerate them
  • To store logs stably in the medium to long term, it’s good to configure a system that uses Fluentd to forward to external systems
  • You can do CI/CD with Spinnaker (Netflix), skaffold (Google), etc.
  • There are manifest file Linter kubeval and unit testing tool kubetest
  • Service Mesh
    • The concept of controlling communication and routing between microservices
    • Istio/Conduit (Linkerd v2)/Linkerd, etc.
  • etcd
    • Stores all information of the cluster
    • Must not become a single point of failure (SPoF)
    • Due to Raft properties, it’s good to set up an odd number of servers such as 3/5/7
    • You can take backups with etcd snapshot
  • You can create custom resources using Operator Framework
  • X as a Service: Vitess (Mysql), NATS (Queue), Rook (Ceph), Kubeflow (ML)