@sylix/coworker 2.0.11 → 2.0.12

package/dist/skills/defaults/devops/linkerd-patterns.md

@@ -0,0 +1,311 @@
+---
+name: linkerd-patterns
+description: Implement Linkerd service mesh patterns for lightweight, security-focused service mesh deployments. Use when setting up Linkerd, configuring traffic policies, or implementing zero-trust networking with minimal overhead.
+---
+
+# Linkerd Patterns
+
+Production patterns for Linkerd service mesh - the lightweight, security-first service mesh for Kubernetes.
+
+## When to Use This Skill
+
+- Setting up a lightweight service mesh
+- Implementing automatic mTLS
+- Configuring traffic splits for canary deployments
+- Setting up service profiles for per-route metrics
+- Implementing retries and timeouts
+- Multi-cluster service mesh
+
+## Core Concepts
+
+### 1. Linkerd Architecture
+
+```
+┌─────────────────────────────────────────────┐
+│                Control Plane                 │
+│  ┌─────────┐ ┌──────────┐ ┌──────────────┐ │
+│  │ destiny │ │ identity │ │ proxy-inject │ │
+│  └─────────┘ └──────────┘ └──────────────┘ │
+└─────────────────────────────────────────────┘
+                      │
+┌─────────────────────────────────────────────┐
+│                 Data Plane                   │
+│  ┌─────┐    ┌─────┐    ┌─────┐             │
+│  │proxy│────│proxy│────│proxy│             │
+│  └─────┘    └─────┘    └─────┘             │
+│     │           │           │               │
+│  ┌──┴──┐    ┌──┴──┐    ┌──┴──┐            │
+│  │ app │    │ app │    │ app │            │
+│  └─────┘    └─────┘    └─────┘            │
+└─────────────────────────────────────────────┘
+```
+
+### 2. Key Resources
+
+| Resource                | Purpose                              |
+| ----------------------- | ------------------------------------ |
+| **ServiceProfile**      | Per-route metrics, retries, timeouts |
+| **TrafficSplit**        | Canary deployments, A/B testing      |
+| **Server**              | Define server-side policies          |
+| **ServerAuthorization** | Access control policies              |
+
+## Templates
+
+### Template 1: Mesh Installation
+
+```bash
+# Install CLI
+curl --proto '=https' --tlsv1.2 -sSfL https://run.linkerd.io/install | sh
+
+# Validate cluster
+linkerd check --pre
+
+# Install CRDs
+linkerd install --crds | kubectl apply -f -
+
+# Install control plane
+linkerd install | kubectl apply -f -
+
+# Verify installation
+linkerd check
+
+# Install viz extension (optional)
+linkerd viz install | kubectl apply -f -
+```
+
+### Template 2: Inject Namespace
+
+```yaml
+# Automatic injection for namespace
+apiVersion: v1
+kind: Namespace
+metadata:
+  name: my-app
+  annotations:
+    linkerd.io/inject: enabled
+---
+# Or inject specific deployment
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: my-app
+  annotations:
+    linkerd.io/inject: enabled
+spec:
+  template:
+    metadata:
+      annotations:
+        linkerd.io/inject: enabled
+```
+
+### Template 3: Service Profile with Retries
+
+```yaml
+apiVersion: linkerd.io/v1alpha2
+kind: ServiceProfile
+metadata:
+  name: my-service.my-namespace.svc.cluster.local
+  namespace: my-namespace
+spec:
+  routes:
+    - name: GET /api/users
+      condition:
+        method: GET
+        pathRegex: /api/users
+      responseClasses:
+        - condition:
+            status:
+              min: 500
+              max: 599
+          isFailure: true
+      isRetryable: true
+    - name: POST /api/users
+      condition:
+        method: POST
+        pathRegex: /api/users
+      # POST not retryable by default
+      isRetryable: false
+    - name: GET /api/users/{id}
+      condition:
+        method: GET
+        pathRegex: /api/users/[^/]+
+      timeout: 5s
+      isRetryable: true
+  retryBudget:
+    retryRatio: 0.2
+    minRetriesPerSecond: 10
+    ttl: 10s
+```
+
+### Template 4: Traffic Split (Canary)
+
+```yaml
+apiVersion: split.smi-spec.io/v1alpha1
+kind: TrafficSplit
+metadata:
+  name: my-service-canary
+  namespace: my-namespace
+spec:
+  service: my-service
+  backends:
+    - service: my-service-stable
+      weight: 900m # 90%
+    - service: my-service-canary
+      weight: 100m # 10%
+```
+
+### Template 5: Server Authorization Policy
+
+```yaml
+# Define the server
+apiVersion: policy.linkerd.io/v1beta1
+kind: Server
+metadata:
+  name: my-service-http
+  namespace: my-namespace
+spec:
+  podSelector:
+    matchLabels:
+      app: my-service
+  port: http
+  proxyProtocol: HTTP/1
+---
+# Allow traffic from specific clients
+apiVersion: policy.linkerd.io/v1beta1
+kind: ServerAuthorization
+metadata:
+  name: allow-frontend
+  namespace: my-namespace
+spec:
+  server:
+    name: my-service-http
+  client:
+    meshTLS:
+      serviceAccounts:
+        - name: frontend
+          namespace: my-namespace
+---
+# Allow unauthenticated traffic (e.g., from ingress)
+apiVersion: policy.linkerd.io/v1beta1
+kind: ServerAuthorization
+metadata:
+  name: allow-ingress
+  namespace: my-namespace
+spec:
+  server:
+    name: my-service-http
+  client:
+    unauthenticated: true
+    networks:
+      - cidr: 10.0.0.0/8
+```
+
+### Template 6: HTTPRoute for Advanced Routing
+
+```yaml
+apiVersion: policy.linkerd.io/v1beta2
+kind: HTTPRoute
+metadata:
+  name: my-route
+  namespace: my-namespace
+spec:
+  parentRefs:
+    - name: my-service
+      kind: Service
+      group: core
+      port: 8080
+  rules:
+    - matches:
+        - path:
+            type: PathPrefix
+            value: /api/v2
+        - headers:
+            - name: x-api-version
+              value: v2
+      backendRefs:
+        - name: my-service-v2
+          port: 8080
+    - matches:
+        - path:
+            type: PathPrefix
+            value: /api
+      backendRefs:
+        - name: my-service-v1
+          port: 8080
+```
+
+### Template 7: Multi-cluster Setup
+
+```bash
+# On each cluster, install with cluster credentials
+linkerd multicluster install | kubectl apply -f -
+
+# Link clusters
+linkerd multicluster link --cluster-name west \
+  --api-server-address https://west.example.com:6443 \
+  | kubectl apply -f -
+
+# Export a service to other clusters
+kubectl label svc/my-service mirror.linkerd.io/exported=true
+
+# Verify cross-cluster connectivity
+linkerd multicluster check
+linkerd multicluster gateways
+```
+
+## Monitoring Commands
+
+```bash
+# Live traffic view
+linkerd viz top deploy/my-app
+
+# Per-route metrics
+linkerd viz routes deploy/my-app
+
+# Check proxy status
+linkerd viz stat deploy -n my-namespace
+
+# View service dependencies
+linkerd viz edges deploy -n my-namespace
+
+# Dashboard
+linkerd viz dashboard
+```
+
+## Debugging
+
+```bash
+# Check injection status
+linkerd check --proxy -n my-namespace
+
+# View proxy logs
+kubectl logs deploy/my-app -c linkerd-proxy
+
+# Debug identity/TLS
+linkerd identity -n my-namespace
+
+# Tap traffic (live)
+linkerd viz tap deploy/my-app --to deploy/my-backend
+```
+
+## Best Practices
+
+### Do's
+
+- **Enable mTLS everywhere** - It's automatic with Linkerd
+- **Use ServiceProfiles** - Get per-route metrics and retries
+- **Set retry budgets** - Prevent retry storms
+- **Monitor golden metrics** - Success rate, latency, throughput
+
+### Don'ts
+
+- **Don't skip check** - Always run `linkerd check` after changes
+- **Don't over-configure** - Linkerd defaults are sensible
+- **Don't ignore ServiceProfiles** - They unlock advanced features
+- **Don't forget timeouts** - Set appropriate values per route
+
+## Resources
+
+- [Linkerd Documentation](https://linkerd.io/2.14/overview/)
+- [Service Profiles](https://linkerd.io/2.14/features/service-profiles/)
+- [Authorization Policy](https://linkerd.io/2.14/features/server-policy/)

package/dist/skills/defaults/devops/multi-cloud-architecture.md

@@ -0,0 +1,181 @@
+---
+name: multi-cloud-architecture
+description: Design multi-cloud architectures using a decision framework to select and integrate services across AWS, Azure, and GCP. Use when building multi-cloud systems, avoiding vendor lock-in, or leveraging best-of-breed services from multiple providers.
+---
+
+# Multi-Cloud Architecture
+
+Decision framework and patterns for architecting applications across AWS, Azure, and GCP.
+
+## Purpose
+
+Design cloud-agnostic architectures and make informed decisions about service selection across cloud providers.
+
+## When to Use
+
+- Design multi-cloud strategies
+- Migrate between cloud providers
+- Select cloud services for specific workloads
+- Implement cloud-agnostic architectures
+- Optimize costs across providers
+
+## Cloud Service Comparison
+
+### Compute Services
+
+| AWS     | Azure               | GCP             | Use Case           |
+| ------- | ------------------- | --------------- | ------------------ |
+| EC2     | Virtual Machines    | Compute Engine  | IaaS VMs           |
+| ECS     | Container Instances | Cloud Run       | Containers         |
+| EKS     | AKS                 | GKE             | Kubernetes         |
+| Lambda  | Functions           | Cloud Functions | Serverless         |
+| Fargate | Container Apps      | Cloud Run       | Managed containers |
+
+### Storage Services
+
+| AWS     | Azure           | GCP             | Use Case       |
+| ------- | --------------- | --------------- | -------------- |
+| S3      | Blob Storage    | Cloud Storage   | Object storage |
+| EBS     | Managed Disks   | Persistent Disk | Block storage  |
+| EFS     | Azure Files     | Filestore       | File storage   |
+| Glacier | Archive Storage | Archive Storage | Cold storage   |
+
+### Database Services
+
+| AWS         | Azure            | GCP           | Use Case        |
+| ----------- | ---------------- | ------------- | --------------- |
+| RDS         | SQL Database     | Cloud SQL     | Managed SQL     |
+| DynamoDB    | Cosmos DB        | Firestore     | NoSQL           |
+| Aurora      | PostgreSQL/MySQL | Cloud Spanner | Distributed SQL |
+| ElastiCache | Cache for Redis  | Memorystore   | Caching         |
+
+**Reference:** See `references/service-comparison.md` for complete comparison
+
+## Multi-Cloud Patterns
+
+### Pattern 1: Single Provider with DR
+
+- Primary workload in one cloud
+- Disaster recovery in another
+- Database replication across clouds
+- Automated failover
+
+### Pattern 2: Best-of-Breed
+
+- Use best service from each provider
+- AI/ML on GCP
+- Enterprise apps on Azure
+- General compute on AWS
+
+### Pattern 3: Geographic Distribution
+
+- Serve users from nearest cloud region
+- Data sovereignty compliance
+- Global load balancing
+- Regional failover
+
+### Pattern 4: Cloud-Agnostic Abstraction
+
+- Kubernetes for compute
+- PostgreSQL for database
+- S3-compatible storage (MinIO)
+- Open source tools
+
+## Cloud-Agnostic Architecture
+
+### Use Cloud-Native Alternatives
+
+- **Compute:** Kubernetes (EKS/AKS/GKE)
+- **Database:** PostgreSQL/MySQL (RDS/SQL Database/Cloud SQL)
+- **Message Queue:** Apache Kafka (MSK/Event Hubs/Confluent)
+- **Cache:** Redis (ElastiCache/Azure Cache/Memorystore)
+- **Object Storage:** S3-compatible API
+- **Monitoring:** Prometheus/Grafana
+- **Service Mesh:** Istio/Linkerd
+
+### Abstraction Layers
+
+```
+Application Layer
+    ↓
+Infrastructure Abstraction (Terraform)
+    ↓
+Cloud Provider APIs
+    ↓
+AWS / Azure / GCP
+```
+
+## Cost Comparison
+
+### Compute Pricing Factors
+
+- **AWS:** On-demand, Reserved, Spot, Savings Plans
+- **Azure:** Pay-as-you-go, Reserved, Spot
+- **GCP:** On-demand, Committed use, Preemptible
+
+### Cost Optimization Strategies
+
+1. Use reserved/committed capacity (30-70% savings)
+2. Leverage spot/preemptible instances
+3. Right-size resources
+4. Use serverless for variable workloads
+5. Optimize data transfer costs
+6. Implement lifecycle policies
+7. Use cost allocation tags
+8. Monitor with cloud cost tools
+
+**Reference:** See `references/multi-cloud-patterns.md`
+
+## Migration Strategy
+
+### Phase 1: Assessment
+
+- Inventory current infrastructure
+- Identify dependencies
+- Assess cloud compatibility
+- Estimate costs
+
+### Phase 2: Pilot
+
+- Select pilot workload
+- Implement in target cloud
+- Test thoroughly
+- Document learnings
+
+### Phase 3: Migration
+
+- Migrate workloads incrementally
+- Maintain dual-run period
+- Monitor performance
+- Validate functionality
+
+### Phase 4: Optimization
+
+- Right-size resources
+- Implement cloud-native services
+- Optimize costs
+- Enhance security
+
+## Best Practices
+
+1. **Use infrastructure as code** (Terraform/OpenTofu)
+2. **Implement CI/CD pipelines** for deployments
+3. **Design for failure** across clouds
+4. **Use managed services** when possible
+5. **Implement comprehensive monitoring**
+6. **Automate cost optimization**
+7. **Follow security best practices**
+8. **Document cloud-specific configurations**
+9. **Test disaster recovery** procedures
+10. **Train teams** on multiple clouds
+
+## Reference Files
+
+- `references/service-comparison.md` - Complete service comparison
+- `references/multi-cloud-patterns.md` - Architecture patterns
+
+## Related Skills
+
+- `terraform-module-library` - For IaC implementation
+- `cost-optimization` - For cost management
+- `hybrid-cloud-networking` - For connectivity