déployer des applications avec kapp-controller

Publié le : 28/01/2022

kapp-controller est une extension de kapp qui permet d’installer et de mettre à jour vos applications et packages sur vos clusters Kubernetes. Il fait partie de la suite Carvel.

kapp-controller vous laisse le choix de vos outils de configuration et de vos sources de configuration : configurations YAML simples, graphiques Helm, modèles ytt, modèles jsonnet, … chargé depuis un référentiel Git, une archive sur HTTP, un référentiel Helm, etc

Fonctionnement de kapp-controller

On retrouve le même principe de fonctionnement que les systèmes de packages Linux (apt, yum, …). En effet, kapp-controller décompose l’installation d’un package d’une application en trois étapes :

Fetch : récupération des définitions des sources de l’application depuis le package repository.
Template: applications des valeurs fournies par l’utilisateur pour personnaliser le logiciel en utilisant des templates ytt, helm, …
Deploy : création ou mise à jour des ressources sur le cluster

kapp-controller utilise des images crées avec l’outil de la suite Carvel répondant au nom de imgpkg. Nous en verrons l’utilisation plus bas dans le tutoriel.

Installation de kapp-controller sur votre cluster

Pour notre tutoriel je vais avoir besoin d’une registry docker. Je la crée en locale :

docker run -d -p 5000:5000 --restart=always --name registry registry:2
export REPO_HOST="`ifconfig | grep -A1 docker | grep inet | cut -f10 -d' '`:5000"
echo $REPO_HOST
172.17.0.1:5000

L’installation de kapp-controller se fait simplement avec kapp. Pour ce tutoriel j’ai utilisé un cluster créé avec kind.

kapp deploy -a kc -f https://github.com/vmware-tanzu/carvel-kapp-controller/releases/latest/download/release.yml
Target cluster 'https://127.0.0.1:38717' (nodes: master1, 1+)

Apps in all namespaces

Namespace  Name  Namespaces                             Lcs   Lca
default    kc    (cluster),kapp-controller,kube-system  true  15m

Lcs: Last Change Successful
Lca: Last Change Age

1 apps

Un pti coup d’inspect :

kapp inspect -a kc --tree
Target cluster 'https://127.0.0.1:38717' (nodes: master1, 1+)

Resources in app 'kc'

Namespace        Name                                                    Kind                      Owner    Conds.  Rs  Ri  Age
(cluster)        pkg-apiserver:system:auth-delegator                     ClusterRoleBinding        kapp     -       ok  -   17m
(cluster)        kapp-controller-cluster-role                            ClusterRole               kapp     -       ok  -   17m
(cluster)        kapp-controller-cluster-role-binding                    ClusterRoleBinding        kapp     -       ok  -   17m
(cluster)        internalpackagemetadatas.internal.packaging.carvel.dev  CustomResourceDefinition  kapp     2/2 t   ok  -   17m
kube-system      pkgserver-auth-reader                                   RoleBinding               kapp     -       ok  -   17m
kapp-controller  packaging-api                                           Service                   kapp     -       ok  -   17m
kapp-controller   L packaging-api                                        Endpoints                 cluster  -       ok  -   17m
kapp-controller   L packaging-api-rmftl                                  EndpointSlice             cluster  -       ok  -   17m
(cluster)        internalpackages.internal.packaging.carvel.dev          CustomResourceDefinition  kapp     2/2 t   ok  -   17m
(cluster)        packageinstalls.packaging.carvel.dev                    CustomResourceDefinition  kapp     2/2 t   ok  -   17m
(cluster)        v1alpha1.data.packaging.carvel.dev                      APIService                kapp     1/1 t   ok  -   17m
(cluster)        packagerepositories.packaging.carvel.dev                CustomResourceDefinition  kapp     2/2 t   ok  -   17m
(cluster)        kapp-controller-packaging-global                        Namespace                 kapp     -       ok  -   17m
kapp-controller  kapp-controller-sa                                      ServiceAccount            kapp     -       ok  -   17m
(cluster)        apps.kappctrl.k14s.io                                   CustomResourceDefinition  kapp     2/2 t   ok  -   17m
(cluster)        kapp-controller                                         Namespace                 kapp     -       ok  -   17m
kapp-controller  kapp-controller                                         Deployment                kapp     2/2 t   ok  -   17m
kapp-controller   L kapp-controller-79bd7d495                            ReplicaSet                cluster  -       ok  -   17m
kapp-controller   L.. kapp-controller-79bd7d495-c4jbh                    Pod                       cluster  4/4 t   ok  -   17m
kapp-controller   L kapp-controller-79bd7d495-c4jbh                      PodMetrics                cluster  -       ok  -   0s

