GKE

This guide provides detailed instructions for deploying Kuberise.io on a GKE cluster. It covers the preparation steps, requirements, and configurations for internal and external DNS using Google Cloud DNS and ExternalDNS.

Assumptions

• I assume 'kuberise.internal' is my internal domain for communication of internal services inside cluster. But you can replace it with your own internal domain.
• I assume 'gke.kuberise.dev' is my external domain for communication of external services outside cluster and I manage it with Cloudflare by external-dns. But you can replace it with your own external domain and manage it with any other DNS provider and set the DNS records manually or with external-dns.

Prerequisites

Before starting, ensure you have the following:

• Google Cloud Account: Access to a Google Cloud project with billing enabled.
• CLI Tools: kubectl, helm, git, htpasswd, openssl.
• Kubernetes Cluster: A GKE cluster with appropriate permissions.
• Domain Names: Domains for external and internal services (e.g., gke.kuberise.dev and kuberise.internal).
• Service Accounts: A Google Cloud service account for ExternalDNS with DNS permissions.
• Cloud DNS Zones: A private DNS zone for internal services.

Preparation

1. Set Up GKE Cluster

Create a GKE cluster in your Google Cloud project. Ensure it has the necessary node pools and network configurations to support your applications.

Item number 2, 3 and 4 are optional and only required if you want to use automatic DNS configuration with ExternalDNS for your internal domain using cloud DNS and for your external domain using Cloudflare.

2. Configure Cloud DNS

Private DNS Zone: Create a private DNS zone for your internal domain (e.g., kuberise.internal), and associate it with your VPC network.

3. Create Service Accounts

• Internal DNS Service Account: Create a Google Cloud service account for Internal DNS with DNS Administrator permissions.
• Attach Service Account: Attach the Google Cloud service account to a Kubernetes service account in the internal-dns namespace called internal-dns.

4. Create Kubernetes Secret for Cloudflare

Create Kubernetes Secret: Create a Kubernetes secret with your Cloudflare API token.

kubectl create namespace external-dns
kubectl create secret generic cloudflare --from-literal cloudflare_api_token=[paste the token here] -n external-dns

Deployment Instructions

1. Fork and Clone Repository

Fork the kuberise.io repository and clone it to your local machine.

2. Modify Configuration Files

Update the 'values-gke.yaml' configuration file and enable the necessary Helm charts and applications.

helm:
  external-dns:
    enabled: true
  internal-dns:
    enabled: true
  argocd-image-updater:
    enabled: true

3. Configure Ingress Controllers

External Ingress Controller

Configure the external ingress-nginx controller to use an external load balancer.

controller:
  service:
    annotations:
      cloud.google.com/load-balancer-type: External

Internal Ingress Controller

Configure the internal ingress-nginx controller to use an internal load balancer.

controller:
  service:
    annotations:
      cloud.google.com/load-balancer-type: Internal

4. Configure ExternalDNS

ExternalDNS for Public DNS

Configure ExternalDNS to use the Cloudflare for public DNS management.

provider: cloudflare
cloudflare:
  secretName: "cloudflare"
  proxied: false

ExternalDNS for Private DNS

Configure Internal DNS to use the Google Cloud DNS zone to manage Internal DNS records.

provider: google
google:
  project: kuberise # Replace this with your Google Cloud project ID
  zoneVisibility: private

5. Configure Service Accounts

Annotate the Kubernetes service account of internal-dns to use the Google Cloud service account.

serviceAccount:
  create: true
  annotations:
    iam.gke.io/gcp-service-account: [email protected]

6. Deploy Applications

Execute the following command after replacing the placeholders with your values:

./scripts/install.sh [CONTEXT] [NAME] [REPO_URL] [REVISION] [DOMAIN] [TOKEN]

• [CONTEXT]: Your Kubernetes context name for your GKE cluster. Find your current context with kubectl config current-context.
• [NAME]: The name of your platform. Ensure there is a values-[NAME].yaml file in the app-of-apps folder and a [NAME] folder in the values directory for all configurations.
• [REPO_URL]: The URL of your forked repository.
• [REVISION]: The branch, commit SHA, or tag you want to use for this installation (e.g., "main" for the main branch).
• [DOMAIN]: The domain for the cluster. All platform services and applications will be subdomains of this domain (e.g., keycloak.[DOMAIN]). For gke, you might use gke.kuberise.dev, resulting in keycloak.gke.kuberise.dev.
• [TOKEN]: If using a private repository, provide a token here so ArgoCD can access your repository. Skip this parameter if your repository is public.

Example

Assume:

• Your Kubernetes context is gke-cluster.
• Your platform name is gke.
• Your forked repository URL is https://github.com/[YourUsername]/kuberise.io.git
• You want to use the main branch.
• Your domain is gke.kuberise.dev.

Then, the installation command would be:

./scripts/install.sh gke-cluster gke https://github.com/[YourUsername]/kuberise.io.git main gke.kuberise.dev

7. Access Dashboards

Once you finished the installation, you can access the dashboards and services using the domain you specified during installation. For example, if your domain is gke.kuberise.dev, you can access the Keycloak dashboard at keycloak.gke.kuberise.dev.

Cloudflare Token

If you are using Cloudflare for your DNS, you can create a cloudflare API token and put it in environment variable CLOUDFLARE_API_TOKEN, then the installation script will automatically create a Kubernetes secret and the ExternalDNS will use it to update the DNS records for your External Ingresses.

Post Installation

The ./script/install.sh script is idempotent, you can run it multiple times to update your installation without any problem. You need to run the install.sh script again, if you change values of the ArgoCD helm chart or the install.sh script itself. Also you have to run install.sh script for each platform separately. For example if you want to create multiple platform for different environments or for different purposes, you have to run the install.sh script for each platform.