Versione 1.6. Questa versione non è più supportata. Per ulteriori informazioni, consulta le norme relative all'assistenza per le versioni. Per informazioni su come eseguire l'upgrade alla versione 1.7, consulta la pagina relativa all'upgrade di Anthos su Bare Metal nella documentazione della versione 1.7.

Versioni supportate disponibili: 1.14 | 1.13 | 1.12

Guida rapida di Cluster Anthos su Bare Metal

Introduzione ai cluster Anthos su Bare Metal

Guida rapida alla configurazione di Cluster Anthos on bare metal

Con Cluster Anthos on bare metal, puoi definire quattro tipi di cluster:

admin: un cluster utilizzato per gestire i cluster utente.
user - Un cluster utilizzato per eseguire carichi di lavoro.
standalone: un unico cluster che può amministrare autonomamente e che può eseguire carichi di lavoro, ma non può creare o gestire altri cluster utente.
hybrid: un unico cluster per amministratori e carichi di lavoro, in grado di gestire anche i cluster utente.

In questa guida rapida, eseguirai il deployment di un cluster ibrido a due nodi con Cluster Anthos on bare metal. Imparerai a creare un cluster e a monitorare il processo di creazione del cluster.

Questa guida rapida presuppone che tu abbia una conoscenza di base di Kubernetes

Preparazione per Cluster Anthos on bare metal

Il comando di installazione di Cluster Anthos on bare metal, chiamato bmctl, è stato progettato per semplificare la creazione dei cluster. Il comando può configurare automaticamente gli account di servizio e le API Google necessari per Cluster Anthos on bare metal, e utilizzeremo questi servizi automatizzati in questa guida rapida.

Se vuoi, puoi anche configurare manualmente i servizi e le API necessari prima di creare i cluster con bmctl. Noteremo le modifiche al comando che devi apportare in seguito in questo documento, ma per configurare manualmente i servizi Google di cui hai bisogno, consulta Attivare i servizi e gli account di servizio Google.

Prima di poter creare un cluster utilizzando Cluster Anthos on bare metal, assicurati di:

Crea un progetto Google Cloud in cui hai il ruolo Editor o Proprietario.
Scarica e installa lo strumento a riga di comando bmctl come descritto di seguito.
Configura una workstation di amministrazione Linux per l'esecuzione di bmctl. Nota: non utilizzare Cloud Shell come workstation di amministrazione.
1. Installa gcloud, gsutil e kubectl come descritto di seguito.
2. Installa Docker versione 19.03 o successive. Per istruzioni sulla configurazione di Docker, consulta la pagina per configurare il tuo sistema operativo Linux: Configurazione di CentOS, Configurazione di RHEL o Configurazione di Ubuntu.
3. Utilizzando l'accesso root, configura SSH sia sulla workstation di amministrazione sia sulle macchine dei nodi del cluster remoto. Inizialmente, è necessario abilitare l'autenticazione tramite password SSH di root sulle macchine dei nodi del cluster remoto per condividere le chiavi dalla workstation di amministrazione. Dopo aver inserito le chiavi, puoi disabilitare l'autenticazione tramite password SSH.
4. Genera una coppia di chiavi pubblica/privata nella workstation di amministrazione (non impostare una passphrase per le chiavi). Le chiavi sono necessarie per utilizzare SSH per connessioni sicure e senza password tra la workstation di amministrazione e le macchine dei nodi del cluster.
```
ssh-keygen -t rsa
```
  Puoi anche utilizzare l'accesso utente SUDO alle macchine dei nodi del cluster per configurare SSH, ma per le connessioni utente senza password e non radice devi aggiornare il file YAML cluster config con le credenziali appropriate. Per ulteriori informazioni, consulta la sezione #Node access configuration nel file di configurazione del cluster di esempio.
