One place for hosting & domains

      Cluster

      How to Deploy a Linode Kubernetes Engine Cluster Using Terraform


      Updated by Linode Contributed by Linode

      What is the Linode Kubernetes Engine (LKE)?

      The Linode Kubernetes Engine (LKE) is a fully-managed container orchestration engine for deploying and managing containerized applications and workloads. LKE combines Linode’s ease of use and simple pricing with the infrastructure efficiency of Kubernetes. When you deploy a LKE cluster, you receive a Kubernetes Master at no additional cost; you only pay for the Linodes (worker nodes), NodeBalancers (load balancers), and Block Storage Volumes. Your LKE Cluster’s Master node runs the Kubernetes control plane processes – including the API, scheduler, and resource controllers.

      In this Guide

      This guide will walk you through the steps needed to deploy a Kubernetes cluster using LKE and the popular infrastructure as code (IaC) tool, Terraform. Throughout the guide you will:

      Before you Begin

      1. Create a personal access token for Linode’s API v4. Follow the Getting Started with the Linode API to get a token. You will need a token to be able to create Linode resources using Terraform.

        Note

        Ensure that your token has, at minimum, Read/Write permissions for Linodes, Kubernetes, NodeBalancers, and Volumes.

      2. Review the A Beginner’s Guide to Terraform to familiarize yourself with Terraform concepts if you have not used the tool before. This guide assumes familiarity with Terraform and its native HCL syntax.

      Prepare your Local Environment

      Install Terraform

      Install Terraform on your computer by following the Install Terraform section of our Use Terraform to Provision Linode Environments guide.

      Install kubectl

      macOS:

      Install via Homebrew:

      brew install kubernetes-cli
      

      If you don’t have Homebrew installed, visit the Homebrew home page for instructions. Alternatively, you can manually install the binary; visit the Kubernetes documentation for instructions.

      Linux:

      1. Download the latest kubectl release:

        curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl
        
      2. Make the downloaded file executable:

        chmod +x ./kubectl
        
      3. Move the command into your PATH:

        sudo mv ./kubectl /usr/local/bin/kubectl
        

      Note

      Windows:

      Visit the Kubernetes documentation for a link to the most recent Windows release.

      Create your Terraform Configuration Files

      In this section, you will create Terraform configuration files that define the resources needed to create a Kubernetes cluster. You will create a main.tf file to store your resource declarations, a variables.tf file to store your input variable definitions, and a terraform.tfvars file to assign values to your input variables. Setting up your Terraform project in this way will allow you to reuse your configuration files to deploy more Kubernetes clusters, if desired.

      Create your Resource Configuration File

      Terraform defines the elements of your Linode infrastructure inside of configuration files. Terraform refers to these infrastructure elements as resources. Once you declare your Terraform configuration, you then apply it, which results in the creation of those resources on the Linode platform. The Linode Provider for Terraform exposes the Linode resources you will need to deploy a Kubernetes cluster using LKE.

      1. Navigate to the directory where you installed Terraform. Replace ~/terraform with the location of your installation.

        cd ~/terraform
        
      2. Create a new directory to store your LKE cluster’s Terraform configurations. Replace lke-cluster with your preferred directory name.

        mkdir lke-cluster
        
      3. Using the text editor of your choice, create your cluster’s main configuration file named main.tf which will store your resource definitions. Add the following contents to the file.

        ~/terraform/lke-cluster/main.tf
         1
         2
         3
         4
         5
         6
         7
         8
         9
        10
        11
        12
        13
        14
        15
        16
        17
        18
        19
        20
        21
        22
        23
        24
        25
        26
        27
        28
        29
        30
        31
        32
        33
        34
        35
        36
        37
        38
        39
        40
        41
        42
        43
        
        //Use the Linode Provider
        provider "linode" {
          token = var.token
        }
        
        //Use the linode_lke_cluster resource to create
        //a Kubernetes cluster
        resource "linode_lke_cluster" "foobar" {
            k8s_version = var.k8s_version
            label = var.label
            region = var.region
            tags = var.tags
        
            dynamic "pool" {
                for_each = var.pools
                content {
                    type  = pool.value["type"]
                    count = pool.value["count"]
                }
            }
        }
        
        //Export this cluster's attributes
        output "kubeconfig" {
           value = linode_lke_cluster.foobar.kubeconfig
        }
        
        output "api_endpoints" {
           value = linode_lke_cluster.foobar.api_endpoints
        }
        
        output "status" {
           value = linode_lke_cluster.foobar.status
        }
        
        output "id" {
           value = linode_lke_cluster.foobar.id
        }
        
        output "pool" {
           value = linode_lke_cluster.foobar.pool
        }
            

        This file contains your cluster’s main configuration arguments and output variables. In this example, you make use of Terraform’s input variables so that your main.tf configuration can be easily reused across different clusters.

        Variables and their values will be created in separate files later on in this guide. Using separate files for variable declaration allows you to avoid hard-coding values into your resources. This strategy can help you reuse, share, and version control your Terraform configurations.

        This configuration file uses the Linode provider to create a Kubernetes cluster. All arguments within the linode_lke_cluster.foobar resource are required, except for tags. The pool argument accepts a list of pool objects. In order to read their input variable values, the configuration file makes use of Terraform’s dynamic blocks. Finally, output values are declared in order to capture your cluster’s attribute values that will be returned to Terraform after creating your cluster.

        Note

        For a complete linode_lke_cluster resource argument reference, see the Linode Provider Terraform documentation. You can update the main.tf file to include any additional arguments you would like to use.

      Define your Input Variables

      You are now ready to define the input variables that were referenced in your main.tf file.

      1. Create a new file named variables.tf in the same directory as your main.tf file. Add the following contents to the file:

        ~/terraform/lke-cluster/variables.tf
         1
         2
         3
         4
         5
         6
         7
         8
         9
        10
        11
        12
        13
        14
        15
        16
        17
        18
        19
        20
        21
        22
        23
        24
        25
        26
        27
        28
        29
        30
        31
        32
        33
        34
        35
        36
        37
        38
        39
        40
        41
        42
        43
        
            variable "token" {
              description = "Your Linode API Personal Access Token.(required)."
            }
        
            variable "k8s_version" {
              description = "The Kubernetes version to use for this cluster.(required)"
              default = "1.17"
            }
        
            variable "label" {
              description = "The unique label to assign to this cluster.(required)"
              default = "default-lke-cluster"
            }
        
            variable "region" {
              description = "The region where your cluster will be located.(required)"
              default = "us-east"
            }
        
            variable "tags" {
              description = "Tags to apply to your cluster for organizational purposes.(optional)"
              type = list(string)
              default = ["testing"]
            }
        
            variable "pools" {
              description = "The Node Pool specifications for the Kubernetes cluster.(required)"
              type = list(object({
                type = string
                count = number
              }))
              default = [
                {
                  type = "g6-standard-4"
                  count = 3
                },
                {
                  type = "g6-standard-8"
                  count = 3
                }
              ]
            }
            

        This file describes each variable and provides them with default values. You can update the file with your own preferred default values.

      Assign Values to your Input Variables

      You will now need to define the values you would like to use in order to create your Kubernetes cluster. These values are stored in a separate file named terraform.tfvars. This file should be the only file that requires updating when reusing the files created in this guide to deploy a new Kubernetes cluster or to add a new node pool to the cluster.

      1. Create a new file named terraform.tfvars to provide values for all the input variables declared in the previous section.

        Note

        If you leave out a variable value in this file, Terraform will use the variable’s default value that you provided in your variables.tf file.

        $~/terraform/lke-cluster/terraform.tfvars
         1
         2
         3
         4
         5
         6
         7
         8
         9
        10
        
        label = "example-lke-cluster"
        k8s_version = "1.17"
        region = "us-west"
        pools = [
          {
            type : "g6-standard-2"
            count : 3
          }
        ]
              

        Terraform will use the values in this file to create a new Kubernetes cluster with one node pool that contains three 4 GB nodes. The cluster will be located in the us-west data center (Dallas, Texas, USA). Each node in the cluster’s node pool will use Kubernetes version 1.17 and the cluster will be named example-lke-cluster. You can replace any of the values in this file with your own preferred cluster configurations.

      Deploy your Kubernetes Cluster

      Now that all your Terraform configuration files are ready, you can deploy your Kubernetes cluster.

      1. Ensure that you are in your lke-cluster project directory which should contain all of your Terraform configuration files. If you followed the naming conventions used in this guide, your project directory will be ~/terraform/lke-cluster.

        cd ~/terraform/lke-cluster
        
      2. Install the Linode Provider to your Terraform project directory. Whenever a new provider is used in a Terraform configuration, it must be initialized before you can create resources with it.

        terraform init
        

        You will see a message that confirms that the Linode provider plugins have been successfully initialized.

      3. Export your API token to an environment variable. Terraform environment variables have the prefix TF_VAR_ and are supplied at the command line. This method is preferable over storing your token in a plain text file. Replace the example’s token value with your own.

        export TF_VAR_token=70a1416a9.....d182041e1c6bd2c40eebd
        

        Caution

        This method commits the environment variable to your shell’s history, so take care when using this method.

      4. View your Terraform’s execution plan before deploying your infrastructure. This command won’t take any actions or make any changes on your Linode account. It will provide a report displaying all the resources that will be created or modified when the plan is executed.

        terraform plan 
        -var-file="terraform.tfvars"
        
      5. Apply your Terraform configurations to deploy your Kubernetes cluster.

        terraform apply 
        -var-file="terraform.tfvars"
        

        Terraform will begin to create the resources you’ve defined throughout this guide. This process will take several minutes to complete. Once the cluster has been successfully created the output will include a success message and the values that you exposed as output when creating your main.tf file (the example output has been truncated for brevity).

          
        Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
        
        Outputs:
        
        api_endpoints = [
          "https://91132f3d-fd20-4a70-a171-06ddec5d9c4d.us-west-2.linodelke.net:443",
          "https://91132f3d-fd20-4a70-a171-06ddec5d9c4d.us-west-2.linodelke.net:6443",
          "https://192.0.2.0:443",
          "https://192.0.2.0:6443",
        ]
        ...
                  
        

      Connect to your LKE Cluster

      Now that your Kubernetes cluster is deployed, you can use kubectl to connect to it and begin defining your workload. In this section, you will access your cluster’s kubeconfig and use it to connect to your cluster with kubectl.

      1. Use Terraform to access your cluster’s kubeconfig, decode its contents, and save them to a file. Terraform returns a base64 encoded string (a useful format for automated pipelines) representing your kubeconfig. Replace lke-cluster-config.yaml with your preferred file name.

        export KUBE_VAR=`terraform output kubeconfig` && echo $KUBE_VAR | base64 -D > lke-cluster-config.yaml
        

        Note

        Depending on your local operating system, to decode the kubeconfig’s base64 format, you may need to replace base64 -D with base64 -d. For example, this is update is needed on an Ubuntu 18.04 system.

      2. Add the kubeconfig file to your $KUBECONFIG environment variable. This will give kubectl access to your cluster’s kubeconfig file.

        export KUBECONFIG=lke-cluster-config.yaml
        
      3. Verify that your cluster is selected as kubectl’s current context:

        kubectl config get-contexts
        
      4. View all nodes in your Kubernetes cluster using kubectl:

        kubectl get nodes
        

        Your output will resemble the following example, but will vary depending on your own cluster’s configurations.

          
        NAME                        STATUS   ROLES    AGE   VERSION
        lke4377-5673-5eb331ac7f89   Ready       17h   v1.17.0
        lke4377-5673-5eb331acab1d   Ready       17h   v1.17.0
        lke4377-5673-5eb331acd6c2   Ready       17h   v1.17.0
            
        

        Now that you are connected to your LKE cluster, you can begin using kubectl to deploy applications, inspect and manage cluster resources, and view logs.

      Destroy your Kubernetes Cluster (optional)

      Terraform includes a destroy command to remove resources managed by Terraform.

      1. Run the plan command with the -destroy option to verify which resources will be destroyed.

        terraform plan -destroy
        

        Follow the prompt to enter your Linode API v4 access token and review the report to ensure the resources you expect to be destroyed are listed.

      2. Destroy the resources outlined in the above command.

        terraform destroy
        

        Follow the prompt to enter your Linode API v4 access token and type in yes when prompted to destroy your Kubernetes cluster.

      More Information

      You may wish to consult the following resources for additional information on this topic. While these are provided in the hope that they will be useful, please note that we cannot vouch for the accuracy or timeliness of externally hosted materials.

      This guide is published under a CC BY-ND 4.0 license.



      Source link

      Étapes recommandées pour la mise en place d’un cluster DigitalOcean Kubernetes


      L’auteur a choisi Open Sourcing Mental Illness pour recevoir un don dans le cadre du programme Write for DOnations.

      Introduction

      Kubernetes, la plateforme open-source d’orchestration de conteneurs, devient progressivement la solution privilégiée pour l’automatisation, la mise à l’échelle et la gestion des clusters à haute disponibilité. En raison de sa popularité croissante, la sécurité de Kubernetes est devenue de plus en plus pertinente.

      Compte tenu des pièces mobiles impliquées dans Kubernetes et de la variété des scénarios de déploiement, la sécurisation de Kubernetes peut parfois être complexe. Pour cette raison, l’objectif de cet article est de fournir une base de sécurité solide pour un cluster DigitalOcean Kubernetes (DOKS). Veuillez noter que ce tutoriel couvre les mesures de sécurité de base pour Kubernetes, et se veut un point de départ plutôt qu’un guide exhaustif. Pour les étapes supplémentaires, voir la documentation officielle de Kubernetes.

      Dans ce guide, vous prendrez les mesures de base pour sécuriser votre cluster Kubernetes DigitalOcean. Vous devrez configurer une authentification locale sécurisée avec des certificats TLS/SSL, accorder des autorisations aux utilisateurs locaux avec des contrôles d’accès basés sur les rôles (RBAC), accorder des autorisations aux applications Kubernetes et aux déploiements avec des comptes de service, et définir des limites de ressources avec les contrôleurs d’admission ResourceQuota et LimitRange.

      Conditions préalables

      Pour pouvoir compléter ce tutoriel, vous aurez besoin de :

      Étape 1 – Activation de l’authentification des utilisateurs à distance

      Après avoir rempli les conditions préalables, vous vous retrouverez avec un super-utilisateur Kubernetes qui s’authentifiera grâce à un jeton du porteur DigitalOcean prédéfini. Toutefois, le partage de ces identifiants n’est pas une bonne pratique de sécurité, car ce compte peut entraîner des modifications à grande échelle et éventuellement destructrices de votre cluster. Pour limiter cette possibilité, vous pouvez configurer des utilisateurs supplémentaires à authentifier à partir de leurs clients locaux respectifs.

      Dans cette section, vous allez authentifier les nouveaux utilisateurs du cluster DOKS distant à partir de clients locaux en utilisant des certificats SSL/TLS sécurisés. Il s’agira d’un processus en trois étapes : Tout d’abord, vous allez créer des demandes de signature de certificats (CSR) pour chaque utilisateur, puis vous approuverez ces certificats directement dans le cluster par l’intermédiaire de kubectl. Enfin, vous construirez pour chaque utilisateur un fichier kubeconfig avec les certificats appropriés. Pour plus d’informations sur les méthodes d’authentification supplémentaires prises en charge par Kubernetes, consultez la documentation sur l’authentification Kubernetes.

      Création de demandes de signature de certificats pour les nouveaux utilisateurs

      Avant de commencer, vérifiez la connexion au cluster DOKS depuis la machine locale configurée lors des prérequis :

      En fonction de votre configuration, la sortie sera similaire à celle-ci :

      Output

      Kubernetes master is running at https://a6616782-5b7f-4381-9c0f-91d6004217c7.k8s.ondigitalocean.com CoreDNS is running at https://a6616782-5b7f-4381-9c0f-91d6004217c7.k8s.ondigitalocean.com/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

      Cela signifie que vous êtes connecté au cluster DOKS.

      Ensuite, créez un dossier local pour les certificats des clients. Pour les besoins de ce guide,~/certs seront utilisés pour stocker tous les certificats :

      Dans ce tutoriel, nous allons autoriser un nouvel utilisateur appelé sammy à accéder au cluster.  N’hésitez pas à modifier cela pour un utilisateur de votre choix. En utilisant la bibliothèque SSL et TLS OpenSSL, générez une nouvelle clé privée pour votre utilisateur en utilisant la commande suivante :

      • openssl genrsa -out ~/certs/sammy.key 4096

      Le drapeau -out rendra le fichier de sortie ~/certs/sammy.key, et 4096 définit la clé comme 4096-bit. Pour plus d’informations sur OpenSSL, consultez notre guide Les essentiels d’OpenSSL.

      Maintenant, créez un fichier de configuration de la demande de signature de certificat. Ouvrez le fichier suivant avec un éditeur de texte (pour ce tutoriel, nous utiliserons nano) :

      • nano ~/certs/sammy.csr.cnf

      Ajoutez le contenu suivant dans le fichier sammy.csr.cnf pour spécifier dans le sujet le nom d’utilisateur souhaité comme nom commun (CN), et le groupe comme organisation (O) :

      ~/certs/sammy.csr.cnf

      [ req ]
      default_bits = 2048
      prompt = no
      default_md = sha256
      distinguished_name = dn
      [ dn ]
      CN = sammy
      O = developers
      [ v3_ext ]
      authorityKeyIdentifier=keyid,issuer:always
      basicConstraints=CA:FALSE
      keyUsage=keyEncipherment,dataEncipherment
      extendedKeyUsage=serverAuth,clientAuth
      

      Le fichier de configuration de la demande de signature de certificat contient toutes les informations nécessaires, l’identité de l’utilisateur et les paramètres d’utilisation appropriés pour l’utilisateur. Le dernier argument extendedKeyUsage=serverAuth,clientAuth permettra aux utilisateurs d’authentifier leurs clients locaux avec le cluster DOKS en utilisant le certificat une fois qu’il sera signé.

      Ensuite, créez la demande de signature du certificat sammy :

      • openssl req -config ~/certs/sammy.csr.cnf -new -key ~/certs/sammy.key -nodes -out ~/certs/sammy.csr

      Le paramètre -config vous permet de spécifier le fichier de configuration pour le CSR, et -new signale que vous créez une nouvelle CSR pour la clé spécifiée par -key.

      Vous pouvez vérifier votre demande de signature de certificat en exécutant la commande suivante :

      • openssl req -in ~/certs/sammy.csr -noout -text

      Ici vous passez dans le CSR avec -in et utilisez -text pour imprimer la demande de certificat en texte.

      La sortie montrera la demande de certificat, dont le début ressemblera à ceci :

      Output

      Certificate Request: Data: Version: 1 (0x0) Subject: CN = sammy, O = developers Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public-Key: (4096 bit) ...

      Répétez la même procédure pour créer des RSC pour tout utilisateur supplémentaire. Une fois que vous avez enregistré toutes les demandes de signature de certificats dans le dossier ~/certs de l’administrateur, passez à l’étape suivante pour les approuver.

      Gérer les demandes de signature de certificats avec l’API Kubernetes

      Vous pouvez soit approuver soit refuser les certificats TLS délivrés à l’API Kubernetes en utilisant l’outil de ligne de commande kubectl. Cela vous donne la possibilité de vous assurer que l’accès demandé est approprié pour l’utilisateur donné. Dans cette section, vous enverrez la demande de certificat pour sammy et l’approuverez.

      Pour envoyer une CSR au cluster DOKS, utilisez la commande suivante cluster

      cat <<EOF | kubectl apply -f -
      apiVersion: certificates.k8s.io/v1beta1
      kind: CertificateSigningRequest
      metadata:
        name: sammy-authentication
      spec:
        groups:
        - system:authenticated
        request: $(cat ~/certs/sammy.csr | base64 | tr -d 'n')
        usages:
        - digital signature
        - key encipherment
        - server auth
        - client auth
      EOF
      

      En utilisant un document Bash here, cette commande utilise cat pour transmettre la demande de certificat à kubectl apply.

      Examinons de plus près la demande de certificat :

      • nom : sammy-authentication crée un identificateur de métadonnées, dans ce cas appelé sammy-authentication.
      • request : $(cat ~/certs/sammy.csr | base64 | tr -d 'n') envoie la demande de signature du certificat sammy.csr au cluster encodé en Base64.
      • L'autorisation du serveur et l'autorisation du client précisent l’utilisation prévue du certificat. Dans ce cas, l’objectif est l’authentification de l’utilisateur.

      Le résultat sera similaire à celui-ci :

      Output

      certificatesigningrequest.certificates.k8s.io/sammy-authentication created

      Vous pouvez vérifier le statut de la demande de signature de certificat en utilisant la commande :

      Selon la configuration de votre cluster, le résultat sera similaire à celui-ci :

      Output

      NAME AGE REQUESTOR CONDITION sammy-authentication 37s your_DO_email Pending

      Ensuite, approuvez la CSR en utilisant la commande CSR

      • kubectl certificate approve sammy-authentication

      Vous recevrez un message confirmant l’opération :

      Output

      certificatesigningrequest.certificates.k8s.io/sammy-authentication approved

      Remarque : En tant qu’administrateur, vous pouvez également refuser une CSR en utilisant la commande kubectl certificate deny sammy-authentication. Pour plus d’informations sur la gestion des certificats TLS, veuillez lire la documentation officielle de Kubernetes.

      Maintenant que la RSE est approuvée, vous pouvez la télécharger sur la machine locale en exécutant :

      • kubectl get csr sammy-authentication -o jsonpath='{.status.certificate}' | base64 --decode > ~/certs/sammy.crt

      Cette commande décode le certificat Base64 pour une utilisation correcte par kubectl, puis l’enregistre sous la forme ~/certs/sammy.crt.

      Avec le certificat signé sammy en main, vous pouvez maintenant construire le fichier kubeconfig de l’utilisateur.

      Construire des utilisateurs distants Kubeconfig

      Ensuite, vous allez créer un fichier kubeconfig spécifique pour l’utilisateur sammy. Cela vous permettra de mieux contrôler l’accès de l’utilisateur à votre cluster.

      La première étape de la construction d’un nouveau kubeconfig consiste à faire une copie du fichier kubeconfig actuel. Pour les besoins de ce guide, le nouveau fichier kubeconfig s’appelleraconfig-sammy :

      • cp ~/.kube/config ~/.kube/config-sammy

      Ensuite, modifiez le nouveau fichier :

      • nano ~/.kube/config-sammy

      Conservez les huit premières lignes de ce fichier, car elles contiennent les informations nécessaires à la connexion SSL/TLS avec le cluster. Ensuite, en partant du paramètre utilisateur, remplacez le texte par les lignes surlignées suivantes afin que le fichier ressemble à ce qui suit :

      config-sammy

      apiVersion: v1
      clusters:
      - cluster:
          certificate-authority-data: certificate_data
        name: do-nyc1-do-cluster
      contexts:
      - context:
          cluster: do-nyc1-do-cluster
          user: sammy
        name: do-nyc1-do-cluster
      current-context: do-nyc1-do-cluster
      kind: Config
      preferences: {}
      users:
      - name: sammy
        user:
          client-certificate: /home/your_local_user/certs/sammy.crt
          client-key: /home/your_local_user/certs/sammy.key
      

      Remarque : pour le certificat-client et la clé-client, utilisez le chemin d’accès absolu à l’emplacement du certificat correspondant. Dans le cas contraire, kubectl produira une erreur.

      Enregistrez et quittez le fichier.

      Vous pouvez tester la connexion du nouvel utilisateur en utilisant kubectl cluster-info :

      • kubectl --kubeconfig=/home/your_local_user/.kube/config-sammy cluster-info

      Vous verrez une erreur similaire à celle-ci :

      Output

      To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'. Error from server (Forbidden): services is forbidden: User "sammy" cannot list resource "services" in API group "" in the namespace "kube-system"

      Cette erreur est attendue car l’utilisateur sammy n’a pas encore l’autorisation de lister une ressource sur le cluster. L’octroi d’autorisations aux utilisateurs sera abordé dans la prochaine étape. Pour l’instant, le résultat confirme que la connexion SSL/TLS a réussi et que l’API Kubernetes a accepté les références d’authentification sammy.

      Étape 2 – Autorisation des utilisateurs par le biais du contrôle d’accès basé sur les rôles (RBAC)

      Une fois qu’un utilisateur est authentifié, l’API détermine ses autorisations en utilisant le modèle de contrôle d’accès basé sur les rôles (RBAC) intégré à Kubernetes. Le RBAC est une méthode efficace pour restreindre les droits des utilisateurs en fonction du rôle qui leur est attribué. Du point de vue de la sécurité, le RBAC permet de définir des autorisations précises pour limiter l’accès des utilisateurs à des données sensibles ou l’exécution de commandes au niveau du super-utilisateur. Pour des informations plus détaillées sur les rôles des utilisateurs, veuillez consulter la documentation relative à Kubernetes RBAC.

      Dans cette étape, vous utiliserez kubectl pour attribuer le rôle d’édition prédéfini à l’utilisateur sammy dans l’espace de noms par défaut. Dans un environnement de production, vous souhaiterez peut-être utiliser des rôles personnalisés et/ou des liens de rôles personnalisés.

      Accorder des autorisations

      Dans Kubernetes, accorder des autorisations signifie attribuer le rôle souhaité à un utilisateur. Attribuez des droits d'édition à l’utilisateur sammy dans l’espace de noms par défaut en utilisant la commande suivante :

      • kubectl create rolebinding sammy-edit-role --clusterrole=edit --user=sammy --namespace=default

      Cela donnera un résultat similaire à ce qui suit :

      Output

      rolebinding.rbac.authorization.k8s.io/sammy-edit-role created

      Analysons cette commande plus en détail :

      • créer une liaison de rôle sammy-edit-role crée une nouvelle liaison de rôle, dans ce cas appelée sammy-edit-role.
      • --clusterrole=edit attribue le rôle prédéfini d'édition à une portée globale (rôle de cluster).
      • --user=sammy spécifie à quel utilisateur lier le rôle.
      • --namespace=default accorde à l’utilisateur des autorisations de rôle dans l’espace de noms spécifié, dans ce cas par défaut.

      Ensuite, vérifiez les autorisations des utilisateurs en listant les pods dans l’espace de noms par défaut. Vous pouvez savoir si l’autorisation RBAC fonctionne comme prévu si aucune erreur n’est affichée.

      • kubectl --kubeconfig=/home/your_local_user/.kube/config-sammy auth can-i get pods

      Vous aurez le résultat suivant :

      Output

      yes

      Maintenant que vous avez attribué des autorisations à sammy, vous pouvez vous entraîner à les révoquer dans la section suivante.

      Révoquer les autorisations

      La révocation des autorisations dans Kubernetes se fait en supprimant le rôle obligatoire de l’utilisateur.

      Pour ce tutoriel, supprimez le rôle d'édition de l’utilisateur sammy en exécutant la commande suivante :

      • kubectl delete rolebinding sammy-edit-role

      Vous aurez le résultat suivant :

      Output

      rolebinding.rbac.authorization.k8s.io "sammy-edit-role" deleted

      Vérifiez si les autorisations des utilisateurs ont été révoquées comme prévu en listant les pods d’espace de noms par défaut :

      • kubectl --kubeconfig=/home/localuser/.kube/config-sammy --namespace=default get pods

      Vous recevrez l’erreur suivante :

      Output

      Error from server (Forbidden): pods is forbidden: User "sammy" cannot list resource "pods" in API group "" in the namespace "default"

      Cela montre que l’autorisation a été révoquée.

      Du point de vue de la sécurité, le modèle d’autorisation Kubernetes donne aux administrateurs de clusters la flexibilité nécessaire pour modifier les droits des utilisateurs à la demande. De plus, le contrôle d’accès basé sur les rôles n’est pas limité à un utilisateur physique ; vous pouvez également accorder et retirer des autorisations aux services de cluster, comme vous l’apprendrez dans la section suivante.

      Pour plus d’informations sur l’autorisation RBAC et sur la manière de créer des rôles personnalisés, veuillez lire la documentation officielle.

      Étape 3 – Gestion des autorisations de demande à l’aide de comptes de service

      Comme mentionné dans la section précédente, les mécanismes d’autorisation du RBAC s’étendent au-delà des utilisateurs humains. Les utilisateurs de clusters non humains, tels que les applications, services et processus s’exécutant à l’intérieur des pods, s’authentifient auprès du serveur API en utilisant ce que Kubernetes appelle des comptes de service. Lorsqu’un pod est créé dans un espace de noms, vous pouvez soit le laisser utiliser le compte de service par défaut, soit définir un compte de service de votre choix. La possibilité d’affecter des SAS individuels aux demandes et aux processus donne aux administrateurs la liberté d’accorder ou de révoquer des autorisations selon les besoins. En outre, l’affectation de SAS spécifiques à des applications critiques pour la production est considérée comme une meilleure pratique de sécurité. Comme les comptes de service sont utilisés pour l’authentification, et donc pour les contrôles d’autorisation RBAC, les administrateurs de clusters pourraient contenir les menaces de sécurité en modifiant les droits d’accès aux comptes de service et en isolant le processus incriminé.

      Pour démontrer les comptes de service, ce tutoriel utilisera un serveur web Nginx comme exemple d’application.

      Avant d’attribuer une SA particulière à votre application, vous devez créer la SA. Créez un nouveau compte de service appelé nginx-sa dans l’espace de noms par défaut :

      • kubectl create sa nginx-sa

      Vous obtiendrez :

      Output

      serviceaccount/nginx-sa created

      Vérifiez que le compte de service a été créé en exécutant ce qui suit :

      Vous obtiendrez ainsi une liste de vos comptes de service :

      Output

      NAME SECRETS AGE default 1 22h nginx-sa 1 80s

      Vous allez maintenant attribuer un rôle au compte de service nginx-sa. Pour cet exemple, accordez nginx-sa les mêmes permissions que l’utilisateur sammy :

      • kubectl create rolebinding nginx-sa-edit
      • --clusterrole=edit
      • --serviceaccount=default:nginx-sa
      • --namespace=default

      L’exécution de cette opération donnera les résultats suivants :

      Output

      rolebinding.rbac.authorization.k8s.io/nginx-sa-edit created

      Cette commande utilise le même format que pour l’utilisateur sammy, à l’exception du drapeau --serviceaccount=default:nginx-sa, où vous attribuez le compte de service nginx-sa dans l’espace de noms par défaut.

      Vérifiez que la liaison de rôle a réussi à l’aide de cette commande :

      Cela donnera le résultat suivant :

      Output

      NAME AGE nginx-sa-edit 23s

      Une fois que vous avez confirmé que le rôle obligatoire pour le compte de service a été configuré avec succès, vous pouvez affecter le compte de service à une application. L’attribution d’un compte de service particulier à une application vous permettra de gérer ses droits d’accès en temps réel et donc de renforcer la sécurité du cluster.

      Pour les besoins de ce tutoriel, un pod nginx servira d’exemple d’application. Créez le nouveau pod et spécifiez le compte de service nginx-sa avec la commande suivante :

      • kubectl run nginx --image=nginx --port 80 --serviceaccount="nginx-sa"

      La première partie de la commande crée un nouveau pod faisant tourner un serveur web nginx sur le port :80, et la dernière partie --serviceaccount="nginx-sa" indique que ce pod doit utiliser le compte de service nginx-sa et non le SA par défaut.

      Vous obtiendrez ainsi un résultat similaire à celui qui suit :

      Output

      deployment.apps/nginx created

      Vérifiez que la nouvelle demande utilise le compte de service en utilisant kubectl describe : 

      • kubectl describe deployment nginx

      Cela donnera lieu à une longue description des paramètres de déploiement. Sous la section Modèle de Pod, vous verrez un résultat similaire à celui-ci :

      Output

      ... Pod Template: Labels: run=nginx Service Account: nginx-sa ...

      Dans cette section, vous avez créé le compte de service nginx-sa dans l’espace de noms par défaut et l’avez attribué au serveur web nginx. Vous pouvez désormais contrôler les autorisations de nginx en temps réel en modifiant son rôle si besoin est. Vous pouvez également regrouper les demandes en attribuant le même compte de service à chacune d’entre elles, puis apporter des modifications en masse aux autorisations. Enfin, vous pourriez isoler les applications critiques en leur attribuant un SA unique.

      En résumé, l’idée qui sous-tend l’attribution des rôles à vos applications/déploiements est d’affiner les autorisations. Dans les environnements de production du monde réel, vous pouvez avoir plusieurs déploiements nécessitant différentes autorisations allant de la lecture seule à des privilèges administratifs complets. L’utilisation du RBAC vous donne la possibilité de restreindre l’accès au cluster selon vos besoins.

      Ensuite, vous mettrez en place des contrôleurs d’admission pour contrôler les ressources et se prémunir contre les attaques de privation de ressources.

      Étape 4 – Mise en place des contrôleurs d’admission

      Les contrôleurs d’admission Kubernetes sont des plug-ins optionnels qui sont compilés dans le binaire kube-apiserver pour élargir les options de sécurité. Les contrôleurs d’admission interceptent les demandes après qu’elles aient passé la phase d’authentification et d’autorisation. Une fois que la demande est interceptée, les contrôleurs d’admission exécutent le code spécifié juste avant que la demande ne soit appliquée.

      Si le résultat d’un contrôle d’authentification ou d’autorisation est un booléen qui autorise ou refuse la demande, les contrôleurs d’admission peuvent être beaucoup plus divers. Les contrôleurs d’admission peuvent valider les demandes de la même manière que l’authentification, mais ils peuvent également faire muter ou modifier les demandes et modifier les objets avant de les admettre.

      Dans cette étape, vous utiliserez les contrôleurs d’admission ResourceQuota et LimitRange pour protéger votre cluster en faisant muter les demandes qui pourraient contribuer à une pénurie de ressources ou à une attaque par déni de service. Le contrôleur d’admission ResourceQuota permet aux administrateurs de restreindre les ressources informatiques, les ressources de stockage et la quantité de tout objet dans un espace de noms, tandis que le contrôleur d’admission LimitRange limitera le nombre de ressources utilisées par les conteneurs. En utilisant ces deux contrôleurs d’admission ensemble, vous protégerez votre cluster contre les attaques qui rendent vos ressources indisponibles.

      Pour montrer comment fonctionne ResourceQuota, vous allez mettre en place quelques restrictions dans l’espace de noms par défaut. Commencez par créer un nouveau fichier objet ResourceQuota :

      • nano resource-quota-default.yaml

      Ajoutez la définition d’objet suivante pour définir les contraintes de consommation de ressources dans l’espace de noms par défaut. Vous pouvez ajuster les valeurs selon les besoins en fonction des ressources physiques de vos nœuds :

      resource-quota-default.yaml

      apiVersion: v1
      kind: ResourceQuota
      metadata:
        name: resource-quota-default
      spec:
        hard:
          pods: "2"
          requests.cpu: "500m"
          requests.memory: 1Gi
          limits.cpu: "1000m"
          limits.memory: 2Gi
          configmaps: "5"
          persistentvolumeclaims: "2"
          replicationcontrollers: "10"
          secrets: "3"
          services: "4"
          services.loadbalancers: "2"
      

      Cette définition utilise le mot-clé hard pour fixer des contraintes strictes, telles que le nombre maximum de pods, les configmaps, les PersistentVolumeClaims, les ReplicationController, les secrets, les services et les loadbalancers. Cela impose également des contraintes en matière de ressources informatiques, par exemple :

      • requests.cpu, qui fixe la valeur CPU maximale des requêtes en milliCPU, soit un millième d’un noyau CPU.
      • requests.memory, qui fixe la valeur maximale de la mémoire des requêtes en octets.
      • limits.cpu, qui fixe la valeur CPU maximale des limites en milliCPU.
      • limits.memory, qui fixe la valeur maximale de la mémoire des limites en octets.

      Enregistrez et quittez le fichier.

      Maintenant, créez l’objet dans l’espace de noms en exécutant la commande suivante :

      • kubectl create -f resource-quota-default.yaml --namespace=default

      Il en résultera ce qui suit :

      Output

      resourcequota/resource-quota-default created

      Notez que vous utilisez le drapeau -f pour indiquer à Kubernetes l’emplacement du fichier ResourceQuota et le drapeau --namespace pour préciser quel espace de noms sera mis à jour.

      Une fois l’objet créé, votre ResourceQuota sera actif. Vous pouvez vérifier les quotas d’espace de noms par défaut avec le quota de description :

      • kubectl describe quota --namespace=default

      La sortie sera similaire à celle-ci, avec les limites strictes que vous avez définies dans le fichier resource-quota-default.yaml :

      Output

      Name: resource-quota-default Namespace: default Resource Used Hard -------- ---- ---- configmaps 0 5 limits.cpu 0 1 limits.memory 0 2Gi persistentvolumeclaims 0 2 pods 1 2 replicationcontrollers 0 10 requests.cpu 0 500m requests.memory 0 1Gi secrets 2 3 services 1 4 services.loadbalancers 0 2

      Les quotas de ressources sont exprimés en unités absolues, de sorte que l’ajout de nœuds supplémentaires n’augmentera pas automatiquement les valeurs définies ici. Si d’autres nœuds sont ajoutés, vous devrez modifier manuellement les valeurs ici pour proportionner les ressources. Les quotas de ressources peuvent être modifiés aussi souvent que nécessaire, mais ils ne peuvent être supprimés que si l’espace de noms entier est supprimé.

      Si vous devez modifier un quota de ressources particulier, mettez à jour le fichier .yaml correspondant et appliquez les modifications à l’aide de la commande suivante :

      • kubectl apply -f resource-quota-default.yaml --namespace=default

      Pour plus d’informations sur le ResourceQuota Admission Controller, reportez-vous à la documentation officielle.

      Maintenant que votre quota de ressources est configuré, vous allez passer à la configuration du LimitRange Admission Controller. De la même manière que le ResourceQuota fait respecter les limites des espaces de noms, le LimitRange fait respecter les limites déclarées en validant et en faisant muter les conteneurs.

      De la même manière qu’auparavant, commencez par créer le fichier objet :

      • nano limit-range-default.yaml

      Maintenant, vous pouvez utiliser l’objet LimitRange pour restreindre l’utilisation des ressources selon les besoins. Ajoutez le contenu suivant comme exemple d’un cas d’utilisation typique :

      limit-ranges-default.yaml

      apiVersion: v1
      kind: LimitRange
      metadata:
        name: limit-range-default
      spec:
        limits:
        - max:
            cpu: "400m"
            memory: "1Gi"
          min:
            cpu: "100m"
            memory: "100Mi"
          default:
            cpu: "250m"
            memory: "800Mi"
          defaultRequest:
            cpu: "150m"
            memory: "256Mi"
          type: Container
      

      Les valeurs d’échantillon utilisées dans limit-ranges-default.yaml limitent la mémoire du conteneur à un maximum de 1Gi et limitent l’utilisation du CPU à un maximum de 400m, ce qui est une métrique de Kubernetes équivalente à 400 milliCPU, ce qui signifie que le conteneur est limité à utiliser presque la moitié de son cœur.

      Ensuite, déployez l’objet sur le serveur API à l’aide de la commande suivante :

      • kubectl create -f limit-range-default.yaml --namespace=default

      Cela donnera le résultat suivant :

      Output

      limitrange/limit-range-default created

      Vous pouvez maintenant vérifier les nouvelles limites avec la commande suivante :

      • kubectl describe limits --namespace=default

      Votre résultat sera similaire à celui-ci :

      Output

      Name: limit-range-default Namespace: default Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio ---- -------- --- --- --------------- ------------- ----------------------- Container cpu 100m 400m 150m 250m - Container memory 100Mi 1Gi 256Mi 800Mi -

      Pour voir LimitRanger en action, déployez un conteneur nginx standard avec la commande suivante :

      • kubectl run nginx --image=nginx --port=80 --restart=Never

      Cela donnera le résultat suivant :

      Output

      pod/nginx created

      Vérifiez comment le contrôleur d’admission a fait muter le conteneur en exécutant la commande suivante :

      • kubectl get pod nginx -o yaml

      Cela donnera de nombreuses lignes de résultats. Consultez la section sur les spécifications des conteneurs pour trouver les limites de ressources spécifiées dans le LimitRange Admission Controller :

      Output

      ... spec: containers: - image: nginx imagePullPolicy: IfNotPresent name: nginx ports: - containerPort: 80 protocol: TCP resources: limits: cpu: 250m memory: 800Mi requests: cpu: 150m memory: 256Mi ...

      Ce serait la même chose que si vous déclariez manuellement les ressources et les demandes dans la spécification du conteneur.

      Dans cette étape, vous avez utilisé les contrôleurs d’admission ResourceQuota et LimitRange pour vous protéger contre les attaques malveillantes envers les ressources de votre cluster. Pour plus d’informations sur le contrôleur d’admission LimitRange, consultez la documentation officielle.

      Conclusion

      Tout au long de ce guide, vous avez configuré un modèle de sécurité Kubernetes de base. Cela a permis d’établir l’authentification et l’autorisation des utilisateurs, les privilèges des applications et la protection des ressources des clusters. En combinant toutes les suggestions couvertes dans cet article, vous aurez une base solide pour le déploiement du cluster de production Kubernetes. A partir de là, vous pouvez commencer à renforcer les différents aspects de votre cluster en fonction de votre scénario.

      Si vous souhaitez en savoir plus sur Kubernetes, consultez notre page de ressources Kubernetes, ou suivez notre cours autogéré Kubernetes pour les développeurs Full-Stack.



      Source link

      How to Provision an Unmanaged Kubernetes Cluster using Terraform


      Updated by Linode

      Contributed by
      Linode

      Use Terraform, the popular orchestration tool by HaschiCorp, to deploy a Kubernetes cluster on Linode. Linode’s Terraform K8s module creates a Kubernetes cluster running on the CoreOS ContainerLinux operating system. After creating a Master and worker nodes, the module connects through SSH to these instances and installs kubeadm, kubectl, and other Kubernetes binaries to /opt/bin. It also handles initializing kubeadm, joining worker nodes to the master, and configuring kubectl. For the cluster’s container networking interface, Calico is installed. Finally, a kubectl admin config file is installed to the local environment, which you can use to connect to your cluster’s API server.

      Using Linode’s Terraform k8s module simplifies many of the steps involved in manually deploying a Kubernetes cluster with kubeadm. To learn more about kubeadm, see our Getting Started with Kubernetes: Use kubeadm to Deploy a Cluster on Linode guide.

      Note

      Currently, Linode’s Terraform k8s module only supports Kubernetes version 1.1.14. Development work to update this module is currently in progress. The latest updates can be found in the project’s corresponding GitHub repository.

      Before You Begin

      1. If you are new to Terraform, read through our A Beginner’s Guide to Terraform guide to familiarize yourself with key concepts.

      2. For an introduction to Kubernetes concepts, see our A Beginner’s Guide to Kubernetes series of guides.

      3. You need a personal access token for Linode’s v4 API to use with Terraform. Follow the Getting Started with the Linode API to get a token.

        Note

        When you create a personal access token ensure that you set Read/Write access because you are creating new Linode servers.

      4. Install Terraform on your computer.

        Note

      5. Install kubectl on your computer. You need kubectl to connect to and manage your Kubernetes cluster. Deployment of your cluster using this Terraform module fails if kubectl is not installed locally.

      In this Guide

      You will complete the following tasks:

      Configure your Local Environment

      Linode’s k8s Terraform module requires a local environment with a kubectl instance, a system-wide installation of Python, SSH keys, SSH keys configured with your SSH agent, and the sed and scp command line utilities. The module’s script preflight.sh verifies that all these requirements are installed on your local environment and generates a $var not found error if any of the tools are missing. This section shows how to install and configure kubectl, set up your SSH agent, and create an environment variable to store your API v4 token for easy reuse.

      If you receive an error that your system is missing Python, scp, or sed, use your operating system’s package manager to install the missing utilities.



      Create a Python Alias

      If your Python installation is invoked using python3, you can alias the command so that Terraform can execute scripts locally using Python as its interpreter.

      Using the text editor of your choice, edit your ~/.bashrc file to include the following alias:

      Then, reinitialize your ~/.bashrc file for the changes to take effect.

      source ~/.bashrc
      

      Install kubectl

      macOS:

      Install via Homebrew:

      brew install kubernetes-cli
      

      If you don’t have Homebrew installed, visit the Homebrew home page for instructions. Alternatively, you can manually install the binary; visit the Kubernetes documentation for instructions.

      Linux:

      1. Download the latest kubectl release:

        curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl
        
      2. Make the downloaded file executable:

        chmod +x ./kubectl
        
      3. Move the command into your PATH:

        sudo mv ./kubectl /usr/local/bin/kubectl
        

      Note

      Windows:

      Visit the Kubernetes documentation for a link to the most recent Windows release.

      SSH Agent

      By default, Terraform uses your operating system’s SSH agent to connect to a Linode instance through SSH. This section shows how to run the SSH agent and add your SSH keys to it.

      1. Run your SSH agent with the following command:

        eval `ssh-agent`
        

        The output is similar to:

          
        Agent pid 11308
           
        
      2. Add your SSH keys to the agent. For more information, see creating an authentication key-pair. This command adds keys from the default location, ~/.ssh/

        ssh-add
        

        The output is similar to:

          
        Identity added: /home/example_user/.ssh/id_rsa (/home/example_user/.ssh/id_rsa)
           
        

      Create an API Token Environment Variable

      When you run terraform commands that need to communicate with Linode’s API v4, you need to issue the command along with your Linode token. In this section, you create an environment variable to store the token for easy reuse.

      1. Create the TF_VAR_linode_token environment variable to store your Linode API v4 token. Enter your token after the prompt.

        read -sp "Linode Token: " TF_VAR_linode_token # Enter your Linode Token (it will be hidden)
        export TF_VAR_linode_token
        

        Note

        To use your environment variable, add the -var flag. For example, when you run the terraform apply command, you would do so using:

        terraform apply -var linode_token=$LINODE_TOKEN
        

      Create your Terraform Configuration Files

      1. In the directory where you installed terraform, create a new directory to store your Kubernetes cluster’s configuration files.

        cd terraform
        mkdir k8s-cluster
        
      2. Using the text editor of your choice, create your cluster’s main configuration file named main.tf. Add the following contents to the file.

        ~/terraform/k8s-cluster/main.tf
         1
         2
         3
         4
         5
         6
         7
         8
         9
        10
        11
        12
        
        module "k8s" {
          source             = "linode/k8s/linode"
          version            = "0.1.2"
          linode_token       = var.linode_token
          server_type_master = var.server_type_master
          server_type_node   = var.server_type_node
          cluster_name       = var.cluster_name
          k8s_version        = var.k8s_version
          region             = var.region
          nodes              = var.nodes
        }
              

        This file contains your cluster’s main configuration arguments. The only required configurations are source and linode_token. source calls Linode’s k8s module, while the linode_token will give you access to viewing, creating, and destroying Linode resources.

        The rest of the configurations are optional and have sane default values. In this example, however, you make use of Terraform’s input variables so that your main.tf configuration can be easily reused across different clusters, if desired.

      3. Create your input variables file, named variables.tf, with the example content.

        ~/terraform/k8s-cluster/variables.tf
         1
         2
         3
         4
         5
         6
         7
         8
         9
        10
        11
        12
        13
        14
        15
        16
        17
        18
        19
        20
        21
        22
        23
        24
        25
        26
        27
        28
        29
        30
        31
        32
        33
        34
        
        variable "linode_token" {
          description = " Linode API token"
        }
        
        variable "server_type_master" {
          default     = "g6-standard-2"
          description = " Linode API token"
        }
        
        variable "cluster_name" {
          description = " Linode API token"
          default     = "example-cluster-1"
        }
        
        variable "server_type_node" {
          description = " Linode API token"
          default     = "g6-standard-1"
        }
        
        variable "k8s_version" {
          description = " Linode API token"
          default     = "v1.14.0"
        }
        
        variable "region" {
          description = "Values: us-east, ap-west, etc."
          default     = "us-east"
        }
        
        variable "nodes" {
          description = " Linode API token"
          default     = 3
        }
              

        The example file creates input variables which are referenced in your main configuration file that you created in the previous step. The values for those variables are assigned in a separate file in the next step. You can override the k8s module’s default values and provide your own defaults, as done in the example file. For more details about input variables, see the Input Variables section in our A Beginner’s Guide to Terraform guide.

      4. Create your input variables values file to provide your main configuration file with values that differ from your input variable file’s defaults.

        ~/terraform/k8s-cluster/terraform.tfvars
        1
        2
        3
        
        server_type_master = "g6-standard-4"
        cluster_name = "example-cluster-2"
              

        In this example, your cluster’s master node uses a g6-standard-4 Linode plan, instead of the default g6-standard-2, and the cluster_name is set to example-cluster-2, instead of example-cluster-1.

      Deploy Your Kubernetes Cluster

      1. Change to ~/terraform/k8s-cluster/ directory and initialize Terraform to install the Linode K8s module.

        terraform init
        
      2. Verify that Terraform creates your cluster’s resources as you expect them to be created before making any actual changes to your infrastructure. To do this, run the plan command:

        terraform plan
        

        This command generates a report detailing what actions Terraform will take to set up your Kubernetes cluster.

      3. If you are satisfied with the generated report, run the apply command to create your Kubernetes cluster. This command prompts you to confirm that you want to proceed.

        terraform apply -var-file="terraform.tfvars"
        

        After a few minutes, when Terraform has finished applying your configuration, it displays a report of what actions were taken and your Kubernetes cluster is ready for you to connect to it.

      Connect to Your Kubernetes Cluster with kubectl

      After Terraform finishes deploying your Kubernetes cluster, your ~/terraform/k8s-cluster/ directory should have a file named default.conf. This file contains your kubeconfig file. You can use kubectl, along with this file, to gain access to your Kubernetes cluster.

      1. Save your kubeconfig file’s path to the $KUBECONFIG environment variable. In the example command, the kubeconfig file is located in the Terraform directory you created at the beginning of this guide. Ensure that you update the command with the location of your default.conf file

        export KUBECONFIG=~/terraform/k8s-cluster/default.conf
        

        Note

        It is common practice to store your kubeconfig files in ~/.kube directory. By default, kubectl searches for a kubeconfig file named config that is located in the ~/.kube directory. You can specify other kubeconfig files by setting the $KUBECONFIG environment variable, as done in the step above.

      2. View your cluster’s nodes using kubectl.

        kubectl get nodes
        

        Note

        If your kubectl commands are not returning the resources and information you expect, then your client may be assigned to the wrong cluster context. Visit our Troubleshooting Kubernetes guide to learn how to switch cluster contexts.

        You are now ready to manage your cluster using kubectl. For more information about using kubectl, see Kubernetes’ Overview of kubectl guide.

      Persist the Kubeconfig Context

      If you open a new terminal window, it does not have access to the context that you specified using the previous instructions. This context information can be made persistent between new terminals by setting the KUBECONFIG environment variable in your shell’s configuration file.

      Note

      These instructions are for the Bash terminal. They are similar for other terminals that you may use:

      1. Navigate to the $HOME/.kube directory:

        cd $HOME/.kube
        
      2. Create a directory called configs within $HOME/.kube. You can use this directory to store your kubeconfig files.

        mkdir configs
        
      3. Copy your default.conf file to the $HOME/.kube/configs directory.

        cp ~/terraform/k8s-cluster/default.conf $HOME/.kube/configs/default.conf
        

        Note

        Optionally, you can give the copied file a different name to help distinguish it from other files in the configs directory.

      4. Open up your Bash profile (e.g. ~/.bashrc) in the text editor of your choice and add your configuration file to the $KUBECONFIG PATH variable.

        If an export KUBECONFIG line is already present in the file, append to the end of this line as follows; if it is not present, add this line to the end of your file:

        export KUBECONFIG=$KUBECONFIG:$HOME/.kube/config:$HOME/.kube/configs/default.conf
        
      5. Close your terminal window and open a new window to receive the changes to the $KUBECONFIG variable.

      6. Use the config get-contexts command for kubectl to view the available cluster contexts:

        kubectl config get-contexts
        

        You should see output similar to the following:

          
        CURRENT   NAME                                 CLUSTER             AUTHINFO           NAMESPACE
        *         [email protected]   example-cluster-1   kubernetes-admin
        
        
      7. If your context is not already selected, (denoted by an asterisk in the current column), switch to this context using the config use-context command. Supply the full name of the cluster (including the authorized user and the cluster):

        kubectl config use-context [email protected]
        

        You should see output similar to the following:

          
        Switched to context "[email protected]".
        
        
      8. You are now ready to interact with your cluster using kubectl. You can test the ability to interact with the cluster by retrieving a list of Pods. Use the get pods command with the -A flag to see all pods running across all namespaces:

        kubectl get pods -A
        

        You should see output like the following:

          
        NAMESPACE            NAME                                               READY   STATUS    RESTARTS   AGE
        kube-system          calico-node-5bkc6                                  2/2     Running   0          17m
        kube-system          calico-node-gp5ls                                  2/2     Running   0          17m
        kube-system          calico-node-grpnj                                  2/2     Running   0          17m
        kube-system          calico-node-qd85t                                  2/2     Running   0          17m
        kube-system          ccm-linode-mjgzz                                   1/1     Running   0          17m
        kube-system          coredns-fb8b8dccf-5tlbm                            1/1     Running   0          17m
        kube-system          coredns-fb8b8dccf-7tpgf                            1/1     Running   0          17m
        kube-system          csi-linode-controller-0                            3/3     Running   0          17m
        kube-system          csi-linode-node-gfd8m                              2/2     Running   0          17m
        kube-system          csi-linode-node-hrfnd                              2/2     Running   0          16m
        kube-system          csi-linode-node-q6fmd                              2/2     Running   0          17m
        kube-system          etcd-mytestcluster-master-1                        1/1     Running   0          16m
        kube-system          external-dns-7885f88564-tvpjf                      1/1     Running   0          17m
        kube-system          kube-apiserver-mytestcluster-master-1              1/1     Running   0          16m
        kube-system          kube-controller-manager-mytestcluster-master-1     1/1     Running   0          16m
        kube-system          kube-proxy-cs9tm                                   1/1     Running   0          17m
        kube-system          kube-proxy-qljn5                                   1/1     Running   0          17m
        kube-system          kube-proxy-sr5h8                                   1/1     Running   0          17m
        kube-system          kube-proxy-ww2tx                                   1/1     Running   0          17m
        kube-system          kube-scheduler-mytestcluster-master-1              1/1     Running   0          16m
        kube-system          kubernetes-dashboard-5f7b999d65-jk99z              1/1     Running   0          17m
        kube-system          metrics-server-58db9f9647-tz8f8                    1/1     Running   0          17m
        reboot-coordinator   container-linux-update-agent-6kgqm                 1/1     Running   0          16m
        reboot-coordinator   container-linux-update-agent-7nck5                 1/1     Running   0          17m
        reboot-coordinator   container-linux-update-agent-nhlxj                 1/1     Running   0          17m
        reboot-coordinator   container-linux-update-agent-vv8db                 1/1     Running   0          17m
        reboot-coordinator   container-linux-update-operator-5c9d67d4cf-78wbp   1/1     Running   0          17m
        
        

      More Information

      You may wish to consult the following resources for additional information on this topic. While these are provided in the hope that they will be useful, please note that we cannot vouch for the accuracy or timeliness of externally hosted materials.

      This guide is published under a CC BY-ND 4.0 license.



      Source link