zhongwei/gh-jeremylongshore-claude-code-plugins-plus-plugins-devops-service-mesh-configurator
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit

Browse Source
This commit is contained in:
Zhongwei Li
2025-11-30 08:20:01 +08:00
commit fcbbbd1725
12 changed files with 748 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

15
.claude-plugin/plugin.json Normal file
View File

@@ -0,0 +1,15 @@
{
"name": "service-mesh-configurator",
"description": "Configure service mesh (Istio, Linkerd) for microservices",
"version": "1.0.0",
"author": {
"name": "Claude Code Plugins",
"email": "[email protected]"
},
"skills": [
"./skills"
],
"commands": [
"./commands"
]
}

3
README.md Normal file
View File

@@ -0,0 +1,3 @@
# service-mesh-configurator
Configure service mesh (Istio, Linkerd) for microservices

25
commands/service-mesh.md Normal file
View File

@@ -0,0 +1,25 @@
---
description: $(echo "$description" | cut -d' ' -f1-5)
---
# $(echo "$name" | sed 's/-/ /g' | sed 's/\b\(.\)/\u\1/g')
$(echo "$description")
## Key Features
- Production-ready configurations
- Best practices implementation
- Security-first approach
- Scalable architecture
- Comprehensive documentation
- Multi-platform support
## Example Usage
This plugin generates complete configurations for your DevOps needs.
Specify your requirements and get production-ready code instantly.
## When Invoked
Generate configurations and setup code based on your specific requirements and infrastructure needs.

77
plugin.lock.json Normal file
View File

@@ -0,0 +1,77 @@
{
"$schema": "internal://schemas/plugin.lock.v1.json",
"pluginId": "gh:jeremylongshore/claude-code-plugins-plus:plugins/devops/service-mesh-configurator",
"normalized": {
"repo": null,
"ref": "refs/tags/v20251128.0",
"commit": "b98d3478817a2b92b6b0e2fa18e2b55a43fc296c",
"treeHash": "c534cf6cdcca4ce9bc59a8e3e31db23aa1e2df60e445ca8b7e2df3e659d8dc14",
"generatedAt": "2025-11-28T10:18:45.199409Z",
"toolVersion": "publish_plugins.py@0.2.0"
},
"origin": {
"remote": "git@github.com:zhongweili/42plugin-data.git",
"branch": "master",
"commit": "aa1497ed0949fd50e99e70d6324a29c5b34f9390",
"repoRoot": "/Users/zhongweili/projects/openmind/42plugin-data"
},
"manifest": {
"name": "service-mesh-configurator",
"description": "Configure service mesh (Istio, Linkerd) for microservices",
"version": "1.0.0"
},
"content": {
"files": [
{
"path": "README.md",
"sha256": "924cd8918cd8d153cb34972678af0ac8e7986b4ced52c60a2f1bb16d56aa1e71"
},
{
"path": ".claude-plugin/plugin.json",
"sha256": "5f11c4a06e171b73ab73732496fd9c17f9ed3d7eef020a9f98251c777634bea8"
},
{
"path": "commands/service-mesh.md",
"sha256": "353f80054a90cda1e6716da3628115ce829307fbbb83a15b64f1d37c96224a99"
},
{
"path": "skills/service-mesh-configurator/SKILL.md",
"sha256": "22ede674edd3cbc0f1fcbce2421593b07b6a7f33d256fbea62463b7b5da5c877"
},
{
"path": "skills/service-mesh-configurator/references/README.md",
"sha256": "4a592214eccd289d95067724f02e21882729db0b6ae3c2f76e7ce4b23e73c376"
},
{
"path": "skills/service-mesh-configurator/scripts/README.md",
"sha256": "0789cd42e15230fa1f9cdec3213c57dda3bbb63caae8a8756b50c4f5fc0b1a35"
},
{
"path": "skills/service-mesh-configurator/assets/README.md",
"sha256": "2d8053bfa00fec99cf91a61b7e120e9196bf52dd4e573ffdc7e7c77583058dbb"
},
{
"path": "skills/service-mesh-configurator/assets/istio_config_template.yaml",
"sha256": "b9e02481fcf2814b0cd75d53ae0952650e5cc678c9e9f21c46073ab70e9a4e87"
},
{
"path": "skills/service-mesh-configurator/assets/linkerd_config_template.yaml",
"sha256": "4c1b037dd5c0ac5b1506b249adb594fcab2acb0de70ffbde8c2bce7ae256c9f9"
},
{
"path": "skills/service-mesh-configurator/assets/error_handling_strategies.md",
"sha256": "9e4678417d2fc1db25bcc4dc4ad15e9942dc7d40e9f249aee263d6ed3c0570e3"
},
{
"path": "skills/service-mesh-configurator/assets/example_microservices_architecture.md",
"sha256": "142a6b9225f748f3227b10ac79822132d48cec361410ecdd49222cc5f36dcd2d"
}
],
"dirSha256": "c534cf6cdcca4ce9bc59a8e3e31db23aa1e2df60e445ca8b7e2df3e659d8dc14"
},
"security": {
"scannedAt": null,
"scannerVersion": null,
"flags": []
}
}

