{"id":719,"date":"2021-06-13T02:01:00","date_gmt":"2021-06-13T02:01:00","guid":{"rendered":"https:\/\/blog.ngocha.biz\/?p=719"},"modified":"2021-06-13T02:01:00","modified_gmt":"2021-06-13T02:01:00","slug":"setup-kubernetes-cluster-google-cloud","status":"publish","type":"post","link":"https:\/\/blog.ngocha.biz\/?p=719","title":{"rendered":"How To Configure and Setup Kubernetes Cluster On Google Cloud (GKE)"},"content":{"rendered":"

This guide walks you through deploying a Kubernetes Cluster on google cloud using the Google Kubernetes Engine (GKE).<\/p>\n

About Google Kubernetes Engine<\/h2>\n

Google cloud offers its own managed Kubernetes service called Google Kubernetes Engine, also know as GKE.<\/p>\n

Several companies use GKE for their production workload. One of the best examples would be hosting the PokemopnGo game on GKE<\/a>. In fact, it is the largest GKE deployment ever.<\/p>\n

Compared to other managed services like EKS (AWS) and AKS (Azure), GKE is relatively easy to set up and operate.<\/p>\n

In my container orchestration platform Post<\/a>, I have listed the difference between managed and self-hosted Kubernetes implementation. One main advantage of managed kubernetes clusters is the less administrative overhead.<\/p>\n

If you use GKE you can avoid the Kubernetes administrative overhead as it is taken care of by Google cloud. You just need to focus on deploying applications on Kubernetes.<\/p>\n

GKE has two types of clusters.<\/p>\n

    \n
  1. Autopilot Cluster:<\/strong> All cluster infrastructure operations are taken care of by Google cloud. You just have to focus on application deployments.<\/li>\n
  2. Standard Cluster<\/strong>: Here except for the control plane, you have to manage the underlying infrastructure (Nodes, scaling etc)<\/li>\n<\/ol>\n

    Following image shows the main difference between autopilot and standard GKE cluster.<\/p>\n

    \"difference<\/figure>\n

    In this blog, I will focus only on the Standard GKE cluster. To know more about GKE, there is no better place than the google cloud official GKE documentation<\/a><\/p>\n

    Create VPC With GKE Subnet & Secondary IP Ranges<\/h2>\n
    \n
    Note:<\/strong><\/b> Ensure you have the IAM admin permissions to create the network, GKE cluster, and associated components.<\/div>\n<\/div>\n

    You can create the GKE cluster in the default VPC provided by Google cloud. However, for learning and better understanding, lets create our own VPC.<\/p>\n

    Normally, when we deploy non-containerized workloads on VPC, we would just create subnets with primarry IP ranges.<\/p>\n

    When it comes to the GKE cluster, we need to create a subnet to host the cluster nodes, and secondary IP ranges under the subnet for the kubernetes pod and service network. In google cloud term; it is called VPC native clusters.<\/p>\n

    So, lets plan for nework for the following requirements.<\/p>\n

    <\/p>\n\n\n\n\n\n\n
    Cluster Requirements<\/strong><\/td>\nCalculated IP ranges<\/strong><\/td>\n<\/tr>\n
    The cluster should accommodate 200 Nodes. (Primary Subnet)<\/td>\nThis means we need a subnet with a minimum of 254 IP addresses<\/strong>. That is 10.0.1.0\/24<\/strong><\/code><\/td>\n<\/tr>\n
    Each node should accommodate 75 pods (Secondary range – Pod network)<\/td>\n200×75 = 15000 . So we will \/18 secondary range that would give 16384 IP addresses. 172.16.0.0\/18 (172.16.0.0 – 172.16.63.255<\/strong>)<\/td>\n<\/tr>\n
    The cluster should support 2000 services. Secondary range – Service network)<\/td>\nThis means we need a \/21 range for the service network. Assuming we continue from the pod range, it would be be 172.16.64.0\/20 (172.16.64.0 – 172.16.79.255<\/strong>)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    <\/p>\n

    Finally we have arrived to the following network ranges.<\/p>\n

      \n
    1. Primary subnet (For Cluster Nodes) – 10.0.1.0\/24<\/strong><\/li>\n
    2. Secondary network (For pods) – 172.16.0.0\/18<\/strong><\/li>\n
    3. Secondary network (For services) – 172.16.64.0\/20<\/strong><\/li>\n<\/ol>\n
      \"GKE<\/figure>\n

      So here is what we are going to do.<\/p>\n

        \n
      1. Create a VPC<\/li>\n
      2. Add a subnet with pod and service secondary range networks.<\/li>\n<\/ol>\n

        Now that we have finalized the network ranges let’s create a VPC network. I am calling network name as gke-network<\/code><\/p>\n

        gcloud compute networks create gke-network --subnet-mode=custom<\/code><\/pre>\n
        Create a subnet named gke-subnet-a <\/code> with two secondary ranges named pod-network <\/code>& service-network<\/code><\/p>\n
        gcloud compute networks subnets create gke-subnet-a \\\n    --network gke-network \\\n    --region us-central1 \\\n    --range 10.0.1.0\/24 \\\n    --secondary-range pod-network=172.16.0.0\/18,service-network=172.16.64.0\/20<\/code><\/pre>\n
        By default the subnet creates a routed to the internet gateway. So you dont have to do anything to enable internet access for the nodes.<\/p>\n
        However,  we need to add custom firewall rules to access the nodes from outside the VPC network.<\/p>\n
        \n
        Note: <\/strong><\/b>When running production workloads, careful consideration has been given to the network design by keeping the subnets fully private without internet gateways.<\/div>\n<\/div>\n
        Now we have the necessary network infrastructure to deploy a public GKE cluster.<\/p>\n
        Setting Up Kubernetes Cluster On Google Cloud<\/h2>\n
        \n
        Note:<\/strong><\/b> If you are looking for a self-hosted test\/POC kubernetes cluster setup on google cloud, you can use Kubeadm to quickly configure it. Refer to my Kubeadm cluster setup guide<\/a> for setting up one master node and multi worker node Kubernetes setup.<\/div>\n<\/div>\n
        There are two types of standard GKE cluster.<\/p>\n
          \n
        1. Public GKE cluster: <\/strong>Control plane node is publicly accessible, and all the worker nodes have a public interface attached to them. Here the cluster is secured using firewall rules and whitelisting only approved IP ranges to connect to the cluster API. This reduces the attack surface. The public clusters are normally not part of an organization’s hybrid network due to the fact that the nodes have a public interface.<\/li>\n
        2. Private GKE Cluster: <\/strong>The control plan and worker nodes get deployed in a predefined VPC network range defined by the user. The access to the cluster components will be completely private through VPC networks. Even though the control plane gets launched in the CIDR given by the user, that VPC gets created and managed by google cloud. We can only control the worker node subnets.<\/li>\n<\/ol>\n
          This tutorial will guide you through the steps for setting up a highly available multi-zone public kubernetes cluster.<\/p>\n
          Prerequitests<\/h3>\n
            \n
          1. You should have gcloud<\/code> configured from the machine you are trying to set up the cluster. Refer to google cloud SDK setup guide<\/a> to configure gcloud<\/li>\n
          2. If you are using google cloud servers, gcloud is available by default. You should have the admin service account attached to the server for provisioning GKE services.<\/li>\n<\/ol>\n
            GKE Cluster Creation Using gcloud CLI<\/h2>\n
            Step 1:<\/strong> We will use the gcloud CLI to launch a regional multi-zone cluster.<\/p>\n
            In our setup, we will be doing the following.<\/p>\n
              \n
            1. Spin up the cluster in us-central1<\/code> the region with one instance per zone (total three zones) using g1-small<\/code>(1.7GB) machine type with autoscaling enabled.<\/li>\n
            2. Preemptible VMs<\/strong> with autoscaling to a maximum of three-node per to reduce the cost of the cluster.<\/li>\n
            3. Cluster gets deployed with custom VPC, subnets & secondary ranges<\/strong> we created in the previous section.<\/li>\n
            4. Enable the master authorized network<\/strong> to allow only whitelisted IP ranges to connect to the master API. I have given 0.0.0.0\/0, you can replace this with your IP address.<\/li>\n
            5. Add a network tag named “webapps<\/code>” to add a custom firewall rule to the GKE cluster nodes for testing purposes.<\/li>\n<\/ol>\n
              \n
              Note<\/strong><\/b>: When deploying a cluster in production, more configurations need to be considered for the network and the cluster. It depends on the organizational policy and project requirements.<\/div>\n<\/div>\n
              Now, lets create the cluster using the following command.<\/p>\n
              gcloud container clusters create demo-gke \\\n      --region us-central1 \\\n      --no-enable-ip-alias \\\n      --node-locations us-central1-a,us-central1-b,us-central1-c \\\n      --num-nodes 1 \\\n      --enable-autoscaling \\\n      --min-nodes 1 \\\n      --max-nodes 3 \\\n      --node-labels=env=dev \\\n      --machine-type g1-small \\\n      --enable-autorepair  \\\n      --node-labels=type=webapps \\\n      --enable-vertical-pod-autoscaling \\\n      --preemptible \\\n      --disk-type pd-standard \\\n      --disk-size 50 \\\n      --enable-ip-alias \\\n      --network gke-network \\\n      --subnetwork gke-subnet-a \\\n      --cluster-secondary-range-name pod-network \\\n      --services-secondary-range-name service-network \\\n      --tags=webapp \\\n      --enable-master-authorized-networks \\\n      --master-authorized-networks=0.0.0.0\/0<\/code><\/pre>\n
              On a successful execution, you will see the cluster details in the output as shown below.<\/p>\n
              \"\"<\/figure>\n
              Also, you check the google kubernetes engine dashboard to view all the details about the cluster.<\/p>\n
              \"\"<\/figure>\n
              Step 2: <\/strong>You can get all the information about the  GKE cluster using the following command.<\/p>\n
              gcloud container clusters describe  demo-gke --region=us-central1<\/code><\/pre>\n
              Step 3: <\/strong>Now, we need to download the cluster kubeconfig<\/code> to our location workstation.<\/p>\n
              The following command generates the kubeconfig<\/code> and adds it to the ~\/.kube\/config<\/code> file.<\/p>\n
              gcloud container clusters get-credentials demo-gke  --region=us-central1<\/code><\/pre>\n
              You can also get the connect command from the GKE GUI.<\/p>\n
              gcloud Kubectl Component Installation<\/h2>\n
              Kubectl is a command-line utility for interacting with the kubernetes cluster. You can get more information about kubectl from here<\/a><\/p>\n
              If you already have kubectl<\/code> in your workstation, you can ignore this step.<\/p>\n
              To install kubectl component, execute the following gcloud command.<\/p>\n
              gcloud components install kubectl<\/code><\/pre>\n
              Now, you can get your cluster information using the kubectl command using the following command.<\/p>\n
              kubectl cluster-info<\/code><\/pre>\n
              The output would look like the following.<\/p>\n
              \"\"<\/figure>\n
              Deploy Nginx on GKE for Validation<\/h2>\n
              Let’s deploy a sample Nginx application in a custom namespace to validate the cluster.<\/p>\n
              Step 1:<\/strong> Create a namespace named demo<\/p>\n
              kubectl create namespace demo<\/code><\/pre>\n
              Step 2:<\/strong> Let’s deploy a sample Nginx app in the demo namespace. Also, create a Nodeport service for testing purposes.<\/p>\n
              Copy the following and execute directly on the terminal.<\/p>\n
              cat <<EOF | kubectl apply -f -\n---\napiVersion: apps\/v1\nkind: Deployment\nmetadata:\n  name: nginx-deployment\n  namespace: demo\nspec:\n  selector:\n    matchLabels:\n      app: nginx\n  replicas: 2 \n  template:\n    metadata:\n      labels:\n        app: nginx\n    spec:\n      containers:\n      - name: nginx\n        image: nginx:latest\n        ports:\n        - containerPort: 80\n---\napiVersion: v1\nkind: Service\nmetadata:\n  name: nginx-service\n  namespace: demo\nspec:\n  selector:\n    app: nginx\n  type: NodePort\n  ports:\n    - port: 80\n      targetPort: 80\n      nodePort: 32000\nEOF<\/code><\/pre>\n
              Lets check the deployment status.<\/p>\n
              kubectl get deployments -n demo<\/code><\/pre>\n
              Also lets describe the service and check the nodePort details.<\/p>\n
              kubectl describe svc nginx-service -n demo<\/code><\/pre>\n
              Step 3: <\/strong>Now to access the application on node port 32000<\/code>, you need to add an ingress firewall rule to allow traffic on port 32000 from the internet.<\/p>\n
              This rule is applicable for all instances with gke-webapps<\/code> tag in gke-network<\/code><\/p>\n
              gcloud compute firewall-rules create gke-webapps \\\n    --network=gke-network \\\n    --allow=tcp:32000 \\\n    --description=\"Allow incoming traffic on TCP port 32000\" \\\n    --direction=INGRESS \\\n    --source-ranges=\"0.0.0.0\/0\" \\\n    --target-tags=\"gke-webapps\"<\/code><\/pre>\n
              For demonstration purposes, I am adding 0.0.0.0\/0<\/code> as the source IP range. Meaning, allow traffic from anywhere on the internet.<\/p>\n
              You can get your public IP by a simple google search and add it as a source instead of 0.0.0.0\/0<\/code><\/p>\n
              For example, 53.45.78.32\/32 <\/code>as shown below.<\/p>\n
              \"get<\/figure>\n
              We deployed the cluster with a network tag named “gke-webapps<\/code>“. So we need to add a firewall rule that applies to the gke-webapps<\/code> tag. The rule gets applied to all the cluster instances as it has the gke-webapps<\/code> tag attached to it.<\/p>\n
              Step 5: <\/strong>Now that we have added the rule, lets try accessing the Nginx app using a nodes IP.<\/p>\n
              The following command will list all GKE nodes with their public IP address. Grab one IP and try accessing port 32000 and see if you can access the Nginx page.<\/p>\n
              gcloud compute instances list --filter=\"name~'gke-demo-*'\"<\/code><\/pre>\n
              \"GKE<\/figure>\n
              For example, http:\/\/35.224.101.80:32000\/<\/code><\/p>\n
              You should see the Nginx page.<\/p>\n
              \"GKE<\/figure>\n
              Expose Nginx as a Loadbalancer Service<\/h2>\n
              The same deployment can be exposed as a Loadbalancer by modifying the NodePort to Loadbalancer in the service file. GKE will create a Loadbancer that points to the Nginx service endpoint.<\/p>\n
              apiVersion: v1\nkind: Service\nmetadata:\n  name: nginx-service\n  namespace: demo\nspec:\n  selector:\n    app: nginx\n  type: LoadBalancer\n  ports:\n    - port: 80\n      targetPort: 80<\/code><\/pre>\n
              Accessing Kubernetes Objects From GKE Dashboard<\/h2>\n
              Kubernetes dashboard is not part of the default GKE setup. The dashboard addon is depricated.<\/p>\n
              However, there is a workload explorer in the Kubernetes engine dashboard. You can browse all the cluster objects from the dashboard.<\/p>\n
              I have recorded a small demo in the following gif file. Take a look.<\/p>\n
              \"Exploring<\/figure>\n
              GKE Cluster Logging & Monitoring<\/h2>\n
              By default GKE pushes all the logs to its Stackdriver logging and monitoring systems.<\/p>\n
              You can check the cluster logs from the Kubernetes engine dashboard.<\/p>\n
              \"\"<\/figure>\n
              From the monitoring dashboard you can create alerts based on the metrics generated from the cluster.<\/p>\n
              \n
              Note: <\/strong><\/b>When it comes to production level logging, organizations push the logs to central logging systems like Splunk through pub-sub. And tools like Prometheus are used to collect all the cluster resource metrics (Nodes, pods, etc.)<\/div>\n<\/div>\n
              Troubleshooting GKE Nodes<\/h2>\n
              If you use the default container optimized OS (COS) for the GKE cluster, there are only a limited utilities for troubleshooting the node issues.<\/p>\n
              Also, COS does  not come with any package manager.<\/p>\n
              However, GKE provides a command that deploys a container in which you can install the required utilities using from the apt<\/code> package manager.<\/p>\n
              Here is what you need to do. Login to a GKE node.<\/p>\n
              Execute the following command. It will automatically log in to a toolbox container with root privileges.<\/p>\n
              toolbox<\/code><\/pre>\n
              Then, you can install required troubleshooting utilities and carry on with the node troubleshooting.<\/p>\n
              Delete GKE Cluster<\/h2>\n
              If you want to delete the GKE cluster, use the following command.<\/p>\n
              gcloud container clusters delete demo-gke --region us-central1  --quiet<\/code><\/pre>\n
              Also, to remove the firewall rule, execute the following command.<\/p>\n
              gcloud compute firewall-rules delete gke-webapps --quiet<\/code><\/pre>\n
              Conclusion<\/h2>\n
              Setting up a Kubernetes cluster on google cloud is an easy task.<\/p>\n
              However, many configurations need to be considered for production setup from a security, scalability, and network standpoint.<\/p>\n
              Refer to the Kubernetes design consideration<\/a> blog for some standard design recommendations.<\/p>\n
              If you have any questions, let me know in the comments.<\/p>\n
              \n
              Ngu\u1ed3n:<\/strong> How To Configure and Setup Kubernetes Cluster On Google Cloud (GKE) \u2014 DevOpsCube<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
              Source: https:\/\/devopscube.com\/setup-kubernetes-cluster-google-cloud\/<\/p>\n","protected":false},"author":1,"featured_media":720,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-719","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-devops"],"_links":{"self":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts\/719","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=719"}],"version-history":[{"count":0,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts\/719\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/media\/720"}],"wp:attachment":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=719"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=719"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=719"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}