5. Aggiungi la chiave pubblica generata alle macchine dei nodi del cluster. Per impostazione predefinita, le chiavi pubbliche sono archiviate nel file di identità id_rsa.pub.
```
ssh-copy-id -i ~/.ssh/identity_file root@cluster_node_ip
```
6. Disabilita l'autenticazione tramite password SSH sulle macchine nodo del cluster e utilizza il seguente comando sulla workstation di amministrazione per verificare che l'autenticazione delle chiavi pubbliche funzioni tra la workstation di amministrazione e le macchine dei nodi del cluster.
```
ssh -o IdentitiesOnly=yes -i identity_file root@cluster_node_ip
```

Installazione delle utilità di gcloud

Gli strumenti gcloud, gsutil e kubectl sono inclusi nell'interfaccia a riga di comando gcloud.

Sulla macchina di amministrazione, installa e inizializza gcloud CLI utilizzando le istruzioni riportate qui. Questo processo installa gcloud e gsutil.
Aggiorna l'interfaccia a riga di comando gcloud:
```
gcloud components update
```
Accedi con il tuo Account Google per gestire i servizi e gli account di servizio:
```
gcloud auth login --update-adc
```
Viene visualizzata una nuova scheda del browser e ti viene chiesto di scegliere un account.

Tieni presente che a questo punto puoi configurare un progetto predefinito di Google Cloud e abilitare altri servizi e API di Google. prima di creare i cluster Anthos su cluster Bare Metal. L'impostazione di un progetto predefinito consente di risparmiare tempo quando abiliti i servizi manualmente.

Tuttavia, come mostrato in questa guida rapida, puoi anche specificare un progetto e configurare i servizi Google richiesti, direttamente con il comando bmctl quando crei i cluster. In questo caso, bmctl utilizza sempre l'ID progetto specificato durante l'esecuzione del comando.
Usa gcloud per installare kubectl:
```
gcloud components install kubectl
```

Installazione di bmctl

Lo strumento a riga di comando per creare cluster in Cluster Anthos on bare metal è bmctl. Puoi scaricare bmctl da un bucket Cloud Storage

Per scaricare bmctl:

Crea una nuova directory per bmctl:
```
cd ~
mkdir baremetal
cd baremetal
```

Scarica bmctl dal bucket Cloud Storage:

gsutil cp gs://anthos-baremetal-release/bmctl/1.6.2/linux-amd64/bmctl bmctl
chmod a+x bmctl

Assicurati che bmctl sia installato correttamente visualizzando le informazioni della guida:
```
./bmctl -h
```

Creazione dei nodi del cluster

Crea due macchine da utilizzare come nodi per il tuo cluster:

Una macchina funge da nodo del piano di controllo.
Una macchina funge da nodo worker.

Tieni presente che la tua workstation di amministrazione deve essere in grado di ssh per questi nodi e avere accesso al VIP del piano di controllo.

Consulta i requisiti di hardware e sistema operativo (Cento, RHEL e Ubuntu) per ulteriori informazioni sui requisiti per i nodi del cluster.

Creazione di un cluster

Per creare un cluster:

Utilizza bmctl per creare un file di configurazione.
Modifica il file di configurazione per personalizzarlo per il cluster e la rete.
Usa bmctl per creare il cluster dal file di configurazione.

Creazione di un file di configurazione

Per creare un file di configurazione e abilitare automaticamente account e API di servizio, assicurati di essere nella directory baremetal ed esegui il comando bmctl con i seguenti flag:

./bmctl create config -c CLUSTER_NAME \
  --enable-apis --create-service-accounts --project-id=PROJECT_ID

CLUSTER_NAME è il nome del tuo cluster e PROJECT_ID è un progetto Google per il quale hai un ruolo di Proprietario o Editor.

Questo comando crea un file di configurazione nella directory baremetal all'indirizzo: bmctl-workspace/cluster1/cluster1.yaml

Modificare il file di configurazione

Per modificare il file di configurazione:

Apri il file di configurazione bmctl-workspace/cluster1/cluster1.yaml in un editor.
Modifica il file per i requisiti specifici di nodo e rete. Guarda il file di configurazione di esempio riportato di seguito. Tieni presente che in questa guida rapida abbiamo omesso OpenID Connect (OIDC)