52
skills/service-mesh-configurator/SKILL.md Normal file
View File

@@ -0,0 +1,52 @@
---
name: configuring-service-meshes
description: |
This skill configures service meshes like Istio and Linkerd for microservices. It generates production-ready configurations, implements best practices, and ensures a security-first approach. Use this skill when the user asks to "configure service mesh", "setup Istio", "setup Linkerd", or requests assistance with "service mesh configuration" for their microservices architecture. The configurations will be tailored to the specified infrastructure requirements.
allowed-tools: Read, Write, Edit, Grep, Glob, Bash
version: 1.0.0
---
## Overview
This skill enables Claude to generate configurations and setup code for service meshes like Istio and Linkerd. It simplifies the process of deploying and managing microservices by automating the configuration of essential service mesh components.
## How It Works
1. **Requirement Gathering**: Claude identifies the specific service mesh (Istio or Linkerd) and infrastructure requirements from the user's request.
2. **Configuration Generation**: Based on the requirements, Claude generates the necessary configuration files, including YAML manifests and setup scripts.
3. **Code Delivery**: Claude provides the generated configurations and setup code to the user, ready for deployment.
## When to Use This Skill
This skill activates when you need to:
- Configure Istio for a microservices application.
- Configure Linkerd for a microservices application.
- Generate service mesh configurations based on specific infrastructure requirements.
## Examples
### Example 1: Setting up Istio
User request: "Configure Istio for my Kubernetes microservices deployment with mTLS enabled."
The skill will:
1. Generate Istio configuration files with mTLS enabled.
2. Provide the generated YAML manifests and setup instructions.
### Example 2: Configuring Linkerd
User request: "Setup Linkerd on my existing microservices cluster, focusing on traffic splitting and observability."
The skill will:
1. Generate Linkerd configuration files for traffic splitting and observability.
2. Provide the generated YAML manifests and setup instructions.
## Best Practices
- **Security**: Always prioritize security configurations, such as mTLS, when configuring service meshes.
- **Observability**: Ensure that the service mesh is configured for comprehensive observability, including metrics, tracing, and logging.
- **Traffic Management**: Use traffic management features like traffic splitting and canary deployments to manage application updates safely.
## Integration
This skill can be integrated with other DevOps tools and plugins in the Claude Code ecosystem to automate the deployment and management of microservices applications. For example, it can work with a Kubernetes deployment plugin to automatically deploy the generated configurations.

8
skills/service-mesh-configurator/assets/README.md Normal file
View File

@@ -0,0 +1,8 @@
# Assets
Bundled resources for service-mesh-configurator skill
- [ ] istio_config_template.yaml: A template for generating Istio service mesh configurations.
- [ ] linkerd_config_template.yaml: A template for generating Linkerd service mesh configurations.
- [ ] example_microservices_architecture.md: Example microservices architecture to demonstrate service mesh configuration.
- [ ] error_handling_strategies.md: Document outlining error handling strategies for service mesh configurations.

226
skills/service-mesh-configurator/assets/error_handling_strategies.md Normal file
View File

