Intégration d'une unité F5 BIG-IP à IBM Cloud Private

Procédez comme suit pour intégrer l'unité F5 BIG-IP à votre cluster IBM® Cloud Private :

Prérequis

Votre cluster IBM Cloud Private doit être prêt.
Vous devez posséder une unité BIG-IP sous licence et mise à disposition pour vos exigences.
Vous devez mettre à disposition et exécuter Calico dans votre cluster IBM Cloud Private.

Procédure

Configurez l'unité F5 BIG-IP comme une unité homologue pour votre cluster IBM Cloud Private en installant la charte ibm-calico-bgp-peer version 1.1.0. Lorsque vous configurez l'unité LTM comme une unité homologue pour votre cluster IBM Cloud Private qui exécute Calico, l'unité LTM communique directement avec les pods.
Installez la charte ibm-f5bigip-controller version 1.1.0. La charte crée un contrôleur chargé de surveiller les objets Kubernetes qui sont créés et communique ceux qui sont concernés à l'unité F5 BIG-IP. Par conséquent, l'unité F5 BIG-IP crée des serveurs virtuels appropriés et d'autres objets LTM correspondants.

Configuration de l'unité F5 BIG-IP comme une unité homologue pour votre cluster IBM Cloud Private

Procédez comme suit pour ajouter l'unité F5 BIG-IP comme homologue BGP au maillage Calico dans votre cluster IBM Cloud Private :

Connectez-vous à la console de gestion.
Cliquez sur Catalogue et recherchez la charte ibm-calico-bgp-peer.
Indiquez l'adresse IP interne de l'unité F5 BIG-IP et le numéro de système autonome (AS). Dans le cluster Calico IBM Cloud Private, le numéro AS défini est 64512. Si vous avez besoin d'appliquer l'unité en tant qu'homologue uniquement pour un noeud de cluster spécifique, indiquez l'adresse IP interne de ce dernier. Sinon, laissez la zone vide de manière à informer chaque noeud du cluster de l'existence de cet homologue.
Définissez le contexte pour calicoctl. Vous devez indiquer l'URL de noeud final etcd et les données d'identification etcd.
- etcd Endpoint : le noeud final etcd doit être indiqué au format https://<master-node-internal-IP-address>:4001. Utilisez la commande suivante pour obtenir les informations relatives au noeud final etcd :
```
 kubectl get cm etcd-config -ojsonpath={.data.etcd_endpoints} -n kube-system
```
  Exemple de résultat obtenu :
```
 https://192.168.70.225:4001
```
- etcd Secret : objet de secret Kubernetes doté du certificat de l'autorité de certification (etcd-ca), du certificat client (etcd-cert) et de la clé privée (etcd-key) qui permettent d'accéder à etcd. Remarque : vous devez créer l'objet de secret Kubernetes dans l'espace de nom kube-system.
```
kind: Secret
metadata:
 name: etcd-secret
 namespace: kube-system
type: Opaque
data:
 etcd-ca: LS0......
   .......
   .......
   ..tLQ==
 etcd-cert: MS0......
   .......
   .......
   ..tLQ==
 etcd-key: NS0......
   .......
   .......
   ..tsde2
```
Dans IBM Cloud Private, vous pouvez utiliser la commande suivante pour obtenir les informations relatives au secret etcd existant :
```
   kubectl get secret etcd-secret -oyaml -n kube-system
```
Exemple de résultat obtenu :
```
   apiVersion: v1
   data:
     etcd-ca: 
   LS0tLS1CRU....LQ==
     etcd-cert:
   Q2VydGlm....LS0=
       etcd-key: 
   LS0tLS1....LS0=
   kind: Secret
   metadata:
     name: etcd-secret
     namespace: kube-system
   type: Opaque
   ~#
```
Fournissez les détails de l'image calico-ctl. Ces détails sont obligatoires car la commande calicoctl est utilisée pour configurer l'homologue BGP.
- Repository est l'emplacement de l'image.
- Tag est l'étiquette d'image. Dans IBM Cloud Private version 3.2.1, l'étiquette doit être v3.5.2.
- Pullpolicy est la politique d'extraction d'image. La valeur par défaut est IfNotPresent.
Cliquez sur Install pour installer la charte.

Connectez-vous à l'unité F5 BIG-IP et exécutez ces commandes pour finaliser la configuration d'homologue BGP :

