{"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\/it\/blog\/administrirovanie\/rezervirovanie-v-kubernetes-ono-sushhestvuet","title":{"rendered":"Riservazione in Kubernetes: esiste","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Mi chiamo Sergej, lavoro per ITSumma e voglio raccontarti come affrontiamo il backup in Kubernetes. Ultimamente mi occupo molto di consulenza per l'implementazione di diverse soluzioni DevOps per vari team e, in particolare, lavoro a stretto contatto su progetti che utilizzano K8s. Alla conferenza Uptime Day 4, dedicata al backup in architetture complesse, ho presentato una relazione sul backup del 'cubetto', e qui ne offro una libera interpretazione. Vorrei avvisarti in anticipo che non si tratta di una guida pratica, ma piuttosto di un riassunto delle riflessioni su questo tema.<\/p>\n

\"Riservazione
\n
\nIn linea di principio, il monitoraggio e il backup sono i due strumenti principali per aumentare la resilienza di qualsiasi progetto. Ma nel kubernetes tutto si bilancia da solo, dirai tu, tutto si scalda autonomamente, e se succede qualcosa - si ripristina da solo... Cio\u00e8, a una prima indagine superficiale dell'argomento, la risposta di Internet alla domanda su come si approccia il backup in K8s \u00e8 stata 'ma perch\u00e9?'. Molti pensano che il kuber sia una sorta di oggetto magico che elimina tutti i problemi infrastrutturali e fa s\u00ec che il progetto non crolli mai. Ma... il mondo non \u00e8 come sembra.
\n<\/a><\/noindex>
\nCome ci approcciavamo al processo di backup in passato? Avevamo piattaforme identiche per l'hosting - che fossero macchine virtuali o server fisici servers<\/a>, a cui applicavamo tre pratiche di base: <\/p>\n

    \n
  1. sincronizzazione del codice e della staticit\u00e0<\/li>\n
  2. sincronizzazione delle configurazioni<\/li>\n
  3. replicazione del database<\/li>\n<\/ol>\n

    \nE voil\u00e0: in qualsiasi momento possiamo passare alla piattaforma di riserva, tutti sono felici, ci rialziamo e ci disperdiamo. <\/p>\n

    \"Riservazione
    \n
    \nCosa ci offrono per garantire la disponibilit\u00e0 continua della nostra applicazione Kubernetes? La prima cosa di cui parla la documentazione non ufficiale \u00e8 di installare molte macchine, creando diversi master; il numero deve soddisfare le condizioni per raggiungere il quorum all'interno del cluster, e su ciascun master deve essere in esecuzione etcd, api, MC, scheduler\u2026 E sembra tutto fantastico: quando pi\u00f9 nodi di lavoro o master escono di servizio, il nostro cluster si riequilibrer\u00e0 e l'app continuer\u00e0 a funzionare. Sembra magia! Ma spesso il nostro cluster si trova all'interno di un unico centro dati e questo pu\u00f2 sollevare alcune domande. Cosa succede se arriva un escavatore e scava i cavi, se colpisce un fulmine, o c'\u00e8 un diluvio universale? Tutto \u00e8 andato, il nostro cluster non esiste pi\u00f9. Come possiamo affrontare la questione della ridondanza considerando questo aspetto del problema? <\/p>\n

    Prima di tutto, dovresti avere un altro cluster in riserva calda, ovvero un cluster a cui puoi passare in qualsiasi momento. Da un punto di vista di Kubernetes, le infrastrutture devono essere completamente identiche. Quindi, se ci sono plugin non standard per lavorare con il file system, soluzioni personalizzate per l'ingress, devono essere completamente identiche sui tuoi due (o tre, o dieci, a seconda di quanto hai a disposizione in termini di budget e risorse per gli amministratori) cluster. \u00c8 necessario definire chiaramente due set di applicazioni (deployment, statefulset, daemonset, cronjob, ecc.): quali di esse possono funzionare in riserva costantemente e quali sarebbe meglio non avviare fino al passaggio effettivo. <\/p>\n

    Il nostro cluster di riserva deve essere completamente identico al nostro cluster di produzione? No. Se in passato, lavorando con progetti monolitici e infrastrutture hardware, mantenevamo un ambiente praticamente identico, nell'ambito di Kubernetes, ritengo che questo non debba essere il caso. Vediamo perch\u00e9.<\/p>\n

    Ad esempio, iniziamo con le entit\u00e0 di base di Kubernetes \u2014 i deployments \u2014 che devono essere identici. Devono essere avviate applicazioni che in qualsiasi momento possono prendere in carico l'elaborazione del traffico, permettendo al nostro progetto di continuare a vivere. Se parliamo di file di configurazione, dobbiamo considerare se debbano essere identici o meno. Cio\u00e8, se noi, persone intelligenti, non usiamo sostanze vietate e non teniamo il database in K8s, allora nelle configmaps devono esserci le configurazioni di accesso al database di produzione (il cui processo di backup \u00e8 impostato separatamente). Di conseguenza, per garantire l'accesso al database di backup, dobbiamo avere un file di configurazione (configmap) separato. Allo stesso modo lavoriamo con i secret: le password per accedere al database, le API key; in qualsiasi momento pu\u00f2 funzionare o il secret di produzione o quello di backup. Pertanto, abbiamo gi\u00e0 due entit\u00e0 Kubernetes, le cui versioni di backup non devono essere identiche a quelle di produzione. La prossima entit\u00e0 su cui vale la pena soffermarsi \u00e8 il cronjob. I cronjob di riserva non devono assolutamente essere identici al set di cronjob del cluster di produzione! Se avviamo un cluster di backup e lo avviamo completamente con tutti i cronjob attivi \u2014 ad esempio, le persone riceveranno da voi due email contemporaneamente invece di una. Oppure qualche sincronizzazione dei dati con fonti esterne avverr\u00e0 due volte, e di conseguenza iniziamo a star male, a piangere, a urlare e a litigare. <\/p>\n

    \"Riservazione
    \n
    \nE come ci propongono di organizzare un cluster di riserva le persone su Internet? La seconda risposta pi\u00f9 popolare dopo \"perch\u00e9?\" \u00e8 l'uso della Kubernetes Federation. <\/p>\n

    Che cos'\u00e8? \u00c8, per cos\u00ec dire, un grande meta-cluster. Se rappresentiamo l'architettura di Kubernetes \u2014 dove abbiamo un master e diverse nodi \u2014 dal punto di vista della federazione abbiamo anch'esso un master e diverse nodi, solo che ogni nodo \u00e8 un cluster separato. In altre parole, lavoriamo con le stesse entit\u00e0 e gli stessi primitivi come con un singolo Kubernetes, solo che gestiamo non le nostre macchine fisiche, ma interi cluster. Nell'ambito della federazione avviene una completa sincronizzazione delle risorse federative dai genitori ai figli. Ad esempio, se abbiamo avviato un deployment tramite federazione \u2014 verr\u00e0 distribuito su ogni nostro cluster secondario. Se prendiamo un configmap o un segreto e lo distribuiamo tramite federazione \u2014 questi si propagheranno a tutti i nostri cluster secondari; inoltre, la federazione permette di personalizzare le nostre risorse sui figli. Dunque, prendiamo un configmap, lo distribuiamo tramite federazione e poi, se dobbiamo fare delle modifiche su cluster specifici, ci rechiamo a modificare su un cluster separato e quella modifica non verr\u00e0 pi\u00f9 sincronizzata altrove. <\/p>\n

    Kubernetes Federation \u00e8 uno strumento relativamente recente e non supporta un insieme completo di risorse fornite da K8s: al momento della pubblicazione di una delle prime versioni della documentazione, si parlava di supporto solo per config maps, deployment sotto replica set e ingress. I segreti non erano supportati e il lavoro con i volumi non era supportato. Un insieme di funzionalit\u00e0 troppo limitato. Soprattutto se ci piace divertirci, ad esempio, passando le nostre risorse personalizzate a Kubernetes tramite custom resource definition, nella federazione non possiamo includerle. Quindi, in un certo senso\u2026 \u00e8 una soluzione che si avvicina alla realt\u00e0, ma ci induce periodicamente a <\/p>\n

    Possiamo affrontare il processo di riserva di Kubernetes in maniera pi\u00f9 semplice? Quali strumenti abbiamo a disposizione?<\/p>\n

    Innanzitutto, abbiamo sempre un qualche sistema di CI\/CD, quindi non andiamo manualmente a scrivere sui server create\/apply. Il sistema genera file yaml per i nostri container. <\/p>\n

    In secondo luogo, ci sono diversi cluster e abbiamo uno o pi\u00f9 registry (se siamo intelligenti) che abbiamo anche riservato. E c'\u00e8 un'ottima utilit\u00e0, kubectl, che pu\u00f2 lavorare con pi\u00f9 cluster contemporaneamente. <\/p>\n

    \"Riservazione
    \n
    \nDunque, secondo me, la soluzione pi\u00f9 semplice e corretta per costruire un cluster di backup \u00e8 un deployment parallelo primitivo. C'\u00e8 un certo pipeline nel sistema ci\/cd; prima costruiamo i nostri container, testiamo e distribuiamo le applicazioni tramite kubectl su pi\u00f9 cluster indipendenti. Possiamo realizzare distribuzioni simultanee su pi\u00f9 cluster. Di conseguenza, gestiamo anche la consegna delle configurazioni in questa fase. Possiamo definire in anticipo un set di configurazioni per il nostro cluster di produzione, un set di configurazioni per il cluster di backup e, a livello di sistema ci\/cd, distribuire l'ambiente di produzione nel cluster di produzione, l'ambiente di backup nel cluster di backup. Rispetto alla federazione, non \u00e8 necessario andare su ogni cluster figlio e ridefinire qualcosa dopo aver stabilito la risorsa federativa. Lo abbiamo fatto in anticipo. Che bravi siamo.<\/p>\n

    Ma\u2026 ci sono\u2026 avevo scritto, c'\u00e8 la \u00abradice di tutti i mali\u00bb, ma in realt\u00e0 ce ne sono due. Prima di tutto, il file system. C'\u00e8 qualche PV, oppure utilizziamo uno storage esterno. Se memorizziamo file all'interno del cluster, dobbiamo seguire le vecchie pratiche risalenti ai tempi delle infrastrutture fisiche: ad esempio, sincronizzare con lsync. Oppure con una qualsiasi altra soluzione che preferite. Distribuiamo tutto su altre macchine e andiamo avanti.<\/p>\n

    In secondo luogo, e, in realt\u00e0, un punto di conflitto anche pi\u00f9 importante, \u00e8 il database. Se siamo persone intelligenti e non teniamo il database nel kubernetes, il processo di backup dei dati avviene secondo il vecchio schema \u2014 replica master-slave, poi commutazione, recupereremo la replica e vivremo bene. Ma se teniamo il nostro DB all'interno del cluster, ci sono molte soluzioni pronte per organizzare la stessa replica master-slave, molte soluzioni per alzare DB all'interno di kubernetes.
    \n Di backup dei database si sono gi\u00e0 letti miliardi di rapporti, scritti miliardi di articoli, non c'\u00e8 nulla di nuovo da questo punto di vista. In generale, seguite i vostri sogni, vivete come volete, inventate anche qualche workaround complesso, ma pensate sempre a come farete tutti i vostri backup.<\/p>\n

    Ora parliamo di come, in linea di principio, avverr\u00e0 il processo di switch verso il sito di backup in caso di incendio. In primo luogo, distribuiamo in parallelo applicazioni stateless. Queste non influiscono sulla logica di business delle nostre applicazioni e del nostro progetto; possiamo mantenere continuamente due set di applicazioni in esecuzione, e possono iniziare ad accettare traffico. \u00c8 molto importante, durante il processo di switch verso il sito di backup, controllare se \u00e8 necessario ridefinire le configurazioni. Ad esempio, abbiamo un cluster Kubernetes di produzione, un cluster Kubernetes di backup, un database esterno master e un database master di backup. Abbiamo quattro opzioni su come queste applicazioni in produzione possono iniziare a interagire tra loro. Potrebbe essere necessario fare uno switch del database, e quindi bisognerebbe reindirizzare il traffico del cluster di produzione al nuovo database, oppure potrebbe guastarsi il cluster \u2014 e siamo passati al backup, ma continuiamo a lavorare con il database di produzione. Inoltre, c'\u00e8 il terzo scenario in cui sia questo che quello si guastano, e facciamo lo switch di entrambe le applicazioni, ridefinendo la nostra configurazione affinch\u00e9 le nuove applicazioni possano lavorare gi\u00e0 con il nuovo database. <\/p>\n

    E quindi, quali conclusioni possiamo trarre da tutto questo? <\/p>\n

    \"Riservazione
    \n
    \nConclusione prima: \u00e8 bello avere un backup. Ma \u00e8 costoso. In ideale non dovremmo avere solo un backup. Idealmente dovremmo avere pi\u00f9 backup. In primo luogo, il backup dovrebbe trovarsi in almeno un centro dati diverso e, in secondo luogo, idealmente, presso un altro fornitore. \u00c8 capitato spesso \u2014 e nella mia esperienza \u00e8 successo. Purtroppo non posso nominare progetti, specialmente quando \u00e8 scoppiato un incendio nel centro dati... Io: passiamo al backup! E i server di backup erano nelle stesse rack...<\/p>\n

    Oppure immaginate che Amazon venga bloccato in Russia (e questo \u00e8 successo). Ecco, che utilit\u00e0 ha il nostro backup in un altro Amazon? Anche questo \u00e8 inaccessibile. Quindi ripeto: manteniamo un backup, almeno in un altro centro dati, e preferibilmente \u2014 presso un altro fornitore. <\/p>\n

    Seconda conclusione: se nella vostra applicazione Kubernetes comunicate con fonti esterne (possono essere database o qualche API esterna), assicuratevi di definirla come servizio con un Endpoint esterno, in modo da non dover ridistribuire 15 delle vostre applicazioni che puntano allo stesso database durante il cambio. Definite il database come un servizio separato e accedete a esso come se fosse all'interno del cluster: se il database si guasta, cambiate l'IP in un solo luogo e continuate a vivere felicemente. <\/p>\n

    And lastly: I love Kubernetes, just like I love experimenting with it. I also enjoy sharing the results of these experiments and my personal experiences. That\u2019s why I recorded a series of webinars about K8s, welcome to our YouTube channel<\/a><\/noindex> for more details.
    \n
    Fonte:     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\udd47Redundancy in Kubernetes: it exists | ProHoster","description":"My name is Sergey, I'm from ITSumma, and I want to tell you how we approach redundancy in Kubernetes.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/rezervirovanie-v-kubernetes-ono-sushhestvuet","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","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\/it\/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\/it\/wp-json\/wp\/v2\/posts\/33773","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=33773"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/33773\/revisions"}],"predecessor-version":[{"id":159074,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/33773\/revisions\/159074"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/25449"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=33773"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=33773"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=33773"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}