{"id":3305,"date":"2026-10-11T20:37:15","date_gmt":"2026-10-11T18:37:15","guid":{"rendered":"https:\/\/djimn.com\/?p=3305"},"modified":"2026-10-11T20:37:15","modified_gmt":"2026-10-11T18:37:15","slug":"aislar-pro-y-pre-en-el-mismo-cluster-de-openshift-sin-sustos","status":"publish","type":"post","link":"https:\/\/djimn.com\/index.php\/2026\/10\/11\/aislar-pro-y-pre-en-el-mismo-cluster-de-openshift-sin-sustos\/","title":{"rendered":"Aislar PRO y PRE en el mismo cluster de OpenShift sin sustos"},"content":{"rendered":"<p dir=\"ltr\">Compartir un mismo cluster de OpenShift entre varios entornos, por ejemplo producci\u00f3n y preproducci\u00f3n, es habitual cuando no hay presupuesto o infraestructura para clusters separados. Si el aislamiento no est\u00e1 bien pensado, tambi\u00e9n es una fuente cl\u00e1sica de incidentes silenciosos.<\/p>\n<p dir=\"ltr\">Mi primer intento para separar cargas por entorno fue con taints: marcar los nodos de un entorno como \u201cno tolerado\u201d para el otro. Sobre el papel sonaba limpio. En la pr\u00e1ctica, rompi\u00f3 la programaci\u00f3n de varios DaemonSets que necesitaban correr en todos los nodos fuera cual fuera el entorno, y tuve que revertirlo.<\/p>\n<p dir=\"ltr\">El enfoque que s\u00ed funcion\u00f3 fue m\u00e1s simple de lo que esperaba. Etiquet\u00e9 los nodos por entorno (<code dir=\"ltr\">env=pro<\/code> \/ <code dir=\"ltr\">env=pre<\/code>) y us\u00e9 <code dir=\"ltr\">nodeSelector<\/code> o afinidad en las cargas de trabajo de cada entorno, en vez de intentar bloquear a nivel de scheduler con taints. Es menos elegante, pero mucho m\u00e1s predecible.<\/p>\n<p dir=\"ltr\">Lo que de verdad me hizo priorizar arreglar esto fue lo que encontr\u00e9 al auditar d\u00f3nde estaba corriendo cada cosa. Varias cargas de trabajo \u201cde producci\u00f3n\u201d, incluido un miembro de un replica set de base de datos, estaban corriendo f\u00edsicamente sobre nodos pensados para el otro entorno. Nada estaba ca\u00eddo. Pero si ese nodo hubiera fallado, habr\u00eda afectado al qu\u00f3rum de una base de datos que se supon\u00eda intocable desde el otro entorno.<\/p>\n<p dir=\"ltr\">La lecci\u00f3n no es que los taints sean malos. Es que cualquier estrategia de aislamiento hay que <em>verificarla<\/em>. Que el manifiesto diga <code dir=\"ltr\">env: pro<\/code> en alg\u00fan sitio no garantiza que todo lo que deber\u00eda estar en PRO est\u00e9 f\u00edsicamente en nodos de PRO. Un simple <code dir=\"ltr\">kubectl get pods -A -o wide<\/code> cruzado con las etiquetas de los nodos destapa estas cosas en dos minutos. Merece la pena hacerlo de forma recurrente, no solo la primera vez que se configura.<\/p>\n<p dir=\"ltr\">\u00bfCompart\u00eds cluster entre entornos? \u00bfC\u00f3mo os asegur\u00e1is de que cada carga corre donde debe?<\/p>\n<hr \/>\n<p dir=\"ltr\"><em>Si te interesa el aislamiento y la seguridad en clusters de Kubernetes y OpenShift, lo trato a fondo en mi manual \u201cSeguridad y monitorizaci\u00f3n en Kubernetes\u201d (950 p\u00e1ginas, en espa\u00f1ol). [Echa un vistazo a la muestra gratuita]([URL de la muestra]) \u00b7 <a href=\"https:\/\/4016705366609.gumroad.com\/l\/seguridad-kubernetes?wanted=true\">Consigue el manual completo<\/a><\/em><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Compartir un mismo cluster de OpenShift entre varios entornos, por ejemplo producci\u00f3n y preproducci\u00f3n, es habitual cuando no hay presupuesto o infraestructura para clusters separados. Si el aislamiento no est\u00e1 bien pensado, tambi\u00e9n es una fuente cl\u00e1sica de incidentes silenciosos. Mi primer intento para separar cargas por entorno fue con taints: marcar los nodos de [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":3307,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_post_was_ever_published":false},"categories":[5],"tags":[60],"class_list":["post-3305","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-tech","tag-arquitecturadesoftware-cloudcomputing-devops-sre-monitorizacion-seguridad-aws-azure-gcp-finops"],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"https:\/\/i0.wp.com\/djimn.com\/wp-content\/uploads\/2026\/10\/aislar-pro-pre-openshift.png?fit=1200%2C630&ssl=1","_links":{"self":[{"href":"https:\/\/djimn.com\/index.php\/wp-json\/wp\/v2\/posts\/3305","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/djimn.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/djimn.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/djimn.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/djimn.com\/index.php\/wp-json\/wp\/v2\/comments?post=3305"}],"version-history":[{"count":1,"href":"https:\/\/djimn.com\/index.php\/wp-json\/wp\/v2\/posts\/3305\/revisions"}],"predecessor-version":[{"id":3306,"href":"https:\/\/djimn.com\/index.php\/wp-json\/wp\/v2\/posts\/3305\/revisions\/3306"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/djimn.com\/index.php\/wp-json\/wp\/v2\/media\/3307"}],"wp:attachment":[{"href":"https:\/\/djimn.com\/index.php\/wp-json\/wp\/v2\/media?parent=3305"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/djimn.com\/index.php\/wp-json\/wp\/v2\/categories?post=3305"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/djimn.com\/index.php\/wp-json\/wp\/v2\/tags?post=3305"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}