An open API service indexing awesome lists of open source software.

https://github.com/aryprogrammer/doks-k8s


https://github.com/aryprogrammer/doks-k8s

Last synced: 4 months ago
JSON representation

Awesome Lists containing this project

README

          

Here’s a **detailed breakdown** of each method, along with **alternative approaches** based on different requirements.

---

## **1. Transfer DigitalOcean Kubernetes Cluster Ownership**
This is the **simplest** and most direct method if the client wants **full control** over the cluster, including billing.

### **Steps:**
1. **Invite the Client to Your DigitalOcean Team**
- Go to **DigitalOcean Console → Teams → Manage Team**.
- Click **Invite Members** and enter the client's email.
- Assign them the role of **Owner**.

2. **Transfer Cluster Ownership**
- Once they join, go to **Kubernetes** in the DigitalOcean dashboard.
- Click on the cluster → **Settings** → **Transfer**.
- Select the client’s account as the new owner.

3. **Client Accepts the Transfer**
- The client will receive an email.
- Once they **accept**, they become the new owner, and you can remove yourself.

### **Alternative Approach:**
- If you don’t want to transfer your **entire team**, you can create a **new DigitalOcean team**, set up the cluster there, and then **invite the client**.
- The client can then **remove you from the team** once they confirm ownership.

🔹 **Best For:** When the client wants **full control and billing responsibility**.

---

## **2. Export and Provide Cluster Configuration (`kubeconfig`)**
If the client wants **access** to the cluster but does **not need ownership**, you can just share the **kubeconfig file**.

### **Steps:**
1. **Get the kubeconfig File**
Run the following command in your terminal:
```sh
doctl kubernetes cluster kubeconfig save
```
- This saves the cluster configuration to `~/.kube/config`.

2. **Send the Configuration to the Client**
- The file is located at `~/.kube/config`.
- Copy and **share** it with the client.
- They can use it to connect using `kubectl`:
```sh
kubectl get nodes
```

### **Alternative Approach:**
- Instead of giving full access, you can create a **read-only service account** for the client, restricting their permissions using Role-Based Access Control (RBAC).
- Example YAML to create a **limited access role**:
```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: default
name: read-only-role
rules:
- apiGroups: [""]
resources: ["pods", "services"]
verbs: ["get", "list"]
```

🔹 **Best For:** When the client **only needs access, not ownership**.

---

## **3. Provide Terraform or Helm Scripts to Recreate the Cluster**
If the client wants to **deploy the cluster themselves**, you can give them the **Terraform or Helm files** used to create it.

### **Steps:**
1. **Export the Terraform Configuration (if applicable)**
If you used Terraform, share the `.tf` file:
```hcl
resource "digitalocean_kubernetes_cluster" "example" {
name = "client-k8s"
region = "nyc1"
version = "1.27.2-do.0"

node_pool {
name = "worker-pool"
size = "s-2vcpu-4gb"
node_count = 3
}
}
```
- The client runs:
```sh
terraform apply
```
to create the cluster.

2. **Share Helm Charts (if applicable)**
If you deployed workloads using **Helm**, package and send the Helm chart:
```sh
helm package mychart/
```
- The client installs it using:
```sh
helm install my-release mychart.tgz
```

### **Alternative Approach:**
- If you used **Pulumi** or **Ansible**, you can share the respective scripts instead.

🔹 **Best For:** When the client wants to **create the cluster on their own**.

---

## **4. Backup and Restore to Client’s Cluster**
If the client has **already set up a K8s cluster** and just wants **your workloads**, you can export the existing state.

### **Steps:**
1. **Backup All Manifests from the Current Cluster**
```sh
kubectl get all -o yaml > backup.yaml
```

2. **Send the File to the Client**

3. **Client Restores the Configuration**
- They apply the backup in their own cluster:
```sh
kubectl apply -f backup.yaml
```

### **Alternative Approach:**
- Instead of using `kubectl get all`, use:
```sh
kubectl get deployments,services,configmaps,secrets -o yaml > deployment-backup.yaml
```
- This excludes unnecessary resources.

🔹 **Best For:** When the client already has a **running cluster**.

---

## **5. Migrate Workloads Using Velero (For Full Backup)**
If the client wants an **exact replica**, use **Velero**, which is specifically designed for K8s backups.

### **Steps:**
1. **Install Velero on Your Cluster**
```sh
velero install --provider aws --plugins velero/velero-plugin-for-aws:v1.4.0 \
--bucket --backup-location-config region=
```

2. **Backup Everything**
```sh
velero backup create full-backup --include-namespaces=*
```

3. **Share the Backup with the Client**
- The client restores it using:
```sh
velero restore create --from-backup full-backup
```

### **Alternative Approach:**
- Instead of backing up everything, you can **only backup specific namespaces**:
```sh
velero backup create my-backup --include-namespaces=my-namespace
```

🔹 **Best For:** When you need a **full backup and restore** across different clusters.

---

## **Which Method Should You Choose?**
| **Scenario** | **Method** |
|-------------|------------|
| Client wants full ownership, including billing | **Transfer DigitalOcean ownership** |
| Client just needs access to manage the cluster | **Share `kubeconfig` file** |
| Client wants to recreate the cluster on their account | **Provide Terraform/Helm scripts** |
| Client has a cluster and wants your workloads | **Backup & Restore with `kubectl`** |
| Client wants an exact copy of your cluster | **Use Velero for migration** |

---

💡 **Final Recommendation:**
If the client is new to Kubernetes and doesn’t want to manage infrastructure, the **best option** is **transferring the cluster ownership**. If they are experienced, you can provide Terraform files so they can recreate it in their own account.

Let me know which method you prefer, and I can guide you with step-by-step commands! 🚀