Rs: Reconcile state
Ri: Reconcile information

20 resources

On voit tout ce qui a été déployé pour kapp-controller :

des CRD : internalpackagemetadatas.internal.packaging.carvel.dev, internalpackages.internal.packaging.carvel.dev, packageinstalls.packaging.carvel.dev, apps.kappctrl.k14s.io et packagerepositories.packaging.carvel.dev
une API : v1alpha1.data.packaging.carvel.dev
un namespace : kapp-controller
un Service Account : kapp-controller-sa
un deployment : kapp-controller

Déployer une application avec kapp-controller

Je reprends les mêmes exemples fournis sur le projet de kapp ↗.

cd /tmp
git clone https://github.com/vmware-tanzu/carvel-simple-app-on-kubernetes
cd config-step-2-template

Notre exemple se trouve dans le répertoire config-step-2-template où on y retrouve deux fichiers au format ytt, c’est-à-dire un template :

config.yaml : qui définit un service et un deployment
values.yml : qui contient les valeurs qui seront appliquées par ytt

Pour ceux qui ne connaissent pas le langage de template ytt je vous renvoie à mon billet.

Création du package de l’application avec imgpkg

Nous allons utiliser imgpgk pour construire notre package d’application et pour le pousser dans la registry locale.

Nous allons créer la structure qui contiendra notre package d’application et y déposer les fichiers nécessaires :

mkdir -p package-contents/config/
cp config.yml package-contents/config/config.yml
cp values.yml package-contents/config/values.yml
mkdir -p package-contents/.imgpkg

imgpkg utilise d’un répertoire .imgpkg pour y déposer ses définitions. On peut y retrouver deux fichiers : bundle.yml qui contient des métadatas (optionnel) et images.yml qui référence les images utilisées dans le package.

Pour construire ces images, nous allons utiliser kbld qui offre cette fonctionnalité. Pour rappel, kbld scrute les metadatas d’une ressource kubernetes pour y retrouver les images utilisées par les pods pour les rendre immutable en lui accolant un SHA. Ici ce SHA existe déjà, regardez le contenu du fichier config.yml. Supprimez le avant et vous verrez il l’ajoutera.

kbld -f package-contents/config/ --imgpkg-lock-output package-contents/.imgpkg/images.yml

resolve | final: docker.io/dkalinin/k8s-simple-app -> index.docker.io/dkalinin/k8s-simple-app@sha256:4c8b96d4fffdfae29258d94a22ae4ad1fe36139d47288b8960d9958d1e63a9d0
---
simple-app: ""
---
apiVersion: v1
kind: Service
metadata:
  name: simple-app
  namespace: default
spec:
  ports:
  - port: null
    targetPort: null
  selector: null
---
apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    kbld.k14s.io/images: |
      - origins:
        - resolved:
            tag: latest
            url: docker.io/dkalinin/k8s-simple-app
        url: index.docker.io/dkalinin/k8s-simple-app@sha256:4c8b96d4fffdfae29258d94a22ae4ad1fe36139d47288b8960d9958d1e63a9d0
  name: simple-app
  namespace: default
spec:
  selector:
    matchLabels: null
  template:
    metadata:
      labels: null
    spec:
      containers:
      - env:
        - name: HELLO_MSG
          value: null
        image: index.docker.io/dkalinin/k8s-simple-app@sha256:4c8b96d4fffdfae29258d94a22ae4ad1fe36139d47288b8960d9958d1e63a9d0
        name: simple-app
---
app_port: 80
hello_msg: stranger
svc_port: 80

Que contient ce fichier images.yml :

---
apiVersion: imgpkg.carvel.dev/v1alpha1
images:
- annotations:
    kbld.carvel.dev/id: docker.io/dkalinin/k8s-simple-app
    kbld.carvel.dev/origins: |
      - resolved:
          tag: latest
          url: docker.io/dkalinin/k8s-simple-app
  image: index.docker.io/dkalinin/k8s-simple-app@sha256:4c8b96d4fffdfae29258d94a22ae4ad1fe36139d47288b8960d9958d1e63a9d0
kind: ImagesLock

Maintenant poussons l’image dans la registry avec imgpkg :