# gcrKeyPath: < to GCR service account key>
gcrKeyPath: baremetal/gcr.json
# sshPrivateKeyPath: < to SSH private key, used for node access>
sshPrivateKeyPath: .ssh/id_rsa
# gkeConnectAgentServiceAccountKeyPath: < to Connect agent service account key>
gkeConnectAgentServiceAccountKeyPath: baremetal/connect-agent.json
# gkeConnectRegisterServiceAccountKeyPath: < to Hub registration service account key>
gkeConnectRegisterServiceAccountKeyPath: baremetal/connect-register.json
# cloudOperationsServiceAccountKeyPath: < to Cloud Operations service account key>
cloudOperationsServiceAccountKeyPath: baremetal/cloud-ops.json
---
apiVersion: v1
kind: Namespace
metadata:
name: cluster-cluster1
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: cluster1
namespace: cluster-cluster1
spec:
# Cluster type. This can be:
# 1) admin: to create an admin cluster. This can later be used to create user clusters.
# 2) user: to create a user cluster. Requires an existing admin cluster.
# 3) hybrid: to create a hybrid cluster that runs admin cluster components and user workloads.
# 4) standalone: to create a cluster that manages itself, runs user workloads, but does not manage other clusters.
type: hybrid
# Anthos cluster version.
anthosBareMetalVersion: 1.6.2
# GKE connect configuration
gkeConnect:
projectID: PROJECT_ID
# Control plane configuration
controlPlane:
nodePoolSpec:
nodes:
# Control plane node pools. Typically, this is either a single machine
# or 3 machines if using a high availability deployment.
- address: CONTROL_PLANE_NODE_IP
# Cluster networking configuration
clusterNetwork:
# Pods specify the IP ranges from which Pod networks are allocated.
pods:
cidrBlocks:
- 192.168.0.0/16
# Services specify the network ranges from which service VIPs are allocated.
# This can be any RFC 1918 range that does not conflict with any other IP range
# in the cluster and node pool resources.
services:
cidrBlocks:
- 172.26.232.0/24
# Load balancer configuration
loadBalancer:
# Load balancer mode can be either 'bundled' or 'manual'.
# In 'bundled' mode a load balancer will be installed on load balancer nodes during cluster creation.
# In 'manual' mode the cluster relies on a manually-configured external load balancer.
mode: bundled
# Load balancer port configuration
ports:
# Specifies the port the LB serves the kubernetes control plane on.
# In 'manual' mode the external load balancer must be listening on this port.
controlPlaneLBPort: 443
# There are two load balancer VIPs: one for the control plane and one for the L7 Ingress
# service. The VIPs must be in the same subnet as the load balancer nodes.
vips:
# ControlPlaneVIP specifies the VIP to connect to the Kubernetes API server.
# This address must not be in the address pools below.
controlPlaneVIP: CONTROL_PLANE_VIP
# IngressVIP specifies the VIP shared by all services for ingress traffic.
# Allowed only in non-admin clusters.
# This address must be in the address pools below.
ingressVIP: INGRESS_VIP
# AddressPools is a list of non-overlapping IP ranges for the data plane load balancer.
# All addresses must be in the same subnet as the load balancer nodes.
# Address pool configuration is only valid for 'bundled' LB mode in non-admin clusters.
# addressPools:
# - name: pool1
# addresses:
# # Each address must be either in the CIDR form (1.2.3.0/24)
# # or range form (1.2.3.1-1.2.3.5).
# - LOAD_BALANCER_ADDRESS_POOL-
# A load balancer nodepool can be configured to specify nodes used for load balancing.
# These nodes are part of the kubernetes cluster and run regular workloads as well as load balancers.
# If the node pool config is absent then the control plane nodes are used.
# Node pool configuration is only valid for 'bundled' LB mode.
# nodePoolSpec:
# nodes:
# - address: LOAD_BALANCER_NODE_IP;
# Proxy configuration
# proxy:
# url: http://[username:password@]domain
# # A list of IPs, hostnames or domains that should not be proxied.
# noProxy:
# - 127.0.0.1
# - localhost
# Logging and Monitoring
clusterOperations:
# Cloud project for logs and metrics.
projectID: PROJECT_ID
# Cloud location for logs and metrics.
location: us-central1
# Whether collection of application logs/metrics should be enabled (in addition to
# collection of system logs/metrics which correspond to system components such as
# Kubernetes control plane or cluster management agents).
# enableApplication: false
# Storage configuration
storage:
# lvpNodeMounts specifies the config for local PersistentVolumes backed by mounted disks.
# These disks need to be formatted and mounted by the user, which can be done before or after
# cluster creation.
lvpNodeMounts:
# path specifies the host machine path where mounted disks will be discovered and a local PV
# will be created for each mount.
path: /mnt/localpv-disk
# storageClassName specifies the StorageClass that PVs will be created with. The StorageClass
# is created during cluster creation.
storageClassName: local-disks
# lvpShare specifies the config for local PersistentVolumes backed by subdirectories in a shared filesystem.
# These subdirectories are automatically created during cluster creation.
lvpShare:
# path specifies the host machine path where subdirectories will be created on each host. A local PV
# will be created for each subdirectory.
path: /mnt/localpv-share
# storageClassName specifies the StorageClass that PVs will be created with. The StorageClass
# is created during cluster creation.
storageClassName: local-shared
# numPVUnderSharedPath specifies the number of subdirectories to create under path.
numPVUnderSharedPath: 5
---
# Node pools for worker nodes
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
name: node-pool-1
namespace: cluster-cluster1
spec:
clusterName: cluster1
nodes:
- address: WORKER_NODE_IP

