Skip to content

Latest commit

 

History

History
132 lines (103 loc) · 5.62 KB

Kubernetes Advanced Topics.md

File metadata and controls

132 lines (103 loc) · 5.62 KB

Kubernetes Advanced Topics

Custom Resource Definitions (CRDs)

Custom Resource Definitions (CRDs) allow you to extend the Kubernetes API by defining new resource types. CRDs can be used to represent custom application configurations, manage third-party tools, or create domain-specific abstractions.

Here's an example of a simple CRD:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: myresources.example.com
spec:
  group: example.com
  versions:
    - name: v1
      served: true
      storage: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                field1:
                  type: string
                field2:
                  type: integer
  scope: Namespaced
  names:
    plural: myresources
    singular: myresource
    kind: MyResource
    shortNames:
      - mr

In this example, a new CRD named MyResource is created with the spec containing two fields, field1 and field2.

Operators

Operators are a pattern for managing the lifecycle of Kubernetes applications, extending the Kubernetes API and automating common tasks like deployments, upgrades, and backups. They are typically built using the Operator SDK and rely on Custom Resource Definitions (CRDs) to define custom resources and Controllers to manage those resources.

Operators are useful for managing stateful applications and complex software stacks, as they can encapsulate domain-specific knowledge and provide a higher level of abstraction for managing resources.

Service Mesh (e.g., Istio, Linkerd)

A service mesh is a dedicated infrastructure layer for managing service-to-service communication in a microservices architecture. It provides features like load balancing, traffic routing, observability, and security for service interactions.

Istio and Linkerd are two popular service mesh solutions for Kubernetes:

  • Istio: An open-source service mesh that provides traffic management, security, and observability features. Istio uses Envoy as its sidecar proxy and supports a variety of traffic management patterns like canary deployments and circuit breaking.

  • Linkerd: Another open-source service mesh focused on simplicity and performance. Linkerd provides features like load balancing, traffic routing, and observability, and uses its own lightweight proxy for sidecar injection.

Helm, the package manager for Kubernetes

Helm is a package manager for Kubernetes that simplifies the deployment, management, and versioning of applications. Helm uses "charts" to define, install, and upgrade Kubernetes applications. A chart is a collection of YAML files that describe the Kubernetes resources required to run an application, including Deployments, Services, ConfigMaps, and other dependencies.

Helm consists of two main components:

  • Helm CLI: A command-line tool used to interact with the Helm charts and manage releases.
  • Tiller (Helm 2 only): A server-side component that manages the release lifecycle (deprecated in Helm 3).

Example of using Helm:

  1. Add a chart repository: 
    helm repo add myrepo https://example.com/charts
  2. Install a chart: 
    helm install myapp myrepo/mychart

Kubernetes Federation

Kubernetes Federation is a way to manage multiple Kubernetes clusters from a single control plane, providing a unified interface for managing resources across different clusters and regions. This enables features like cross-cluster load balancing, high availability, and disaster recovery for multi-cluster deployments.

Kubernetes Federation v2 is built on top of CRDs and custom controllers, providing a more flexible and extensible model for managing federated resources. It allows you to define custom resource types and use them across multiple clusters, as well as propagate and synchronize resources across clusters.

Key components of Kubernetes Federation include:

  1. Federation API: The API that provides a unified interface for managing resources across multiple clusters.
  2. Federation Controller Manager: The component responsible for managing the lifecycle of federated resources, including propagation and synchronization.
  3. Cluster Registry: A centralized registry of all the clusters participating in the federation.

To set up Kubernetes Federation, you need to:

  1. Deploy the federation control plane in one of the participating clusters or a dedicated cluster.
  2. Register all the participating clusters with the federation control plane using the Cluster Registry.
  3. Create Federated resources (e.g., FederatedDeployments, FederatedServices) that define how resources should be propagated and synchronized across the clusters.

Example of a FederatedDeployment:

apiVersion: types.federation.k8s.io/v1beta1
kind: FederatedDeployment
metadata:
  name: my-federated-deployment
spec:
  template:
    metadata:
      labels:
        app: myapp
    spec:
      replicas: 3
      selector:
        matchLabels:
          app: myapp
      template:
        metadata:
          labels:
            app: myapp
        spec:
          containers:
            - name: myapp
              image: myapp:latest
  placement:
    clusterNames:
      - cluster1
      - cluster2
  overrides:
    - clusterName: cluster2
      clusterOverrides:
        - path: "/spec/replicas"
          value: 5

In this example, a FederatedDeployment is created with a base Deployment template, specifying that it should be propagated to two clusters, cluster1 and cluster2. The overrides section allows you to customize the Deployment for specific clusters, such as setting a different replica count for cluster2.