imgpkg push -b ${REPO_HOST}/packages/simple-app:1.0.0 -f package-contents/
dir: .
dir: .imgpkg
file: .imgpkg/images.yml
dir: config
file: config/config.yml
file: config/values.yml
Pushed '172.17.0.1:5000/packages/simple-app@sha256:fe88086f7737e1bf834786856edb2bab5e153dc470479b114e58174763472145'
Succeeded

Vérifions ce que contient notre registry locale :

curl ${REPO_HOST}/v2/_catalog
{"repositories":["packages/simple-app"]}

On a bien notre image.

Création des définitions de notre application

Pour déployer notre application avec kapp-controller nous devons définir deux objets : un Package et un PackageMetadata.

Commençons par le PackageMetadata :

cat > metadata.yml << EOF
apiVersion: data.packaging.carvel.dev/v1alpha1
kind: PackageMetadata
metadata:
  # This will be the name of our package
  name: simple-app.corp.com
spec:
  displayName: "Simple App"
  longDescription: "Simple app consisting of a k8s deployment and service"
  shortDescription: "Simple app for demoing"
  categories:
  - demo
EOF

Il ne contient comme attendu que des metadatas qui sera utilisé par kapp-controller lors du fetch.

Ensuite créons la déclaration du Package. Nous allons utiliser ytt comme système de template et donc nous allons devoir créer une ressource de type schema au format openAPI :

ytt -f values.yml --data-values-schema-inspect -o openapi-v3 > schema-openapi.yml

Vérifions ce qu’il contient :

openapi: 3.0.0
info:
  version: 0.1.0
  title: Schema for data values, generated by ytt
paths: {}
components:
  schemas:
    dataValues:
      nullable: true
      default: null

Créons maintenant le package :

cat > package-template.yml << EOF
#@ load("@ytt:data", "data")  # for reading data values (generated via ytt's data-values-schema-inspect mode).
#@ load("@ytt:yaml", "yaml")  # for dynamically decoding the output of ytt's data-values-schema-inspect
---
apiVersion: data.packaging.carvel.dev/v1alpha1
kind: Package
metadata:
  name: #@ "simple-app.corp.com." + data.values.version
spec:
  refName: simple-app.corp.com
  version: #@ data.values.version
  releaseNotes: |
        Initial release of the simple app package
  valuesSchema:
    openAPIv3: #@ yaml.decode(data.values.openapi)["components"]["schemas"]["dataValues"]
  template:
    spec:
      fetch:
      - imgpkgBundle:
          image: #@ "${REPO_HOST}/packages/simple-app:" + data.values.version
      template:
      - ytt:
          paths:
          - "config/"
      - kbld:
          paths:
          - "-"
          - ".imgpkg/images.yml"
      deploy:
      - kapp: {}
EOF

Vous allez me dire “outch” bien difficile à comprendre. Attendez ça va s’éclaircir par la suite. Ça me rappelle la première fois ou j’ai du créer un package yum.

Création du Package Repository

Pour rappel, Un Package Repository est l’endroit où nous allons déposer nos applications et ses metadatas et dans lequel kapp-controller vient puiser pour les déployer.

Commençons par créer les répertoires nécessaires :

ll
total 16K
-rw-r--r--. 1 vagrant vagrant 639 Jan 28 08:45 config.yml
-rw-r--r--. 1 vagrant vagrant 325 Jan 28 09:09 metadata.yml
-rw-r--r--. 1 vagrant vagrant 178 Jan 28 09:03 schema-openapi.yml
-rw-r--r--. 1 vagrant vagrant  64 Jan 27 06:48 values.yml

mkdir -p my-pkg-repo/.imgpkg my-pkg-repo/packages/simple-app.corp.com

Lançons la création du package avec ytt en indiquant la version que nous voulons créer :

ytt -f package-template.yml --data-value-file openapi=schema-openapi.yml -v version="1.0.0" > my-pkg-repo/packages/simple-app.corp.com/1.0.0.yml
cat my-pkg-repo/packages/simple-app.corp.com/1.0.0.yml

apiVersion: data.packaging.carvel.dev/v1alpha1
kind: Package
metadata:
  name: simple-app.corp.com.1.0.0
spec:
  refName: simple-app.corp.com
  version: 1.0.0
  releaseNotes: |
    Initial release of the simple app package
  valuesSchema:
    openAPIv3:
      nullable: true
      default: null
  template:
    spec:
      fetch:
      - imgpkgBundle:
          image: 172.17.0.1:5000/packages/simple-app:1.0.0
      template:
      - ytt:
          paths:
          - config/
      - kbld:
          paths:
          - '-'
          - .imgpkg/images.yml
      deploy:
      - kapp: {}