@@ -0,0 +1,226 @@
# Error Handling Strategies for Service Mesh Configurations
This document outlines various error handling strategies that can be implemented when configuring and managing a service mesh, such as Istio or Linkerd, for microservices. Effective error handling is crucial for ensuring the resilience and reliability of your applications.
## 1. Circuit Breakers
Circuit breakers prevent cascading failures by stopping requests to a failing service after a certain threshold of errors is reached. This allows the failing service to recover without being overwhelmed by further requests.
**Implementation:**
* **Istio:** Use Istio's `DestinationRule` to configure circuit breaking. Define thresholds for connection errors, request timeouts, and number of consecutive errors.
```yaml
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: <destination-rule-name>
spec:
host: <service-name>
trafficPolicy:
connectionPool:
tcp:
maxConnections: 100
http:
http1MaxPendingRequests: 10
maxRequestsPerConnection: 10
outlierDetection:
consecutive5xxErrors: 5
interval: 10s
baseEjectionTime: 30s
maxEjectionPercent: 10
```
* `consecutive5xxErrors`: Number of consecutive 5xx errors before ejecting the host.
* `interval`: The time interval between ejection analysis.
* `baseEjectionTime`: The minimum ejection duration.
* `maxEjectionPercent`: The maximum percentage of hosts that can be ejected.
* **Linkerd:** Linkerd automatically implements circuit breaking through its retries and timeouts configuration. You can fine-tune its behavior via Service Profiles. See Linkerd documentation for details.
**Configuration Notes:**
* Adjust the thresholds (e.g., `consecutive5xxErrors`, `interval`) based on your application's specific needs and traffic patterns.
* Monitor the circuit breaker status to identify failing services and potential issues.
## 2. Retries
Retries allow a client to automatically retry failed requests, potentially recovering from transient errors.
**Implementation:**
* **Istio:** Configure retries within the `VirtualService`. Specify the number of retries, the retry timeout, and the retry conditions (e.g., `gateway-error`, `connect-failure`, `refused-stream`).
```yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: <virtual-service-name>
spec:
hosts:
- <service-name>
http:
- route:
- destination:
host: <target-service-name>
retries:
attempts: 3
perTryTimeout: 2s
retryOn: gateway-error,connect-failure,refused-stream
```
* `attempts`: The maximum number of retry attempts.
* `perTryTimeout`: The timeout for each retry attempt.
* `retryOn`: The conditions under which a retry should be attempted.
* **Linkerd:** Linkerd provides automatic retries based on Service Profiles. Retries are configured based on the observed behavior of the service.
**Configuration Notes:**
* Use exponential backoff for retries to avoid overwhelming the failing service.
* Limit the number of retries to prevent infinite loops.
* Consider the idempotency of the operation being retried to avoid unintended side effects. Only retry idempotent operations unless your application logic can handle duplicates.
## 3. Timeouts
Timeouts prevent requests from hanging indefinitely, ensuring that resources are not tied up unnecessarily.
**Implementation:**
* **Istio:** Configure timeouts within the `VirtualService`. Specify the `timeout` duration for each route.
```yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: <virtual-service-name>
spec:
hosts:
- <service-name>
http:
- route:
- destination:
host: <target-service-name>
timeout: 5s
```
* `timeout`: The maximum duration for a request to complete.
* **Linkerd:** Linkerd uses request timeouts based on Service Profiles. These are automatically configured based on the observed behavior of the service. You can manually override these.
**Configuration Notes:**
* Set timeouts that are appropriate for the expected response time of the service.
* Monitor timeout events to identify slow or unresponsive services.
* Consider using different timeouts for different types of requests.
## 4. Fallbacks (Optional)
For critical services, consider implementing fallback mechanisms to provide a degraded but functional experience in case of failures. This could involve returning cached data, redirecting to a backup service, or displaying a user-friendly error message.
**Implementation:**
* Fallbacks are typically implemented within the application code itself. The service mesh can be configured to route traffic to a fallback service when the primary service is unavailable.
**Example (Conceptual):**
```
# Pseudo-code for fallback logic
try:
data = fetch_data_from_primary_service()
except ServiceUnavailableException:
data = fetch_data_from_cache()
if data is None:
data = get_default_data() # or display an error message
return data
```
**Configuration Notes:**
* Carefully design fallback mechanisms to ensure data consistency and avoid unintended side effects.
* Monitor the usage of fallback mechanisms to identify potential issues with the primary service.
## 5. Graceful Degradation
Graceful degradation ensures that the application remains functional, albeit with reduced functionality, during periods of high load or service failures.
**Implementation:**
* Implement mechanisms to disable non-essential features or redirect traffic to less resource-intensive services.
* Use feature flags to dynamically enable or disable features based on the current system load.
**Configuration Notes:**
* Prioritize essential features to ensure that the most critical functionality remains available.
* Monitor system load and performance metrics to trigger graceful degradation when necessary.
## 6. Health Checks
Regular health checks allow the service mesh to automatically detect and remove unhealthy instances of a service from the load balancing pool.
**Implementation:**
* **Istio:** Configure health checks within the `Service` definition in Kubernetes.
```yaml
apiVersion: v1
kind: Service
metadata:
name: <service-name>
spec:
ports:
- name: http
port: 8080
targetPort: 8080
selector:
app: <service-name>
healthCheckNodePort: 31000 #Optional, specifies a node port for health checks if needed
```
Also, configure liveness and readiness probes in the deployment.
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: <deployment-name>
spec:
template:
spec:
containers:
- name: <container-name>
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 3
periodSeconds: 3
readinessProbe:
httpGet:
path: /readyz
port: 8080
initialDelaySeconds: 5
periodSeconds: 5
```
* **Linkerd:** Linkerd automatically uses health checks provided by Kubernetes.
**Configuration Notes:**
* Use health checks that accurately reflect the health of the service.
* Configure appropriate timeouts and thresholds for health checks.
* Ensure that health checks are lightweight and do not consume excessive resources.
## Monitoring and Alerting
Implement comprehensive monitoring and alerting to detect and respond to errors and failures in a timely manner. Monitor metrics such as error rates, latency, and resource utilization.
**Configuration Notes:**
* Use a monitoring tool such as Prometheus, Grafana, or Datadog.
* Configure alerts to notify you of critical errors or performance degradations.
* Regularly review monitoring dashboards and alerts to identify trends and potential issues.
## Conclusion
Implementing these error handling strategies is crucial for building resilient and reliable microservice applications. By carefully configuring your service mesh and monitoring your applications, you can minimize the impact of errors and ensure a positive user experience. Remember to adapt these strategies to your specific application requirements and environment.

139
skills/service-mesh-configurator/assets/example_microservices_architecture.md Normal file
View File

@@ -0,0 +1,139 @@
# Example Microservices Architecture
This document outlines an example microservices architecture that can be used with the Service Mesh Configurator plugin. It's designed to be a starting point for configuring Istio or Linkerd for your own microservices applications.
## Overview
This example architecture consists of four microservices:
* **Product Catalog Service:** Manages product information (name, description, price, etc.).
* **Inventory Service:** Tracks the available inventory for each product.
* **Order Service:** Handles order placement and management.
* **Payment Service:** Processes payments for orders.
These services communicate with each other to fulfill user requests. For example, when a user places an order, the Order Service interacts with the Product Catalog, Inventory, and Payment Services.
## Architecture Diagram
```mermaid
graph LR
subgraph User
A[User] --> B(Load Balancer)
end
subgraph Infrastructure
B --> C{Order Service}
C --> D[Product Catalog Service]
C --> E[Inventory Service]
C --> F[Payment Service]
end
style A fill:#f9f,stroke:#333,stroke-width:2px
style B fill:#ccf,stroke:#333,stroke-width:2px
style C fill:#ccf,stroke:#333,stroke-width:2px
style D fill:#ccf,stroke:#333,stroke-width:2px
style E fill:#ccf,stroke:#333,stroke-width:2px
style F fill:#ccf,stroke:#333,stroke-width:2px
```
## Service Details
### Product Catalog Service
* **Purpose:** Provides information about available products.
* **Technology Stack:** [Placeholder: Specify technology stack, e.g., Java/Spring Boot]
* **API Endpoints:**
* `/products`: Returns a list of all products.
* `/products/{product_id}`: Returns details for a specific product.
* **Example Request (GET /products/123):**
```json
{
"product_id": "123",
"name": "Example Product",
"description": "A sample product description.",
"price": 29.99
}
```
* **Deployment Details:** [Placeholder: Specify deployment details, e.g., Kubernetes Deployment name, number of replicas]
### Inventory Service
* **Purpose:** Tracks the inventory levels for each product.
* **Technology Stack:** [Placeholder: Specify technology stack, e.g., Python/Flask]
* **API Endpoints:**
* `/inventory/{product_id}`: Returns the current inventory level for a product.
* `/inventory/{product_id}/update`: Updates the inventory level for a product (requires authentication).
* **Example Request (GET /inventory/123):**
```json
{
"product_id": "123",
"quantity": 50
}
```
* **Deployment Details:** [Placeholder: Specify deployment details, e.g., Kubernetes Deployment name, number of replicas]
### Order Service
* **Purpose:** Handles order placement, tracking, and management.
* **Technology Stack:** [Placeholder: Specify technology stack, e.g., Node.js/Express]
* **API Endpoints:**
* `/orders`: Creates a new order.
* `/orders/{order_id}`: Retrieves details for a specific order.
* `/orders/{order_id}/status`: Updates the status of an order (requires authentication).
* **Example Request (POST /orders):**
```json
{
"user_id": "user123",
"items": [
{
"product_id": "123",
"quantity": 2
},
{
"product_id": "456",
"quantity": 1
}
]
}
```
* **Deployment Details:** [Placeholder: Specify deployment details, e.g., Kubernetes Deployment name, number of replicas]
### Payment Service
* **Purpose:** Processes payments for orders.
* **Technology Stack:** [Placeholder: Specify technology stack, e.g., Go]
* **API Endpoints:**
* `/payment`: Processes a payment for an order.
* `/payment/{payment_id}`: Retrieves details for a specific payment.
* **Example Request (POST /payment):**
```json
{
"order_id": "order123",
"amount": 89.97,
"payment_method": "credit_card",
"credit_card_number": "[Placeholder: Encrypted/Tokenized Credit Card Number]"
}
```
* **Deployment Details:** [Placeholder: Specify deployment details, e.g., Kubernetes Deployment name, number of replicas]
## Service Mesh Configuration Considerations
This example architecture highlights several areas where a service mesh like Istio or Linkerd can provide significant benefits:
* **Traffic Management:** Control the flow of traffic between services (e.g., routing rules, canary deployments, A/B testing).
* **Security:** Implement mutual TLS (mTLS) for secure communication between services.
* **Observability:** Gain insights into service performance through metrics, tracing, and logging.
* **Resilience:** Implement retry policies, circuit breakers, and timeouts to improve application resilience.
## Using the Service Mesh Configurator Plugin
The Service Mesh Configurator plugin can help you automate the configuration of your service mesh based on this architecture. Specifically, the plugin can assist with:
1. **Defining Service Mesh Policies:** Creating policies for traffic routing, security, and observability.
2. **Generating Configuration Files:** Generating the necessary YAML files for deploying Istio or Linkerd configurations.
3. **Validating Configurations:** Ensuring that your configurations are valid and conform to best practices.
To use the plugin, provide the relevant details about your microservices (technology stack, API endpoints, deployment details) in the placeholders above. The plugin will then use this information to generate the appropriate service mesh configuration.
Remember to replace the placeholder values with your actual service details.

74
skills/service-mesh-configurator/assets/istio_config_template.yaml Normal file
View File

@@ -0,0 +1,74 @@
# istio_config_template.yaml
# Template for generating Istio service mesh configurations.
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: REPLACE_ME-gateway # Name of the gateway
namespace: YOUR_NAMESPACE_HERE # Namespace where the gateway is deployed
spec:
selector:
istio: ingressgateway # Use Istio's default ingress gateway
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- REPLACE_ME.example.com # Hostname for your service
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: REPLACE_ME-virtual-service # Name of the virtual service
namespace: YOUR_NAMESPACE_HERE # Namespace where the virtual service is deployed
spec:
hosts:
- REPLACE_ME.example.com # Hostname to route traffic to
gateways:
- REPLACE_ME-gateway # Gateway to use for routing
http:
- match:
- uri:
prefix: / # Match all URIs
route:
- destination:
host: REPLACE_ME-service # Name of the service to route to
port:
number: 8080 # Port of the service
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: REPLACE_ME-destination-rule # Name of the destination rule
namespace: YOUR_NAMESPACE_HERE # Namespace where the destination rule is deployed
spec:
host: REPLACE_ME-service # Name of the service
trafficPolicy:
loadBalancer:
simple: ROUND_ROBIN # Load balancing policy. Options: ROUND_ROBIN, LEAST_CONN, RANDOM, PASSTHROUGH
# Optional: Configure TLS settings
# tls:
# mode: ISTIO_MUTUAL # Use Istio mutual TLS
---
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: REPLACE_ME-authz-policy # Name of the authorization policy
namespace: YOUR_NAMESPACE_HERE # Namespace where the authorization policy is deployed
spec:
selector:
matchLabels:
app: REPLACE_ME-service # Apply the policy to the service
action: ALLOW # Default action: ALLOW or DENY
# Optional: Add rules for specific requests
# rules:
# - from:
# - source:
# principals: ["cluster.local/ns/YOUR_NAMESPACE_HERE/sa/YOUR_SERVICE_ACCOUNT_HERE"] # Allow requests from a specific service account
# to:
# - operation:
# methods: ["GET", "POST"] # Allow only GET and POST methods

113
skills/service-mesh-configurator/assets/linkerd_config_template.yaml Normal file
View File

@@ -0,0 +1,113 @@
# Linkerd Configuration Template
# This template provides a starting point for configuring Linkerd service mesh.
# Replace placeholders (REPLACE_ME, YOUR_VALUE_HERE) with your actual values.
# ---
# Global Configuration
# ---
global:
# Namespace for Linkerd control plane components. Consider a dedicated namespace.
namespace: linkerd
# Cluster domain. Used for service discovery.
clusterDomain: cluster.local
# Enable tracing. Requires a tracing backend like Jaeger or Zipkin.
tracing:
enabled: false
# Endpoint for the tracing collector (e.g., Jaeger). Uncomment and configure if enabled.
# collectorEndpoint: http://jaeger.linkerd.svc.cluster.local:14268/api/traces
# Control plane version. Should match the Linkerd version.
controlPlaneVersion: REPLACE_ME # Example: stable-2.14.3
# ---
# Namespace-Specific Configuration
# ---
namespaces:
- name: YOUR_NAMESPACE_HERE # The namespace where your microservices are deployed.
# Automatically inject Linkerd proxies into pods in this namespace.
autoInject: true
# Resources to be injected into the namespace. Optional.
resources:
# Limit ranges for resource consumption.
limitRanges:
- name: default-limits
spec:
limits:
- default:
cpu: "500m" # 0.5 CPU core
memory: "512Mi"
defaultRequest:
cpu: "100m" # 0.1 CPU core
memory: "128Mi"
type: Container
# Resource quotas for the namespace.
resourceQuotas:
- name: default-quota
spec:
hard:
pods: "10" # Maximum number of pods in the namespace
cpu: "5" # 5 CPU cores
memory: "5Gi"
# ---
# Workload-Specific Configuration (Example: Deployment)
# ---
workloads:
- kind: Deployment
name: YOUR_DEPLOYMENT_NAME_HERE # Name of your deployment
namespace: YOUR_NAMESPACE_HERE
spec:
# Configure proxy settings for the workload.
proxy:
# CPU and memory requests/limits for the proxy container. Adjust based on workload needs.
resources:
requests:
cpu: "50m"
memory: "64Mi"
limits:
cpu: "200m"
memory: "128Mi"
# Configure the proxy's outbound concurrency. Helps prevent overwhelming downstream services.
# outboundConcurrency: 100 # Example value
# Enable traffic shifting. Requires a traffic split resource.
trafficSplit:
enabled: false
# Set log level for the proxy. Useful for debugging.
logLevel: info # Options: debug, info, warn, error
# Enable Prometheus metrics scraping for this workload.
metrics:
enabled: true
# Enable retries for failed requests. Configure retry policies carefully.
retry:
enabled: false
# retryPolicy:
# numRetries: 3
# perTryTimeout: 1s
# ---
# Service-Specific Configuration (Example: Service)
# ---
services:
- name: YOUR_SERVICE_NAME_HERE # Name of your service
namespace: YOUR_NAMESPACE_HERE
spec:
# Configure service profile for the service.
serviceProfile:
enabled: true # Enables Linkerd to collect metrics and provide routing information
# Add routes for different endpoints. Example:
# routes:
# - name: /api/v1/users
# condition:
# method: GET
# pathRegex: /api/v1/users
# isRetryable: true

8
skills/service-mesh-configurator/references/README.md Normal file
View File

@@ -0,0 +1,8 @@
# References
Bundled resources for service-mesh-configurator skill
- [ ] istio_best_practices.md: A document outlining best practices for configuring Istio service mesh.
- [ ] linkerd_best_practices.md: A document outlining best practices for configuring Linkerd service mesh.
- [ ] service_mesh_security_guidelines.md: Security guidelines for service mesh configurations.
- [ ] supported_platforms.md: List of supported platforms and their specific configuration requirements (e.g., Kubernetes versions, cloud providers).

8
skills/service-mesh-configurator/scripts/README.md Normal file
View File

@@ -0,0 +1,8 @@
# Scripts
Bundled resources for service-mesh-configurator skill
- [ ] validate_config.py: Validates the generated service mesh configuration against best practices and common errors.
- [ ] deploy_config.sh: Deploys the generated service mesh configuration to the target environment (Kubernetes).
- [ ] rollback_config.sh: Rolls back the service mesh configuration to the previous version in case of issues.
- [ ] generate_test_traffic.py: Generates test traffic to verify the service mesh configuration.