Delegate-Driven Chaos Infrastructure
This topic describes Delegate-Driven Chaos Infrastructure, its characteristics, and installation.
What is DDCR?
DDCR, aka Harness Delegate or DDCI (Delegate-Driven Chaos Infrastructure) or DDCR (Delegate-Driven Chaos Runners) is a service that runs in your local network that helps connect your infrastructure, artifacts with Harness Manager. It allows for quick onboarding and optimized chaos execution for microservices-based targets on Kubernetes.
To install a new Delegate, go to enable chaos
The diagram below describes the high-level flow of how you can discover services and create application maps.
- To execute chaos experiments, HCE supports Delegate version
24.09.83900and above.
Experiment execution using DDCR
The schematic diagram below describes how chaos experiments are executed in using Harness Delegate. It highlights the use of Harness Delegate which eliminates the need for a separate chaos agent, which simplifies the experiment orchestration mechanism.
Go to permissions required to know the detailed list of permissions to execute Kubernetes faults with a Delegate.
The diagram below describes the detailed flow of control (step 5 of the earlier diagram), for an example chaos experiment- pod DNS chaos.
Characteristics of DDCR
- Automated Kubernetes service discovery and workloads with network traffic patterns between them through a transient discovery agent.
- Automated and guided application map creation that represent a fully functional application within the cluster (which comprises of several constituent microservices).
- Chaos experiment auto-creation for a given application map based on the workload specification and its lineage in terms of network traffic.
- Reuse the Harness Delegate for chaos experiment execution on the user cluster without a dedicated (or separate) chaos agent.
- Application-level and application map level resilience scores.
Auto-create experiments
Experiments are auto-created based on levels (or categories) you select during automated or guided onboarding. The default setting is that HCE creates all the recommended experiments for the selected application map.
Speed of execution
Earlier, chaos experiments that executed on dedicated chaos infrastructure would typically take more time (in the order of 4 minutes) whereas with Harness Delegate, you can complete experiment execution in less than half the time (in the order of 1.5 minutes).
The diagram below shows the execution time for experiments that use legacy Kubernetes infrastructure.
The diagram below shows the execution time for experiments that use Harness Delegate.
Fault tunables
The number of tunables configured in an experiment that uses Harness Delegate is different. Harness Delegate provides better control over the experiments because of the presence of advanced tunables.
Resilience score
Earlier, resilience score was measured at the experiment level. With Harness Delegate, you can gain insights into an application along with its associated application map. This way, you can view the application-level resilience score and application-map-level resilience score.
Secret decryption with external secret managers
Chaos experiments that run through Harness Delegate use a dedicated chaos delegate task to decrypt the secrets they consume at runtime, such as connector credentials and APM or cloud probe authentication keys.
Because the delegate performs the decryption, you can store these secrets in the Harness Secret Manager or in an external secret manager such as HashiCorp Vault, Google Cloud KMS, or Azure Key Vault. Secrets are referenced the same way regardless of where they are stored, so your existing experiments and probes do not change.
This behavior is behind the feature flag CHAOS_DEDICATED_DELEGATE_TASK. Contact Harness Support to enable it for your account. When the flag is enabled, chaos workflows that use the Harness NG Manager /chaos/... endpoints start using the dedicated chaos delegate task.
Go to Use an external secret manager to review the supported secret managers and setup steps.