Un petit coup de kbld pour créer notre image de repo :

kbld -f my-pkg-repo/packages/ --imgpkg-lock-output my-pkg-repo/.imgpkg/images.yml

resolve | final: 172.17.0.1:5000/packages/simple-app:1.0.0 -> 172.17.0.1:5000/packages/simple-app@sha256:fe88086f7737e1bf834786856edb2bab5e153dc470479b114e58174763472145
---
apiVersion: data.packaging.carvel.dev/v1alpha1
kind: Package
metadata:
  annotations:
    kbld.k14s.io/images: |
      - origins:
        - resolved:
            tag: 1.0.0
            url: 172.17.0.1:5000/packages/simple-app:1.0.0
        url: 172.17.0.1:5000/packages/simple-app@sha256:fe88086f7737e1bf834786856edb2bab5e153dc470479b114e58174763472145
  name: simple-app.corp.com.1.0.0
spec:
  refName: simple-app.corp.com
  releaseNotes: |
    Initial release of the simple app package
  template:
    spec:
      deploy:
      - kapp: {}
      fetch:
      - imgpkgBundle:
          image: 172.17.0.1:5000/packages/simple-app@sha256:fe88086f7737e1bf834786856edb2bab5e153dc470479b114e58174763472145
      template:
      - ytt:
          paths:
          - config/
      - kbld:
          paths:
          - '-'
          - .imgpkg/images.yml
  valuesSchema:
    openAPIv3:
      default: null
      nullable: true
  version: 1.0.0
---
apiVersion: data.packaging.carvel.dev/v1alpha1
kind: PackageMetadata
metadata:
  name: simple-app.corp.com
spec:
  categories:
  - demo
  displayName: Simple App
  longDescription: Simple app consisting of a k8s deployment and service
  shortDescription: Simple app for demoing

Succeeded

Normalement on doit retrouver le fichier images.yml dans le répertoire .imgpkg

cat  my-pkg-repo/.imgpkg/images.yml

---
apiVersion: imgpkg.carvel.dev/v1alpha1
images:
- annotations:
    kbld.carvel.dev/id: 172.17.0.1:5000/packages/simple-app:1.0.0
    kbld.carvel.dev/origins: |
      - resolved:
          tag: 1.0.0
          url: 172.17.0.1:5000/packages/simple-app:1.0.0
  image: 172.17.0.1:5000/packages/simple-app@sha256:fe88086f7737e1bf834786856edb2bab5e153dc470479b114e58174763472145
kind: ImagesLock

Poussons notre repository dans la registry :

imgpkg push -b ${REPO_HOST}/packages/my-pkg-repo:1.0.0 -f my-pkg-repo
dir: .
dir: .imgpkg
file: .imgpkg/images.yml
dir: packages
dir: packages/simple-app.corp.com
file: packages/simple-app.corp.com/1.0.0.yml
file: packages/simple-app.corp.com/metadata.yml
Pushed '172.17.0.1:5000/packages/my-pkg-repo@sha256:55104b57562a354cb9b5c5ed537fdc221a2c94f575b18dea6b60fa7951b2dee0'
Succeeded
curl ${REPO_HOST}/v2/_catalog

{"repositories":["packages/my-pkg-repo","packages/simple-app"]}

Déploiement du repository sur le cluster

Pour le moment nous avons préparé le terrain en créant toutes les images : celle du package de l’application et celle du repository. Maintenant il faut créer le repository physiquement au sein du cluster. Pour cela il faut utiliser la CRD PackageRepository :

cat > repo.yml << EOF
---
apiVersion: packaging.carvel.dev/v1alpha1
kind: PackageRepository
metadata:
  name: simple-package-repository
spec:
  fetch:
    imgpkgBundle:
      image: ${REPO_HOST}/packages/my-pkg-repo:1.0.0
EOF

Pour le déployer nous allons utiliser kapp qui va nous permettre de voir ce qui se passe :

kapp deploy -a repo -f repo.yml -y

Target cluster 'https://127.0.0.1:38717' (nodes: kind-control-plane)

Changes

Namespace  Name                       Kind               Conds.  Age  Op      Op st.  Wait to    Rs  Ri
default    simple-package-repository  PackageRepository  -       -    create  -       reconcile  -   -