ssh root@<F5-BIG-IP-device-IP-address>
imish
enable
configure terminal
router bgp <AS number>
neighbor <cluster-name> peer-group
neighbor <cluster-name> remote-as <AS number>
neighbor <master node IP address> peer-group <cluster-name>
neighbor <worker node 1 IP address> peer-group <cluster-name>
neighbor <worker node 2 IP address> peer-group <cluster-name>
write
exit
exit

Assurez-vous que tous les noeuds de cluster que vous souhaitez ajouter en tant qu'homologues disposent d'une connectivité avec l'unité F5 BIG-IP. Ajoutez tous ces noeuds en tant qu'homologues.

Voici un exemple de configuration basé sur l'exemple de topologie :

ssh root@192.168.80.254
imish
enable
configure terminal
router bgp 64512
neighbor cluster1 peer-group
neighbor cluster1 remote-as 64512
neighbor 192.168.70.225 peer-group cluster1  # ICP master node
neighbor 192.168.70.226 peer-group cluster1  # ICP worker node 1
neighbor 192.168.70.227 peer-group cluster1  # ICP worker node 2
write
exit
exit

Vérifiez que l'unité F5 BIG-IP est ajoutée en tant qu'homologue BGP dans le maillage Calico. Vérifiez le statut de n'importe quel noeud de cluster à l'aide de l'utilitaire calicoctl.

calicoctl node status

Voici un exemple de résultat lorsque la commande est exécutée sur le noeud maître :

Calico process is running.
IPv4 BGP status
+----------------+-------------------+-------+------------+-------------+
|  PEER ADDRESS  |     PEER TYPE     | STATE |   SINCE    |    INFO     |
+----------------+-------------------+-------+------------+-------------+
| 192.168.70.226 | node-to-node mesh | up    | 2018-04-03 | Established |
| 192.168.70.227 | node-to-node mesh | up    | 2018-04-03 | Established |
| 192.168.70.254 | global            | up    | 09:46:47   | Established |
+----------------+-------------------+-------+------------+-------------+

Vérifiez que la table de routage sur l'unité F5 BIG-IP est mise à jour avec des routes vers tous les noeuds de votre cluster IBM Cloud Private. Vous pouvez désormais atteindre les ID de pod directement à partir du nouvel homologue BGP.

route -n

Exemple de résultat obtenu :

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.80.1    0.0.0.0         UG    9      0        0 mgmt
192.168.80.0    0.0.0.0         255.255.255.0   U     0      0        0 mgmt
10.1.85.192     192.168.70.227  255.255.255.192 UG    0      0        0 internal_vlan
10.1.145.64     192.168.70.225  255.255.255.192 UG    0      0        0 internal_vlan
10.1.148.64     192.168.70.226  255.255.255.192 UG    0      0        0 internal_vlan
192.168.60.0    0.0.0.0         255.255.255.0   U     0      0        0 external_vlan
192.168.70.0    0.0.0.0         255.255.255.0   U     0      0        0 internal_vlan

La configuration de l'unité homologue est terminée. Vous pouvez désormais créer la charte Helm pour intégrer F5 BIG-IP Controller à IBM Cloud Private.

Installation de la charte ibm-f5bigip-controller

Installez la charte ibm-f5bigip-controller pour l'intégration au contrôleur F5 BIG-IP.

Connectez-vous à la console de gestion.
Accédez à Catalogue et recherchez la charte ibm-f5bigip-controller.
Fournissez les attributs requis pour la charte.
- URL est l'adresse IP de gestion de l'unité F5 BIG-IP.
- Partition Name est la partition BIG-IP dans laquelle vous configurez des objets. Vérifiez qu'une partition est gérée à partir d'un seul contrôleur F5 BIG-IP Kubernetes. Gérer la même partition à partir de plusieurs contrôleurs F5 BIG-IP Kubernetes peut entraîner un comportement inattendu.
- Username est le nom d'utilisateur BIG-IP iControl REST.
- Password est le mot de passe BIG-IP iControl REST.
- Pool Member Type est le type de membres de pool BIG-IP que vous souhaitez créer. Les valeurs valides sont cluster ou nodeport. Utilisez cluster pour créer des membres de pool pour chaque noeud final du service, autrement dit le pod. Utilisez nodeport pour créer des membres de pool pour chaque noeud du cluster Kubernetes et pour vous appuyer sur kube-proxy au niveau noeud pour effectuer l'équilibrage de charge des demandes vers les pods.
- Default Ingress IP est l'adresse IP qui est utilisée par le contrôleur pour configurer un serveur virtuel pour tous les contrôleurs ingress avec l'annotation virtual-server.f5.com/ip: controller-default.
- Namespace(s) est la liste d'espaces de nom Kubernetes à surveiller. Par exemple, ["ns1","ns2"].
- Node Label Selector est le libellé de noeud. Kubernetes BIG IP Controller surveille uniquement les noeuds portant le libellé spécifié.
- Extra Arguments sont les autres options Kubernetes BIG IP Controller. Indiquez une carte au format {"key":"value", …}.
Indiquez les valeurs de paramètre NodeSelector et Tolerations.
- NodeSelector est le noeud sur lequel le contrôleur doit être exécuté. Par exemple, si vous souhaitez que le pod de contrôleur soit placé sur le noeud maître, indiquez {"role": "master"}.
- Tolerations est utilisé pour planifier le contrôleur sur un pod avec des tâches taint correspondante. Par exemple, [{"key":"dedicated","operator":"Exists","effect":"NoSchedule"},{"key":"CriticalAddonsOnly","operator":"Exists"}].
Cliquez sur Install pour installer la charte.