Esecuzione di controlli preflight e creazione del cluster

Il comando bmctl esegue controlli preflight sul file di configurazione del cluster prima di creare un cluster. Se l'operazione riesce, il cluster verrà creato.

Per eseguire i controlli preflight e creare il cluster:

Assicurati di essere nella directory baremetal.
Utilizza il comando seguente per creare il cluster:

./bmctl create cluster -c CLUSTER_NAME

./bmctl create cluster -c cluster1

Il comando bmctl monitora i controlli preflight e la creazione del cluster, quindi visualizza l'output sullo schermo e scrive le informazioni dettagliate nei log bmctl.

I log, bmctl oltre al controllo preflight e ai log di installazione del nodo, si trovano nella directory: baremetal/bmctl-workspace/CLUSTER_NAME/log

Il preflight bmctl verifica l'installazione del cluster proposto per le seguenti condizioni:

La distribuzione e la versione di Linux sono supportate.
SELinux non è in modalità "applicazione forzata".
Per Ubuntu, AppArmor e UFW non sono attivi.
Per CentOS/RHEL, il firewall non è attivo.
Google Container Registry è raggiungibile.
Sono disponibili VIP.
Le macchine dei cluster hanno connettività tra loro.
Le macchine del bilanciatore del carico si trovano nella stessa subnet L2.

Il completamento della creazione del cluster può richiedere diversi minuti.

Recupero delle informazioni sul cluster

Una volta creato il cluster, il comando kubectl mostra le informazioni sul nuovo cluster. Durante la creazione del cluster, il comando bmctl scrive un file kubeconfig per il cluster su cui si esegue la query con kubectl. Il file kubeconfig è scritto in bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-kubeconfig.

Ad esempio:

kubectl --kubeconfig bmctl-workspace/cluster1/cluster1-kubeconfig get nodes

Questo comando restituisce:

NAME      STATUS   ROLES    AGE   VERSION
node-01   Ready    master   16h   v1.17.8-gke.16
node-02   Ready    <none>   16h   v1.17.8-gke.16

Se la creazione del cluster non riesce, controlla i log di controllo preflight per verificare la presenza di errori e correggili nel file di configurazione del cluster. I log di controllo preflight si trovano nella directory /log

~/baremetal/bmctl-workspace/CLUSTER_NAME/log