Op:      1 create, 0 delete, 0 update, 0 noop, 0 exists
Wait to: 1 reconcile, 0 delete, 0 noop

9:38:20AM: ---- applying 1 changes [0/1 done] ----
9:38:20AM: create packagerepository/simple-package-repository (packaging.carvel.dev/v1alpha1) namespace: default
9:38:20AM: ---- waiting on 1 changes [0/1 done] ----
9:38:20AM: ongoing: reconcile packagerepository/simple-package-repository (packaging.carvel.dev/v1alpha1) namespace: default
9:38:20AM:  ^ Waiting for generation 1 to be observed
9:38:21AM: ongoing: reconcile packagerepository/simple-package-repository (packaging.carvel.dev/v1alpha1) namespace: default
9:38:21AM:  ^ Reconciling
9:38:22AM: ok: reconcile packagerepository/simple-package-repository (packaging.carvel.dev/v1alpha1) namespace: default
9:38:22AM: ---- applying complete [1/1 done] ----
9:38:22AM: ---- waiting complete [1/1 done] ----

Succeeded

On en sort avec succès. Mais que se passe-t-il ? Nous application est-elle déjà déployée ? Non, car nous avons juste créé le repository.

Utilisons la commande kubectl pour voir ce que nous affiche la ressource PackageRepository que nous venons de créer :

kubectl get packagerepository
NAME                        AGE     DESCRIPTION
simple-package-repository   6m17s   Reconcile succeeded

Maintenant vérifions ce que contient notre repository :

kubectl get packagemetadatas
NAME                  DISPLAY NAME   CATEGORIES   SHORT DESCRIPTION        AGE
simple-app.corp.com   Simple App     demo         Simple app for demoing   9m41s

On y trouve notre application. Maintenant quelle version de l’application disposons-nous ?

kubectl get packages --field-selector spec.refName=simple-app.corp.com
NAME                        PACKAGEMETADATA NAME   VERSION   AGE
simple-app.corp.com.1.0.0   simple-app.corp.com    1.0.0     11m17s

Notre version 1.0.0. Mais que contient-elle ?

kubectl get package simple-app.corp.com.1.0.0 -o yaml

apiVersion: data.packaging.carvel.dev/v1alpha1
kind: Package
metadata:
  annotations:
    kapp.k14s.io/disable-original: ""
    kapp.k14s.io/disable-wait: ""
    kapp.k14s.io/identity: v1;default/data.packaging.carvel.dev/Package/simple-app.corp.com.1.0.0;data.packaging.carvel.dev/v1alpha1
    kbld.k14s.io/images: |
      - origins:
        - resolved:
            tag: 1.0.0
            url: 172.17.0.1:5000/packages/simple-app:1.0.0
        - preresolved:
            url: 172.17.0.1:5000/packages/simple-app@sha256:fe88086f7737e1bf834786856edb2bab5e153dc470479b114e58174763472145
        url: 172.17.0.1:5000/packages/simple-app@sha256:fe88086f7737e1bf834786856edb2bab5e153dc470479b114e58174763472145
  creationTimestamp: "2022-01-28T10:41:22Z"
  generation: 1
  labels:
    kapp.k14s.io/app: "1643366480557105100"
    kapp.k14s.io/association: v1.fc22fec9fc12e7d2a6c2562942b75674
  name: simple-app.corp.com.1.0.0
  namespace: default
  resourceVersion: "7383"
  uid: 3375ab8b-adb5-45b3-aec2-f9be67c1a7cc
spec:
  refName: simple-app.corp.com
  releaseNotes: |
    Initial release of the simple app package
  releasedAt: null
  template:
    spec:
      deploy:
      - kapp: {}
      fetch:
      - imgpkgBundle:
          image: 172.17.0.1:5000/packages/simple-app@sha256:fe88086f7737e1bf834786856edb2bab5e153dc470479b114e58174763472145
      template:
      - ytt:
          paths:
          - config/
      - kbld:
          paths:
          - '-'
          - .imgpkg/images.yml
  valuesSchema:
    openAPIv3:
      default: null
      nullable: true
  version: 1.0.0

Tout simplement toutes les informations nécessaires à son déploiement : les phases : fetch, template et deploy.

Déploiement de l’application sur le cluster

Maintenant que nous avons notre repository d’applications contenant notre application, voyons comment la déployer. Comme pour les autres phases un yaml est nécessaire (IAC bien) :

