OKS & pods
OKS = Kubernetes managé Outscale. Vous dimensionnez cluster et workloads ; Outscale opère le control plane. bige-ops génère specs + manifests — pas votre SRE à la place.
flowchart TB
subgraph oks [OKS — managé Outscale]
CP[Control plane]
NP[Nodepools]
end
subgraph apps [Votre simulation]
DEP[Deployments / Services]
end
CP --- NP
NP --> DEP
DEP -->|replicas formulaire| R[Pods]
App, CLI bige-ops, oks-cli, kubectl
Chemin nominal : app desktop (Visual / Workspace).
Sous le capot (ou en terminal) : la CLI bige-ops — même
moteur. Pour OKS spécifiquement :
apply --target oks→ oks-cli (cluster / nodepools / kubeconfig)deploy→ kubectl apply suroks/apps/
Donc oui, on utilise la CLI pour OKS — pas comme produit terminal-first, mais comme outils kube branchés par bige-ops. Détail : CLI · app · OKS.
Cluster et nœuds
Une topologie oks déclare le cluster, la version kube,
le profil control plane et les nodepools
(type Tina + count). Le formulaire Visual (ou
bige-ops add …) met à jour la simulation
immédiatement ; apply --target oks passe par
oks-cli embarqué.
Pods et réplicas
Les services (api, web, worker, DB…) deviennent Deployments sous
oks/apps/. Le champ réplicas
(service_config.*.replicas) dans l’inspector réécrit le
setup sans questionnaire. Défauts typiques : data / worker ≈ 1,
api / web ≈ 2. Puis deploy applique via kubectl.
Réplicas ≠ exposition réseau : pour
ouvrir ou non un pod / Service, voir
réseau · ouvrir ou non.
service_config:
mongodb:
replicas: 1
api:
replicas: 2
Ce que ça n’est pas
Pas un opérateur Mongo/ES managé, pas un mesh, pas la garantie HA prod sans relecture. Mesh, policies avancées, operators custom : hors kickoff. Quand vous scalez le cluster pour de vrai, vous opérez — périmètre.
Côté machines hors kube : VMs. Data + objet : bases, OOS. CLI vs app : CLI · app · OKS.