premier jet article bug-okd-rook-ceph
This commit is contained in:
49
articles/sre/doc.md
Normal file
49
articles/sre/doc.md
Normal file
@@ -0,0 +1,49 @@
|
||||
|
||||
## Message de will ds affilium
|
||||
https://discord.com/channels/874270880975450112/1291867776310579221/1441782992258207846
|
||||
|
||||
Bonjour,
|
||||
Hier, on a finalement réussi à régler l’erreur de création d’IPAddress qui tournait en boucle.
|
||||
Au final, c’était un bug connu avec OCP 4.20 et Ceph.
|
||||
L’info est ici :
|
||||
https://github.com/okd-project/okd/issues/2280
|
||||
|
||||
En gros, le problème était :
|
||||
-Après l’upgrade vers 4.20, le ipallocator-repair-controller créait des IPAddress dans le namespace `default`
|
||||
-Leur spec.parentRef pointait vers des Services dans le namespace `rook-ceph`
|
||||
- Les références cross-namespace ne sont pas permises, donc l’opérateur les supprimait immédiatement
|
||||
- Ce qui créait une boucle infinie
|
||||
- L’erreur alternait entre rook-ceph-mgr-dashboard et rook-ceph-mgr selon lequel était actif
|
||||
- Aucun Service Ceph n’existait dans `default`, mais des IPAddress y étaient quand même créés avec un ref vers `rook-ceph`
|
||||
|
||||
L’application des ressources ci-dessous a réglé le problème :
|
||||
```
|
||||
apiVersion: admissionregistration.k8s.io/v1
|
||||
kind: ValidatingAdmissionPolicy
|
||||
metadata:
|
||||
name: deny-ceph-ipaddress-in-default
|
||||
spec:
|
||||
matchConditions:
|
||||
- name: is-default-ns
|
||||
expression: 'object.metadata.namespace == "default"'
|
||||
- name: parent-is-ceph
|
||||
expression: 'object.spec.parentRef.namespace == "rook-ceph" && (object.spec.parentRef.name == "rook-ceph-mgr" || object.spec.parentRef.name == "rook-ceph-mgr-dashboard")'
|
||||
validations:
|
||||
- expression: 'false'
|
||||
message: 'IPAddress for Ceph service must not be created in default; cross-namespace parentRef is invalid.'
|
||||
failurePolicy: Fail
|
||||
matchConstraints:
|
||||
resourceRules:
|
||||
- apiGroups: ["networking.k8s.io"]
|
||||
apiVersions: ["v1"]
|
||||
operations: ["CREATE"]
|
||||
resources: ["ipaddresses"]
|
||||
---
|
||||
apiVersion: admissionregistration.k8s.io/v1
|
||||
kind: ValidatingAdmissionPolicyBinding
|
||||
metadata:
|
||||
name: deny-ceph-ipaddress-in-default-binding
|
||||
spec:
|
||||
policyName: deny-ceph-ipaddress-in-default
|
||||
validationActions: ["Deny"]
|
||||
```
|
||||
79
articles/sre/rook-ceph-conflict/text-fr.md
Normal file
79
articles/sre/rook-ceph-conflict/text-fr.md
Normal file
@@ -0,0 +1,79 @@
|
||||
# Junior: je suis bon, j'ai trouvé le problème rapidement de régler les problèmes rapidementavec Harmony
|
||||
TLDR: OKD permet presque de dormir sur la job (émoji rire) sauf... quand il y a un bug d'intégration (émoji oups!). Harmony nous apporte la confiance que ça n'arrivera pas dans notre compagnie (emoji musique)
|
||||
Allez direct à la section technique. =>
|
||||
|
||||
|
||||
En choisisant OKD comme fondation Cloud entreprise, on ne se trompe pas! La vie d'ingénieur en fiabilité est tranquille.
|
||||
On peut gérer sans encombre une ~~shitload~~ tonne de services, des vms avec migration entre node sans interruption, des BD, en veux-tu, en v'là! Et tout ça en multisite. Facile! Merci Kubernetes pour la superbe capacité d'abstraction du matériel.
|
||||
|
||||
Et le stockage n'est pas en reste. Peut-être avez eu la ~~bordel~~ chance d'installer et de gérer un cluster ceph avec le playbook (`ceph-ansible`)? C'est certainement mieux qu'un script bash pour obtenir un cluster de stockage performant, scalable, High Availability, sans single point of failure et assez souplesse pour prendre en charge autant vos stockage block, object et file! Alors on peut se dire que ça vaut la peine de se donner tout ce mal!
|
||||
|
||||
Mais pourquoi se donner tout ce mal? Ansible gère bien le déploiement multi-site, mais... c'est à peu près tout (émoji de déception). Kubernetes prend en charge la synchronisation de l'ensemble des nodes et la gestion dynamique des ressources, potentiellement tout au long de leur cycle de vie. Et OKD, ajoute une robustesse lors des migrations qui rend le tout vraiment
|
||||
|
||||
## IPPAddress has a wrong reference... cleaning up!
|
||||
|
||||
|
||||
## Spoiler: ajouter ce manifest lors de la migration
|
||||
|
||||
- Dans quelle situation peut-on suspecter le problème
|
||||
- Comment se manifeste le problème?... ralentissament?
|
||||
- Comment diagnostiquer
|
||||
|
||||
Si vous rencon
|
||||
|
||||
```
|
||||
apiVersion: admissionregistration.k8s.io/v1
|
||||
kind: ValidatingAdmissionPolicy
|
||||
metadata:
|
||||
name: deny-ceph-ipaddress-in-default
|
||||
spec:
|
||||
matchConditions:
|
||||
- name: is-default-ns
|
||||
expression: 'object.metadata.namespace == "default"'
|
||||
- name: parent-is-ceph
|
||||
expression: 'object.spec.parentRef.namespace == "rook-ceph" && (object.spec.parentRef.name == "rook-ceph-mgr" || object.spec.parentRef.name == "rook-ceph-mgr-dashboard")'
|
||||
validations:
|
||||
- expression: 'false'
|
||||
message: 'IPAddress for Ceph service must not be created in default; cross-namespace parentRef is invalid.'
|
||||
failurePolicy: Fail
|
||||
matchConstraints:
|
||||
resourceRules:
|
||||
- apiGroups: ["networking.k8s.io"]
|
||||
apiVersions: ["v1"]
|
||||
operations: ["CREATE"]
|
||||
resources: ["ipaddresses"]
|
||||
---
|
||||
apiVersion: admissionregistration.k8s.io/v1
|
||||
kind: ValidatingAdmissionPolicyBinding
|
||||
metadata:
|
||||
name: deny-ceph-ipaddress-in-default-binding
|
||||
spec:
|
||||
policyName: deny-ceph-ipaddress-in-default
|
||||
validationActions: ["Deny"]
|
||||
```
|
||||
|
||||
## Reproduire le problème
|
||||
|
||||
|
||||
## Faites évolué vos infras et vos plateformes en toute Harmony (emoji de musique)
|
||||
|
||||
En tant qu'opérateur d'infrastructure multisite auto-hébegé, on ne pouvait pas se permettre de gérer des alertes et d'avoir à intervenir manuellement à chaque migration. C'est une réalité dans un système aussi complexe qui a autant d'interdépendances comme OKD et l'écosystème d'intégration helm, opérateurs, plugin, etc. La combinatoire est implacable... un jour ou l'autre ça va briser. Et dans c'est moments là, NationTech intervient avec efficacité remettre en état vos services critique.
|
||||
|
||||
Mais on veut le faire le moins souvent possible. Parce qu'on a d'autre chose à faire. On préfère coder le futur que de biller de la résolution de bugs (émoji fusée).
|
||||
|
||||
C'est ça qui nous a poussé à développement Harmony, un outil de gestion Cloud as a Service qui peu reproduire à l'identique l'ensemble de votre Cloud, autant les couches matériels, réseau, les intégrations de services plateforme et même l'applicatif. À partir d'une topologie, vous pouvez décrire l'ensemble de votre système d'entreprise et tout remonté en quelques heures pour faire des tests de charge, de robustesse ou de migration à l'échelle du Cloud entier! Je vous mets au défi de trouver une autre techno qui permet de faire ça.
|
||||
|
||||
On peut également repoduire uniquement un Cluster HA OKD en quelques heures et y tester vos migrations pour y repérer les problèmes non trivial.
|
||||
|
||||
Prochaine étape de développement pour Harmony, inclure les migrations dans la mécanique de Harmony afin de:
|
||||
- identifier des problèmes en amont (par exemple, des incompatibilités de version de driver comme avec le nvidia-gpu-operator),
|
||||
- apporter une garantie supplémentaire en utilisant des transitions pré-testées par la communauté
|
||||
|
||||
Ça nous donne le luxe de pouvoir tester
|
||||
|
||||
|
||||
## Questions pour Will
|
||||
|
||||
- c'est quoi le contexte, à quelle moment ça a commencé. Pourquoi?
|
||||
|
||||
|
||||
Reference in New Issue
Block a user