March 19, 2024
Kubernetes directory Structure - source
#
/etc/kubernetes/
: This folder contains the main configuration files for the Kubernetes control plane components.
/etc/kubernetes/manifests/
: This folder contains the YAML files for the Kubernetes system components that run as pods.
/etc/kubernetes/pki/
: This folder contains the public key infrastructure (PKI) files that are used for secure communication between the different components of the Kubernetes cluster.
/etc/cni/net.d/
: This folder contains the configuration files for Container Networking Interface (CNI) plugins used by Kubernetes to manage networking.
/var/lib/kubelet/
: This folder contains the actual data and volumes associated with each pod, as well as the config.yaml file for the kubelet.
/opt/cni/bin
: This folder contains the binary files for CNI plugins used by Kubernetes.
/etc/kubernetes/
├── manifests/ # YAML files defining Kubernetes resources
│ ├── etcd.yaml # etcd cluster manifest
│ ├── kube-apiserver.yaml # kube-apiserver manifest
│ ├── kube-controller-manager.yaml # kube-controller-manager manifest
│ ├── kube-scheduler.yaml # kube-scheduler manifest
│ ├── kube-proxy.yaml # kube-proxy manifest
│ └── ...
├── pki/ # Public Key Infrastructure for Kubernetes
│ ├── apiserver.crt # Kubernetes API Server certificate
│ ├── apiserver.key # Kubernetes API Server private key
│ ├── ca.crt # Cluster Certificate Authority certificate
│ ├── ca.key # Cluster Certificate Authority private key
│ └── ...
├── kubelet.conf # kubelet configuration file
├── controller-manager.conf # kube-controller-manager configuration file
├── scheduler.conf # kube-scheduler configuration file
└── admin.conf # kubeconfig file for cluster administrator
/etc/cni/net.d/ # Folder containing CNI configuration files
/var/lib/kubelet/
├── pods/ # Directory containing pod volumes and data
├── pki/ # Public Key Infrastructure for kubelet
├── config.yaml # kubelet manifest
└── ...
/opt/cni/bin/ # Container Networking Interface (CNI) binaries
- Codebase: Manage all code in version control systems (like Git or Mercurial). The codebase comprehensively dictates what is deployed.
- Dependencies: Dependencies should be managed entirely and explicitly by the codebase, either vendored (stored with the code) or version pinned in a format that a package manager can install from.
- Config: Separate configuration parameters from the application and define them in the deployment environment instead of baking them into the application itself.
- Backing services: Local and remote services are both abstracted as network-accessible resources with connection details set in configuration.
- Build, release, run: The build stage of your application should be completely separate from your application release and operations processes. The build stage creates a deployment artifact from source code, the release stage combines the artifact and configuration, and the run stage executes the release.
- Processes: Applications are implemented as processes that should not rely on storing state locally. State should be offloaded to a backing service as described in the fourth factor.
- Port binding: Applications should natively bind to a port and listen for connections. Routing and request forwarding should be handled externally.
- Concurrency: Applications should rely on scaling through the process model. Running multiple copies of an application concurrently, potentially across multiple servers, allows scaling without adjusting application code.
- Disposability: Processes should be able to start quickly and stop gracefully without serious side effects.
- Dev/prod parity: Your testing, staging, and production environments should match closely and be kept in sync. Differences between environments are opportunities for incompatibilities and untested configurations to appear.
- Logs: Applications should stream logs to standard output so external services can decide how to best handle them.
- Admin processes: One-off administration processes should be run against specific releases and shipped with the main process code.
Key Terminologies - source
#
- Image It is an immutable file that contains the source code, libraries, dependencies and tools to run an app.
- Container It is a running instance of an image.
- Cluster It is a collection of nodes that runs containerized apps.
- Node It is the smallest unit of computing hardware in Kubernetes.
- Pod They are the smallest deployable units in Kubernetes. Each pod can consist of one or more containers.
- Service It enables network access to a set of pods in Kubernetes.
- Deployment It is used to create or modify instances of pods and provides declarative updates to apps.
- Docker It is a set of tools for building ,sharing container images and running containers.