I log di controllo preflight per ogni macchina nel cluster si trovano nella directory CLUSTER_NAME e sono organizzati per indirizzo IP. Ad esempio:

bmctl-workspace/cluster1/log
└── preflight-20201007-034844
    ├── 172.17.0.3
    ├── 172.17.0.4
    ├── 172.17.0.5
    ├── 172.17.0.6
    ├── 172.17.0.7
    └── node-network

Ignorare gli errori di controllo pre-volo

Se la creazione del cluster non riesce dopo i controlli pre-flight, puoi provare a reinstallare il cluster utilizzando il --force flag nel comando bmctl .

Il flag --force viene installato su un cluster esistente, ma ignora i risultati di eventuali errori di controllo preliminare dovuti a porte del server già allocate.

Assicurati di essere nella directory baremetal.
Utilizza il comando seguente con il flag --force per ricreare il cluster:

./bmctl create cluster -c CLUSTER_NAME --force

./bmctl create cluster -c cluster1 --force

Creazione di un deployment e di un servizio

Di seguito è riportato un manifest per un deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  selector:
    matchLabels:
      app: metrics
      department: sales
  replicas: 3
  template:
    metadata:
      labels:
        app: metrics
        department: sales
    spec:
      containers:
      - name: hello
        image: "gcr.io/google-samples/hello-app:2.0"

Salva il manifest come my-deployment.yaml e crea il deployment:

kubectl --kubeconfig bmctl-workspace/cluster1/cluster1-kubeconfig create -f my-deployment.yaml

Visualizza il deployment:

kubectl --kubeconfig bmctl-workspace/cluster1/cluster1-kubeconfig get deployments

L'output mostra che il deployment ha tre pod in esecuzione:

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
my-deployment      3/3     3            3           16s

Di seguito è riportato un manifest per un servizio di tipo LoadBalancer:

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: metrics
    department: sales
  type: LoadBalancer
  ports:
  - port: 80
    targetPort: 8080

Salva il manifest come my-service.yaml e crea il servizio:

kubectl --kubeconfig bmctl-workspace/cluster1/cluster1-kubeconfig create -f my-service.yaml

Visualizza il servizio:

kubectl --kubeconfig bmctl-workspace/cluster1/cluster1-kubeconfig get service my-service

Output:

NAME         TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S
my-service   LoadBalancer   172.26.232.2   172.16.1.21   80:30060/TCP

Nota che Cluster Anthos on bare metal ha dato al servizio un indirizzo IP esterno. Utilizza l'indirizzo IP esterno per chiamare il servizio:

curl 172.16.1.21

L'output è un messaggio di benvenuto:

Hello, world!
Version: 2.0.0
Hostname: my-deployment-75d45b64f9-6clxj

Creazione di un piano di controllo ad alta disponibilità

Questa guida rapida crea un semplice cluster ibrido a due nodi. Se vuoi creare un piano di controllo ad alta disponibilità, crea un cluster con tre nodi del piano di controllo.

Ad esempio, modifica il file di configurazione mostrato sopra per aggiungerlo a ulteriori nodi del piano di controllo:

controlPlane:
  nodePoolSpec:
    clusterName: cluster1
    nodes:
    # Control Plane node pools. Typically, this is either a single machine
    # or 3 machines if using a high availability deployment.
    - address: <Machine 1 IP>
    - address: <Machine 2 IP>
    - address: <Machine 3 IP>

Esecuzione del bilanciatore del carico in un proprio pool di nodi

Questa guida rapida crea un semplice cluster ibrido a due nodi. Il bilanciatore del carico viene eseguito sullo stesso nodo che esegue il piano di controllo.

Se vuoi che il bilanciatore del carico venga eseguito nel proprio pool di nodi, modifica i valori nodePoolSpec della sezione loadBalancer del file di configurazione:

  loadBalancer:
    nodePoolSpec:
      clusterName: "cluster1"
      nodes:
      - address: <LB Machine 1 IP>
      - address: <LB Machine 2 IP>