cat > pkginstall.yml << EOF
---
apiVersion: packaging.carvel.dev/v1alpha1
kind: PackageInstall
metadata:
  name: pkg-demo
spec:
  serviceAccountName: default-ns-sa
  packageRef:
    refName: simple-app.corp.com
    versionSelection:
      constraints: 1.0.0
  values:
  - secretRef:
      name: pkg-demo-values
---
apiVersion: v1
kind: Secret
metadata:
  name: pkg-demo-values
stringData:
  values.yml: |
    ---
    hello_msg: "to all my katacoda friends"
EOF

On y retrouve l’appel à la référence CRD packageinstalls qui utilise une spec de type packageRef qui indique le nom du package (refname) et sa version à utiliser :

  packageRef:
    refName: simple-app.corp.com
    versionSelection:
      constraints: 1.0.0

Vous avez certainement remarqué la création d’un secret qui vient définir le fichier “values.yml” utilisé par le package et d’un service account qu’il faut déployer avant.

kapp deploy -a default-ns-rbac -f https://raw.githubusercontent.com/vmware-tanzu/carvel-kapp-controller/develop/examples/rbac/default-ns.yml -y

Déployons maintenant notre application :

kapp deploy -a pkg-demo -f pkginstall.yml -y

Si comme moi la première fois vous avez des erreurs la commande kapp inspect avec l’option --status vous indiquera la cause :

kapp inspect -a pkg-demo --status
Target cluster 'https://127.0.0.1:38717' (nodes: kind-control-plane)

Resources in app 'pkg-demo'

Namespace  default
Name       pkg-demo
Kind       PackageInstall
Status     conditions:
           - message: Error (see .status.usefulErrorMessage for details)
             status: "True"
             type: ReconcileFailed
           friendlyDescription: 'Reconcile failed: Error (see .status.usefulErrorMessage for
             details)'
           lastAttemptedVersion: 1.0.0
           observedGeneration: 2
           usefulErrorMessage: |
             ytt: Error: Checking file '/etc/kappctrl-mem-tmp/kapp-controller-fetch-template-deploy3698766503/0/config': lstat /etc/kappctrl-mem-tmp/kapp-controller-fetch-template-deploy3698766503/0/config: no such file or directory
           version: 1.0.0

Namespace  default
Name       pkg-demo-values
Kind       Secret
Status     -

2 resources

Succeeded

Une fois corrigé, dans mon cas, j’avais oublié le fichier de config dans le package de l’application on peut vérifier que notre application est bien déployé.

Target cluster 'https://127.0.0.1:38717' (nodes: kind-control-plane)

Resources in app 'pkg-demo'

Namespace  Name             Kind            Owner  Conds.  Rs  Ri  Age
default    pkg-demo         PackageInstall  kapp   1/1 t   ok  -   6m
^          pkg-demo-values  Secret          kapp   -       ok  -   6m

Rs: Reconcile state
Ri: Reconcile information

2 resources

Succeeded

kubectl get deployments.apps simple-app
NAME         READY   UP-TO-DATE   AVAILABLE   AGE
simple-app   1/1     1            1           7m31s

kubectl get pod
default              simple-app-58fb574f5c-55nl4                  1/1     Running   0          7m3s

kubectl get service
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.96.0.1    <none>        443/TCP   75m
simple-app   ClusterIP   10.96.0.46   <none>        80/TCP    8m32s

docker exec -it kind-control-plane bash
root@kind-control-plane:/# curl http://10.96.0.46
<h1>Hello to all my katacoda friends!</h1>

Notre application est bien déployée et fonctionne.

Conclusion

Franchement j’en sors content, car j’ai bien compris le principe. Mais je me pose quelques questions comme :

Est-il possible d’utiliser des repos externes ? Car tout mettre dans le même cluster n’est pas dans mes principes.
Le debug de la partie déploiement est-il facile ? Là, je m’en suis sorti, mais dans des cas plus complexes ???
Comment industrialiser tout ça ?
Comment l’utiliser avec une démarche GitOps ? Car pour le moment je n’ai pas vu trace d’utilisation de repository git.

Voilà ça demande encore un peu de travail pour l’adopter comme gestionnaire d’applications. Et vous donnez moi en commentaires vos réflexions.

Dans le repo git de la version community edition de Tangzu ↗ on retrouve une vingtaine d’applications utilisant kapp-controller.

Source ↗