Vérifiez que le pod F5 BIG IP Controller s'exécute et surveille correctement les ressources dans les espaces de nom requis.

kubectl get po -n <release-namespace>

Exemple de résultat obtenu :

NAME                                   READY     STATUS    RESTARTS   AGE
c1-f5bigipctlr-ctlr-7d8759cd7f-z8zm4   1/1       Running   0          52m

L'intégration de l'unité F5 BIG-IP à IBM Cloud Private est terminée. Vous pouvez à présent créer des serveurs virtuels et procéder à l'équilibrage de charge des pods directement à partir de l'unité F5 BIG-IP.

Exemple de configuration de création de serveurs virtuels à partir d'IBM Cloud Private

Créez une application nommée myapp dans l'espace de nom surveillé par Kubernetes BIG IP Controller.

kubectl get po -n <release-namespace> -owide | grep myapp

Exemple de résultat obtenu :

NAME          READY   STATUS    RESTARTS   AGE   IP            NODE
myapp-kggt8   1/1     Running   0          1h    10.1.148.66   192.168.70.226
myapp-z5grr   1/1     Running   0          1h    10.1.85.226   192.168.70.227

Créez un service pour exposer votre application.

kubectl get svc -n <release-namespace>

Exemple de résultat obtenu :

NAME      TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE
myapp     ClusterIP   10.0.0.20    <none>        8080/TCP   56s

Créez un objet configmap pour créer un serveur virtuel frontal propre au service et, si besoin, des pools sur le système BIG-IP.

cat f5_configmap.yaml
kind: ConfigMap
apiVersion: v1
metadata:
 name: myapp-vs
 labels:
   f5type: virtual-server
data:
 schema: "f5schemadb://bigip-virtual-server_v0.1.1.json"
 data: |
   {
     "virtualServer": {
       "frontend": {
         "balance": "round-robin",
         "mode": "http",
         "partition": "icp",
         "virtualAddress": {
           "bindAddr": "192.168.60.10",
           "port": 80
         }
       },
       "backend": {
         "serviceName": "myapp",
         "servicePort": 8080
       }
     }
   }

Vérifiez que l'objet configmap est créé :

kubectl get cm -n <release-namespace>

Exemple de résultat obtenu :

NAME                        DATA      AGE
myapp-vs                    2         2s

Une fois l'objet configmap créé, les serveurs virtuels et les pools sont visibles sur l'unité F5 BIG-IP. Ouvrez l'interface utilisateur d'unité F5 BIG-IP et recherchez les emplacements suivants :
- Pour les serveurs virtuels, accédez à F5 BIG-IP UI > <Partition Name> > Local Traffic > Virtual Servers.
- Pour les pools, accédez à F5 BIG-IP UI > <Partition Name> > Local Traffic > Pools.

Vérifiez si les demandes émises vers le service font l'objet d'un équilibrage de charge :

Première demande émise vers le service :

 curl 192.168.60.10

Exemple de résultat obtenu :

 Hostname: myapp-kggt8
 Pod Information:
         node name:      192.168.70.226
         pod name:       myapp-kggt8
         pod namespace:  f5
         pod IP: 10.1.148.66

Deuxième demande émise vers le service :

 curl 192.168.60.10

Exemple de résultat obtenu :

 Hostname: myapp-z5grr
 Pod Information:
         node name:      192.168.70.227
         pod name:       myapp-z5grr
         pod namespace:  f5
         pod IP: 10.1.85.226