{"id":33773,"date":"2019-10-31T21:54:36","date_gmt":"2019-10-31T18:54:36","guid":{"rendered":"https:\/\/prohoster.info\/blog\/rezervirovanie-v-kubernetes-ono-sushhestvuet\/"},"modified":"2019-10-31T21:54:36","modified_gmt":"2019-10-31T18:54:36","slug":"rezervirovanie-v-kubernetes-ono-sushhestvuet","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/rezervirovanie-v-kubernetes-ono-sushhestvuet","title":{"rendered":"Reservas en Kubernetes: existen","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Me llamo Sergey, soy de la empresa ITSumma, y quiero contarles c\u00f3mo abordamos la redundancia en Kubernetes. \u00daltimamente he estado trabajando mucho en consultor\u00eda, implementando diversas soluciones de DevOps para diferentes equipos, y, en particular, he estado trabajando intensamente en proyectos que utilizan K8s. En la conferencia Uptime Day 4, que se dedic\u00f3 a la redundancia en arquitecturas complejas, di una charla sobre la redundancia de 'cubes', y aqu\u00ed est\u00e1 su versi\u00f3n libre. Solo advierto de antemano que no es una gu\u00eda directa de acci\u00f3n, sino m\u00e1s bien un resumen de reflexiones sobre el tema indicado.<\/p>\n

\"Reservas
\n
\nEn principio, la monitorizaci\u00f3n y la redundancia son dos herramientas clave para aumentar la resiliencia de cualquier proyecto. Pero, \u00bfno se equilibran las cosas solas en Kubernetes, dir\u00e1n ustedes, se escalan solas, y si algo sucede, se levantan solas...? Es decir, tras una primera exploraci\u00f3n superficial del tema, la Internet me respondi\u00f3 a la pregunta de c\u00f3mo se aborda la redundancia en K8s con un '\u00bfpor qu\u00e9?'. Muchos piensan que Kubernetes es una cosa m\u00e1gica que elimina todos los problemas de infraestructura y asegura que un proyecto nunca caiga. Pero... el mundo no es lo que parece.
\n<\/a><\/noindex>
\n\u00bfC\u00f3mo abord\u00e1bamos el proceso de redundancia antes? Ten\u00edamos plataformas id\u00e9nticas para el alojamiento, ya sea m\u00e1quinas virtuales o f\u00edsicas servidores<\/a>, a las que aplic\u00e1bamos tres pr\u00e1cticas b\u00e1sicas: <\/p>\n

    \n
  1. sincronizaci\u00f3n de c\u00f3digo y est\u00e1ticos<\/li>\n
  2. sincronizaci\u00f3n de configuraciones<\/li>\n
  3. replicaci\u00f3n de bases de datos<\/li>\n<\/ol>\n

    \nY voil\u00e0: en cualquier momento cambiamos a la plataforma de respaldo, todos felices, nos levantamos y nos vamos. <\/p>\n

    \"Reservas
    \n
    \n\u00bfQu\u00e9 nos proponen para aumentar la disponibilidad constante de nuestra aplicaci\u00f3n de Kubernetes? Lo primero que menciona la documentaci\u00f3n no oficial es tener muchas m\u00e1quinas, establecer muchos maestros \u2014 su n\u00famero debe satisfacer las condiciones para alcanzar el quorum dentro del cl\u00faster, y que en cada uno de los maestros se levante etcd, api, MC, scheduler... Y, aparentemente, todo est\u00e1 maravilloso: si varias nodos de trabajo o maestros fallan, nuestro cl\u00faster se reequilibrar\u00e1 y la aplicaci\u00f3n continuar\u00e1 funcionando. De nuevo, parece magia. Pero a menudo nuestro cl\u00faster se encuentra dentro de un \u00fanico centro de datos, y esto puede plantear ciertas preguntas. \u00bfQu\u00e9 pasa si llega un excavador y cava un cable, un rayo cae, o ocurre un diluvio universal? Todo se destruye, nuestro cl\u00faster ya no existe. \u00bfC\u00f3mo abordar la redundancia teniendo en cuenta este aspecto del problema? <\/p>\n

    En primer lugar, debe tener otro cl\u00faster en caliente, es decir, un cl\u00faster al que pueda conmutar en cualquier momento. Desde el punto de vista de Kubernetes, la infraestructura debe ser completamente id\u00e9ntica. Es decir, si hay algunos complementos no est\u00e1ndar para el sistema de archivos, soluciones personalizadas para ingress, deben ser completamente id\u00e9nticos en sus dos (o tres, o diez, aqu\u00ed depende de cu\u00e1nto dinero y esfuerzo tenga el personal administrativo) cl\u00fasteres. Es necesario definir claramente dos conjuntos de aplicaciones (deployments, statefulsets, daemonsets, cronjobs, etc.): cu\u00e1les de ellas pueden funcionar en la reserva de forma constante y cu\u00e1les es mejor no ejecutar hasta el conmutaci\u00f3n inmediata. <\/p>\n

    \u00bfDeber\u00eda nuestro cl\u00faster de respaldo ser completamente id\u00e9ntico a nuestro cl\u00faster de producci\u00f3n? No. Si antes, al trabajar con proyectos monol\u00edticos y con infraestructura f\u00edsica, manten\u00edamos un entorno pr\u00e1cticamente id\u00e9ntico, en el contexto de Kubernetes, creo que esto no deber\u00eda ser as\u00ed. Analicemos por qu\u00e9.<\/p>\n

    Por ejemplo, comencemos con las entidades b\u00e1sicas de Kubernetes: los deployments, que deben ser id\u00e9nticos. Deben estar en funcionamiento las aplicaciones que, en cualquier momento, pueden interceptar el procesamiento de tr\u00e1fico y permitir que nuestro proyecto contin\u00fae vivo. Si hablamos de archivos de configuraci\u00f3n, aqu\u00ed debemos considerar si deben ser id\u00e9nticos o no. Es decir, si nosotros, personas inteligentes, no consumimos ninguna sustancia prohibida y no mantenemos la base de datos en K8s, entonces en los configmaps deben estar las configuraciones de acceso a la base de datos en producci\u00f3n (el proceso de respaldo de la cual se implementa por separado). Por lo tanto, para asegurar el acceso al recurso de respaldo de la base de datos, debemos tener un archivo de configuraci\u00f3n separado (configmap). De la misma manera trabajamos con los secrets: contrase\u00f1as para acceder a la base de datos, claves API; en cualquier momento, puede estar activo ya sea el secret de producci\u00f3n o el de respaldo. En total, ya tenemos dos entidades de Kubernetes, cuyas versiones de respaldo no deben ser id\u00e9nticas a las de producci\u00f3n. La siguiente entidad en la que debemos detenernos es el cronjob. Los cronjobs en el respaldo no deben ser en ning\u00fan caso id\u00e9nticos al conjunto de cronjobs del cl\u00faster de producci\u00f3n. Si levantamos un cl\u00faster de respaldo y lo activamos completamente con todos los cronjobs habilitados, por ejemplo, las personas recibir\u00e1n dos correos al mismo tiempo en lugar de uno. O bien, alguna sincronizaci\u00f3n de datos con fuentes externas ocurrir\u00e1 dos veces, por lo que comenzamos a enfermarnos, llorar, gritar y discutir. <\/p>\n

    \"Reservas
    \n
    \n\u00bfY c\u00f3mo nos proponen organizar el cl\u00faster de respaldo las personas de internet? La segunda respuesta m\u00e1s popular despu\u00e9s de \"\u00bfy para qu\u00e9?\" es el uso de Kubernetes Federation. <\/p>\n

    \u00bfQu\u00e9 es esto? Es, digamos, un gran meta-cl\u00faster. Si imaginamos la arquitectura de Kubernetes, donde tenemos un maestro y varios nodos, desde el punto de vista de la federaci\u00f3n tambi\u00e9n tenemos un maestro y varios nodos, solo que cada nodo es un cl\u00faster independiente. Es decir, trabajamos con las mismas entidades, con los mismos primitivos que con un solo Kubernetes, solo que en lugar de manejar nuestras m\u00e1quinas f\u00edsicas, manejamos cl\u00fasteres completos. En el marco de la federaci\u00f3n, tenemos una sincronizaci\u00f3n completa de los recursos federativos de los padres a los descendientes. Por ejemplo, si lanzamos un despliegue a trav\u00e9s de la federaci\u00f3n, se desplegar\u00e1 en cada uno de nuestros cl\u00fasteres secundarios. Si tomamos alg\u00fan configmap, secreto, y lo implementamos en la federaci\u00f3n, se propagar\u00e1 a todos nuestros cl\u00fasteres secundarios; adem\u00e1s, la federaci\u00f3n permite personalizar nuestros recursos en los hijos. As\u00ed que tomamos un configmap, lo desplegamos a trav\u00e9s de la federaci\u00f3n y luego, si necesitamos ajustar algo en cl\u00fasteres espec\u00edficos, vamos a corregirlo en un cl\u00faster separado, y ese cambio no se sincronizar\u00e1 en ning\u00fan otro lugar. <\/p>\n

    Kubernetes Federation es una herramienta relativamente nueva que no soporta todo el conjunto de recursos que ofrece K8s. En el momento de la publicaci\u00f3n de una de las primeras versiones de la documentaci\u00f3n, se mencionaba que solo se soportaban los config maps, deployments bajo replica set e ingress. Los secretos no estaban soportados, y la gesti\u00f3n de vol\u00famenes tampoco. Es un conjunto demasiado limitado. Especialmente si nos gusta experimentar, como enviar nuestros propios recursos a Kubernetes a trav\u00e9s de definiciones de recursos personalizadas; en la federaci\u00f3n, no podremos incluirlos. Es como si fuera una soluci\u00f3n muy cercana a la realidad, pero que a veces nos lleva a ponerle obst\u00e1culos a nuestro propio camino. Por otro lado, la federaci\u00f3n permite gestionar nuestro replicaset de manera flexible. Por ejemplo, si queremos que se ejecuten 10 r\u00e9plicas de nuestra aplicaci\u00f3n, la federaci\u00f3n, por defecto, repartir\u00e1 este n\u00famero proporcionalmente entre la cantidad de cl\u00fasteres. \u00a1Y eso se puede configurar! Se puede especificar que en el cl\u00faster principal se deben mantener 6 r\u00e9plicas de nuestra aplicaci\u00f3n, mientras que en el cl\u00faster de reserva, ya sea para ahorrar recursos o por entretenimiento personal, solo se mantendr\u00e1n 4 r\u00e9plicas. Lo cual tambi\u00e9n es bastante conveniente. Pero con la federaci\u00f3n, debemos adoptar algunas soluciones nuevas, desplegar cosas sobre la marcha y pensar un poco m\u00e1s... <\/p>\n

    \u00bfPodemos abordar el proceso de reserva de Kubernetes de una manera m\u00e1s sencilla? \u00bfQu\u00e9 herramientas tenemos disponibles?<\/p>\n

    En primer lugar, siempre tenemos alg\u00fan sistema de CI\/CD, es decir, no tenemos que ir manualmente a los servidores para crear o aplicar configuraciones. El sistema genera archivos YAML para nuestros contenedores. <\/p>\n

    En segundo lugar, tenemos varios cl\u00fasteres; contamos con uno o m\u00e1s (si somos inteligentes) registros que tambi\u00e9n hemos reservado. Y hay una maravillosa utilidad llamada kubectl, que puede trabajar con varios cl\u00fasteres simult\u00e1neamente. <\/p>\n

    \"Reservas
    \n
    \nAs\u00ed que, en mi opini\u00f3n, la soluci\u00f3n m\u00e1s simple y correcta para construir un cl\u00faster de respaldo es un despliegue paralelo primitivo. Hay alg\u00fan pipeline en el sistema ci\/cd; primero construimos nuestros contenedores, los probamos y desplegamos las aplicaciones a trav\u00e9s de kubectl en varios cl\u00fasteres independientes. Podemos realizar despliegues simult\u00e1neos en varios cl\u00fasteres. Por lo tanto, tambi\u00e9n resolvemos la entrega de configuraciones en esta etapa. Se puede definir de antemano un conjunto de configuraciones para nuestro cl\u00faster de producci\u00f3n, un conjunto de configuraciones para el cl\u00faster de respaldo y en el nivel del sistema ci\/cd desplegar el entorno de producci\u00f3n en el cl\u00faster de producci\u00f3n y el entorno de respaldo en el cl\u00faster de respaldo. En comparaci\u00f3n con la federaci\u00f3n, no es necesario ir despu\u00e9s de definir el recurso federado a cada cl\u00faster hijo y redefinir algo. Lo hemos hecho de antemano. \u00a1Qu\u00e9 bien lo hemos hecho!<\/p>\n

    Pero... hay... escribir\u00eda que hay \"una ra\u00edz de todos los males\", pero en realidad son dos. En primer lugar, el sistema de archivos. Hay alg\u00fan PV, o usamos almacenamiento externo. Si almacenamos archivos dentro del cl\u00faster, debemos actuar seg\u00fan las viejas pr\u00e1cticas heredadas de las infraestructuras f\u00edsicas: por ejemplo, sincronizar con lsync. O con cualquier otro tipo de soluci\u00f3n que prefieras. Desplegamos todo en otras m\u00e1quinas y seguimos adelante.<\/p>\n

    En segundo lugar, y de hecho, un punto de tropiezo incluso m\u00e1s importante es la base de datos. Si somos personas inteligentes y no mantenemos la base de datos en Kubernetes, entonces el proceso de respaldo de datos sigue el mismo esquema antiguo: replicaci\u00f3n master-slave, luego el cambio y sincronizaremos la r\u00e9plica y viviremos bien. Pero si mantenemos nuestra DB dentro del cl\u00faster, en principio hay muchas soluciones listas para organizar la misma r\u00e9plica master-slave, muchas soluciones para levantar una DB dentro de Kubernetes.
    \n Ya se han dado mil conferencias sobre la reserva de bases de datos, se han escrito mil art\u00edculos, aqu\u00ed realmente no hay nada nuevo. En general, sigue tus sue\u00f1os, vive como quieras, inventa tambi\u00e9n algunos mecanismos complicados, pero aseg\u00farate de pensar en c\u00f3mo vas a respaldar todo esto.<\/p>\n

    Ahora hablemos de c\u00f3mo, en principio, se llevar\u00e1 a cabo el proceso de conmutaci\u00f3n a un sitio de respaldo en caso de incendio. Primero, estamos desplegando aplicaciones sin estado en paralelo. Estas no afectan la l\u00f3gica empresarial de nuestras aplicaciones, de nuestro proyecto; podemos mantener continuamente dos conjuntos de aplicaciones en funcionamiento, y pueden comenzar a recibir tr\u00e1fico. Es muy importante en el proceso de conmutaci\u00f3n al sitio de respaldo verificar si es necesario redefinir las configuraciones. Por ejemplo, tenemos un cl\u00faster de producci\u00f3n de Kubernetes, hay un cl\u00faster de respaldo de Kubernetes, hay una base de datos maestra externa y hay una base de datos maestra de respaldo. Tenemos cuatro opciones sobre c\u00f3mo estas aplicaciones en producci\u00f3n pueden comenzar a interactuar entre s\u00ed. Puede que cambiemos la base de datos y resulta que necesitamos redirigir el tr\u00e1fico en el cl\u00faster de producci\u00f3n a la nueva base, o puede que se caiga el cl\u00faster y hayamos cambiado a respaldo, pero seguimos trabajando con la base de producci\u00f3n. Y la tercera opci\u00f3n es que se nos caiga esto y aquello, y cambiamos ambas aplicaciones, redefiniendo nuestra configuraci\u00f3n, para que las nuevas aplicaciones ya funcionen con la nueva base de datos. <\/p>\n

    Entonces, \u00bfqu\u00e9 conclusiones se pueden sacar de todo esto? <\/p>\n

    \"Reservas
    \n
    \nPrimera conclusi\u00f3n: vivir con respaldo es bueno. Pero caro. Pero idealmente no deber\u00edas vivir con un solo respaldo. En ideal, deber\u00edas tener varios respaldos. Primero, el respaldo debe estar al menos en m\u00e1s de un centro de datos, y segundo, al menos con otro proveedor de hosting. A menudo ha pasado \u2014 y en mi experiencia ha sido as\u00ed. No puedo nombrar proyectos, pero precisamente cuando ocurri\u00f3 un incendio en el centro de datos... Yo dec\u00eda: \u00a1cambiamos a respaldo! Y los servidores de respaldo estaban en el mismo rack...<\/p>\n

    O imagina que Amazon es prohibido en Rusia (y eso ha sucedido). Y ya est\u00e1: \u00bfde qu\u00e9 sirve que nuestro respaldo est\u00e9 en otro Amazon? Tambi\u00e9n est\u00e1 fuera de servicio. As\u00ed que repito: mant\u00e9n el respaldo, al menos en otro centro de datos, y preferiblemente con otro proveedor de hosting. <\/p>\n

    Segunda conclusi\u00f3n: si tienes una aplicaci\u00f3n en Kubernetes que se comunica con alguna fuente externa (puede ser una base de datos o una API externa), aseg\u00farate de definirla como un servicio con un Endpoint externo, para no tener que redeplegar 15 de tus aplicaciones que acceden a la misma base en el momento de hacer el cambio. Define la base de datos como un servicio separado, accede a ella como si estuviera dentro de tu cl\u00faster: si tu base se cae, solo cambias la IP en un lugar y sigues viviendo feliz. <\/p>\n

    Y por \u00faltimo: me encanta el \"cubito\", as\u00ed como los experimentos con \u00e9l. Tambi\u00e9n disfruto compartir los resultados de estos experimentos y mi experiencia personal. Por eso, grab\u00e9 una serie de seminarios web sobre K8s, bienvenidos a nuestro canal de YouTube<\/a><\/noindex> para m\u00e1s detalles.
    \n
    Fuente:     habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

    \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u0421\u0435\u0440\u0433\u0435\u0439, \u044f \u0438\u0437 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 ITSumma, \u0438 \u044f \u0445\u043e\u0447\u0443 \u0432\u0430\u043c \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u0442\u044c, \u043a\u0430\u043a \u043c\u044b \u043f\u043e\u0434\u0445\u043e\u0434\u0438\u043c \u043a \u0440\u0435\u0437\u0435\u0440\u0432\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044e \u0432 Kubernetes. \u0412 \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0435\u0435 \u0432\u0440\u0435\u043c\u044f \u044f \u043c\u043d\u043e\u0433\u043e \u0437\u0430\u043d\u0438\u043c\u0430\u044e\u0441\u044c \u043a\u043e\u043d\u0441\u0443\u043b\u044c\u0442\u0430\u0442\u0438\u0432\u043d\u043e\u0439 \u0440\u0430\u0431\u043e\u0442\u043e\u0439 \u043f\u043e \u0432\u043d\u0435\u0434\u0440\u0435\u043d\u0438\u044e \u0440\u0430\u0437\u043d\u043e\u043e\u0431\u0440\u0430\u0437\u043d\u044b\u0445 devops-\u0440\u0435\u0448\u0435\u043d\u0438\u0439 \u0434\u043b\u044f \u0440\u0430\u0437\u043b\u0438\u0447\u043d\u044b\u0445 \u043a\u043e\u043c\u0430\u043d\u0434, \u0438, \u0432 \u0447\u0430\u0441\u0442\u043d\u043e\u0441\u0442\u0438, \u043f\u043b\u043e\u0442\u043d\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u044e \u043f\u043e \u043f\u0440\u043e\u0435\u043a\u0442\u0430\u043c \u0441 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u0435\u043c K8s. \u041d\u0430 \u043a\u043e\u043d\u0444\u0435\u0440\u0435\u043d\u0446\u0438\u0438 Uptime day 4, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u0431\u044b\u043b\u0430 \u043f\u043e\u0441\u0432\u044f\u0449\u0435\u043d\u0430 \u0440\u0435\u0437\u0435\u0440\u0432\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044e \u0432 \u0441\u043b\u043e\u0436\u043d\u044b\u0445 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":25449,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-33773","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Reserva en Kubernetes: existe | ProHoster","description":"Me llamo Sergio, soy de la empresa ITSumma, y quiero contarte c\u00f3mo abordamos la reserva en Kubernetes.","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/rezervirovanie-v-kubernetes-ono-sushhestvuet","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"es_ES","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0420\u0435\u0437\u0435\u0440\u0432\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 \u0432 Kubernetes: \u043e\u043d\u043e \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0443\u0435\u0442 | ProHoster","og:description":"\u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u0421\u0435\u0440\u0433\u0435\u0439, \u044f \u0438\u0437 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 ITSumma, \u0438 \u044f \u0445\u043e\u0447\u0443 \u0432\u0430\u043c \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u0442\u044c, \u043a\u0430\u043a \u043c\u044b \u043f\u043e\u0434\u0445\u043e\u0434\u0438\u043c \u043a \u0440\u0435\u0437\u0435\u0440\u0432\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044e \u0432 Kubernetes.","og:url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/rezervirovanie-v-kubernetes-ono-sushhestvuet","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:54:36+00:00","article:modified_time":"2019-10-31T18:54:36+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"33773","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-02-09 17:03:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:33:25","updated":"2026-02-09 17:03:20","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/33773","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=33773"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/33773\/revisions"}],"predecessor-version":[{"id":159074,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/33773\/revisions\/159074"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media\/25449"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=33773"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=33773"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=33773"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}