Clone a Cluster

​

Prerequisites

• An existing cluster with GitOps configuration
• Access to the source Git repository
• GitHub credentials configured in Ankra
• Permission to create new repositories or fork existing ones

​

Steps to Clone a Cluster

​

1. Identify the Source Repository

• Find the main GitOps YAML file (e.g., import-cluster.yaml)
• Note any referenced manifests, add-ons, or include directories
• Check the repository structure and dependencies

​

2. Fork or Copy the Repository

# Fork via GitHub UI, then clone locally
git clone https://github.com/YOUR_USERNAME/your-forked-repo.git
cd your-forked-repo

# Create new repo and copy content
git clone https://github.com/original-owner/source-repo.git temp-clone
git clone https://github.com/YOUR_USERNAME/new-cluster-repo.git
cp -r temp-clone/* new-cluster-repo/
cd new-cluster-repo
rm -rf ../temp-clone

​

3. Update Cluster Metadata

apiVersion: v1
kind: ImportCluster
metadata:
  name: my-cluster-staging  # Change from original name
  description: Staging environment cluster  # Update description
spec:
  git_repository:
    provider: github
    credential_name: my-credential
    branch: main
    repository: my-org/my-staging-repo  # Update to new repo
  stacks:
  - name: my-stack
    description: 'Cloned stack for staging'  # Update if needed
    # ... rest of configuration

​

4. Update GitOps Settings

• Repository URL: Update to point to your new repository
• Credentials: Ensure credential_name matches your Ankra setup
• Branch: Change if using a different branch strategy
• Provider: Update if switching Git providers

​

5. Customize for Environment

# Update namespace names for environment isolation
manifests:
- name: app-namespace
  manifest_base64: <base64-encoded YAML with staging namespace>
  namespace: my-app-staging  # Changed from my-app-prod

# Organize by environment
stacks:
- name: my-stack
  manifests:
  - include: manifests/staging/  # Environment-specific path
  addons:
  - include: addons/staging/     # Environment-specific path

​

6. Environment-Specific Customizations

• Resource Limits: Adjust CPU/memory for staging vs production
• Replicas: Scale down for non-production environments
• Secrets: Update secret references for environment-specific values
• Ingress: Change domain names or routing rules
• Storage: Modify storage classes or sizes

# In your values or manifest files
resources:
  requests:
    cpu: 100m     # Reduced from 500m for staging
    memory: 128Mi # Reduced from 512Mi for staging
replicaCount: 1   # Reduced from 3 for staging

​

7. Commit and Push Changes

git add .
git commit -m "Clone cluster configuration for staging environment"
git push origin main

​

8. Import the Cloned Cluster in Ankra

1. Navigate to Clusters in the Ankra dashboard
2. Click Import Cluster
3. Select GitOps import method
4. Enter your new repository details:
   • Repository URL: https://github.com/YOUR_USERNAME/new-cluster-repo
   • Branch: main
   • Credential: Select your configured GitHub credential
5. Point to your main GitOps YAML file
6. Review the configuration preview
7. Click Import to deploy

​

9. Verify the Deployment

• Check the Operations tab for deployment status
• Verify all manifests and add-ons are applied correctly
• Test connectivity and functionality
• Validate environment-specific configurations

​

Best Practices

​

Organization Strategy

• Use Branches: Consider using different branches for different environments
• Environment Folders: Organize configurations in environment-specific directories
• Naming Conventions: Use clear naming patterns (e.g., app-staging, app-prod)

​

Configuration Management

• Environment Variables: Use ConfigMaps and Secrets for environment-specific values
• Helm Values: Leverage Helm’s values system for parameterization
• Kustomize: Consider using Kustomize for environment overlays

​

Version Control

• Tag Releases: Tag stable configurations before cloning
• Document Changes: Maintain clear commit messages and documentation
• Branch Protection: Use branch protection rules for production configurations

​

Testing Strategy

• Validation: Test cloned configurations in development first
• Rollback Plan: Ensure you can revert changes if needed
• Monitoring: Set up monitoring for the cloned environment

​

Common Patterns

​

Multi-Environment Repository

cluster-configs/
├── base/
│   ├── import-cluster.yaml
│   ├── manifests/
│   └── addons/
├── staging/
│   ├── import-cluster.yaml
│   ├── manifests/
│   └── addons/
└── production/
    ├── import-cluster.yaml
    ├── manifests/
    └── addons/

​

Shared Components

stacks:
- name: shared-infrastructure
  manifests:
  - include: shared/manifests/
  addons:
  - include: shared/addons/
- name: environment-specific
  manifests:
  - include: environments/staging/manifests/
  addons:
  - include: environments/staging/addons/

​

Troubleshooting

​

Common Issues

​

Validation

# Check YAML syntax
yaml lint import-cluster.yaml

# Validate Kubernetes manifests
kubectl apply --dry-run=client -f manifests/

# Test Helm charts
helm template addons/my-addon/ --values addons/my-addon/values.yaml

Next Steps: Once your cluster is cloned and deployed, consider setting up monitoring and observability to track the health of your new environment.