DOCSEARCHbyAlgolia
Submit Docs

Elastic Cloud on Kubernetes (ECK)

repository·main·Indexed 25 days ago

https://github.com/elastic/cloud-on-k8s

Elastic Cloud on Kubernetes (ECK) uses the Kubernetes operator pattern to automate the lifecycle management of Elastic Stack components, including Elasticsearch, Kibana, Logstash, APM Server, Enterprise Search, and Beats. The project provides Helm charts for the ECK Operator and ECK-Stack, tools for managing resource annotations via annotator.sh, and a Deployer utility for provisioning Kubernetes clusters across GKE, AKS, EKS, Kind, and K3d.

Tokens
89.3K
Snippets
92
Records
427
Agent score
82%

What's inside ECK

  1. Overview of ECK Recipes

    main

    ECK Recipes provide examples of how to utilize Elastic Cloud on Kubernetes (ECK) for common use cases.

    Warning: These recipes are intended for illustration purposes only and are not considered production-ready. Use them to understand patterns rather than deploying them directly to production environments.

  2. Overview of Elastic Cloud on Kubernetes (ECK)

    main
    Elastic Cloud on Kubernetes (ECK) is an operator-based solution that automates the deployment, provisioning, management, and orchestration of Elastic Stack components on Kubernetes. It handles complex tasks such as TLS certificate management, safe cluster configuration and topology changes, persistent volume usage, and secure settings keystore updates.

  3. Understand Elasticsearch node certificate management

    main

    Elastic Cloud on Kubernetes (ECK) manages Mutual TLS (mTLS) for Elasticsearch nodes using an operator-driven approach. The operator acts as the Certificate Authority (CA) for the clusters it manages, issuing certificates based on Certificate Signing Requests (CSRs) provided by pods.

    Key Workflow:

    1. CSR Generation: An init container within the Elasticsearch pod generates a private key and a CSR on startup.
    2. CSR Retrieval: The init container runs an HTTP server to serve the CSR. The operator requests the CSR via this API (using a cert-initializer component).
    3. Issuance: The operator signs the CSR and creates a Kubernetes Secret containing the certificate.
    4. Mounting: The certificate is mounted to the pod via a secret volume mount. Elasticsearch can automatically use updated certificate files on disk without a restart, though some components like Kibana require a restart to pick up new certificates.

    Security Model:

    • Pod Private Keys: Private keys are generated inside the pod and never leave it (shared only between the init container and the Elasticsearch process).
    • CA Private Key: The operator manages one CA per cluster. The CA private key is stored as a Kubernetes Secret in the apiserver.

  4. Certificate management overview for Elasticsearch nodes

    main

    Elastic Cloud on Kubernetes (ECK) manages TLS certificates for Elasticsearch nodes to ensure production-grade security. The operator handles the generation and signing of self-signed TLS certificates and node private keys.

    Key features include:

    • Automated Management: The operator signs certificates and passes them to Elasticsearch pods via Kubernetes Secrets.
    • Protocol Separation: The operator manages distinct sets of certificates for the Transport protocol and the HTTP protocol.
    • User-Provided Certificates: Users can provide their own private keys and certificates if they prefer not to use the operator-managed ones.
    • Security Design: Each node receives its own private key signed by a CA, and the design aims to prevent Elasticsearch pods from needing direct access to the Kubernetes API.

  5. Understand the Global and Namespaced Operator architecture

    main

    The Elastic Cloud on Kubernetes (ECK) architecture utilizes a split between a Global Operator and Namespaced Operators to improve security, scalability, and reliability.

    • Global Operator: Contains controllers for resources that span multiple deployments or namespaces. These controllers manage installation-wide concerns.
    • Namespaced Operators: Responsible for managing namespace-local resources, such as individual Elasticsearch clusters and Kibana nodes.

    This split allows for granular RBAC (limiting permissions to specific namespaces), reduced load on the Kubernetes API server, and prevents a single point of failure from affecting an entire region.

  7. Understand Elasticsearch sidecar health monitoring status

    main
    As of the July 2019 update, the Elasticsearch sidecar (specifically the keystore-updater process-manager) has been removed to simplify the architecture. The keystore-updater now runs as an init-container instead of a sidecar. Consequently, there is no longer a need to monitor sidecar health via the previous sidecar-based mechanisms.

  8. Understand Pod Reuse and ES Process Restarts

    main

    The ECK operator can reuse existing Elasticsearch (ES) pods to apply configuration changes (like license updates or plugin changes) without deleting the pod itself. Instead of a full pod replacement, the operator restarts the ES process running inside the pod. This is achieved by mounting elasticsearch.yml via a secret volume and using a process manager within the pod that responds to HTTP API calls from the operator.

    Key Concepts:

    • Pod Reuse: Changing the mounted configuration and restarting the ES process instead of recreating the pod.
    • Configuration Delivery: Settings are stored in a secret volume (not environment variables) to allow for secrets like Slack or email credentials.
    • Restart Orchestration: Restarts can be performed in a rolling fashion (one by one) or as a coordinated full cluster restart (e.g., when switching TLS settings during a license change).

  9. Understand the ControllerLicense mechanism for commercial features

    main

    Elastic Cloud on Kubernetes (ECK) uses a specific mechanism to enable commercial features based on the presence of an Enterprise license. Instead of sharing the full Enterprise license across all namespaces, the system uses a dedicated Custom Resource Definition (CRD) called ControllerLicense.

    How it works:

    1. License Controller: A global license controller detects a valid Enterprise or Enterprise trial license in the system.
    2. CRD Creation: The license controller creates a ControllerLicense resource in each relevant namespace.
    3. Verification: Individual controllers in those namespaces verify the ControllerLicense using a public key provided at installation time.
    4. Feature Activation: Commercial features are toggled ON only if a valid, verified ControllerLicense is present in the local namespace.

    This approach limits the impact of accidental license leaks because ControllerLicense resources have no validity outside the specific operator installation that created them and can be issued with shorter lifetimes than the primary Enterprise license.

  10. Understand ECK's architectural decision to use a custom controller instead of StatefulSets

    main

    Elastic Cloud on Kubernetes (ECK) does not use Kubernetes StatefulSets to manage Elasticsearch pods. Instead, it uses a custom controller that manages Pods directly. This design choice provides greater flexibility for complex Elasticsearch topologies and advanced lifecycle operations that standard StatefulSets cannot easily handle.

    Why a custom controller is used:

    • Complex Topologies: Elasticsearch clusters often require diverse node types (master-only, data-only, ML, APM, etc.) and multi-AZ configurations. Using StatefulSets would require managing multiple distinct StatefulSet resources for a single cluster, which increases complexity.
    • Advanced Rolling Upgrades: ECK performs sophisticated rolling upgrades that involve calling the Elasticsearch API to exclude allocations, waiting for shard migration, and managing node replacement. Standard StatefulSet update strategies (like RollingUpdate or RollingUpdate.Partition) are too rigid to orchestrate these application-specific steps.
    • Lifecycle Flexibility: Direct Pod management allows ECK to better handle cluster growth, version migrations, volume reuse, and multi-AZ orchestration.
    • Avoidance of Controller Dependencies: By managing Pods directly, ECK avoids being strictly bound to the release cycles and specific behaviors of the Kubernetes StatefulSet controller.

  12. Prerequisites for exposing Elasticsearch and Kibana via Istio

    main

    Before following this recipe, ensure the following environment is prepared:

    1. Install Istio: Use the default profile with the ingress gateway enabled. For debugging, enable proxy logging via meshConfig.accessLogFile.
    2. Install ECK: Deploy Elastic Cloud on Kubernetes with the Istio sidecar enabled.
    3. Enforce mTLS: Configure Mutual TLS for the cluster.
    4. Namespace Setup: Create an istio-apps namespace with Istio sidecar injection enabled.
    5. Cert-Manager: Install cert-manager and create a ClusterIssuer named selfsigning-issuer.