One place for hosting & domains


      Upcoming Changes Related to Network Infrastructure Upgrades

      , by Linode

      Traducciones al Español

      Estamos traduciendo nuestros guías y tutoriales al Español. Es
      posible que usted esté viendo una traducción generada
      automáticamente. Estamos trabajando con traductores profesionales
      para verificar las traducciones de nuestro sitio web. Este proyecto
      es un trabajo en curso.

      Create a Linode account
      to try this guide with a $ credit.

      This credit will be applied to any valid services used during your first

      Throughout 2022, Linode is rolling out networking infrastructure upgrades to all of our existing data centers. These upgrades increase the stability and resiliency of our already reliable network. It also enables us to bring features, such as VLAN and IP Sharing, to every data center.

      For most customers, these upgrades are performed seamlessly behind the scenes. For customers that use certain features, such as IP Sharing and /116 IPv6 pools, there may be some changes that impact your current configuration. This document outlines what is changing, what data centers are impacted, and what, if anything, you may need to do in order to prepare for these upcoming changes.

      What’s New?

      • IP Sharing (IP failover) availability: The IP Sharing feature, as it exists prior to these upgrades, enables IP failover for public IPv4 addresses in select data centers. After the upgrades have been completed, this feature will be expanded to all data centers and will also support IPv6 routed ranges (/64 and /56). See our
        Configuring IP Failover on a Compute Instance guide to learn more about configuring IP failover.

      • VLAN availability:
        VLANs, which enable private layer 2 networking, will be launched across all data centers soon after the network upgrades have occurred.

      What’s Changing?

      The following is a list of breaking changes and any action that may be required if you are impacted by that change:

      • Deprecation of IPv6 /116 pools: /116 pools will no longer be provided to new Compute Instances. Existing /116 pools will be removed from Compute Instances when data center is undergoing upgrades.

        Action: If you are using /116 for IPv6 failover, consider using an IPv6 /64 instead.

      • IP failover through BGP: IP failover (IP Sharing) for public IPv4 addresses and IPv6 routed ranges will be facilitated through BGP instead of ARP (configured through

        Action: If you have previously configured IP failover for a public IPv4 address, review the
        Configuring IP Failover on a Compute Instance guide to learn more about configuring IP failover using BGP. You can configure BGP ahead of time, but will not be able to test or use the configuration until after the network upgrades have been completed.

      Which Data Centers Have Been Upgraded?

      Review the table below to learn which data centers have been upgraded with the latest network enhancements.

      Data centerUpgrade Status
      Atlanta (Georgia, USA)Coming soon
      Dallas (Texas, USA)Coming soon
      Frankfurt (Germany)Complete
      Fremont (California, USA)Coming soon
      London (United Kingdom)Complete
      Mumbai (India)Complete
      Newark (New Jersey, USA)Complete
      Sydney (Australia)Coming soon
      Tokyo (Japan)Coming soon
      Toronto (Canada)Coming soon

      A status of complete indicates that all new Compute Instances (and most existing instances) are located on fully upgraded hardware. Compute Instances using legacy features, such as ARP-based failover and /116 ranges, may still be located on hardware that hasn’t yet been upgraded. These customers have been notified and a migration timeline has been shared.

      What Action is Required?

      • Migration of Compute Instances: Once a data center has started the network infrastructure upgrades, live migrations will be scheduled for all Compute Instances that do not reside on upgraded hardware. This live migration will occur while your Compute Instance is powered on and operating normally. After the migration has been successfully completed, there may be a brief period of downtime while the Compute Instance is rebooted.

      • Update IP failover configuration: If you have configured IP failover for a public IPv4 address, review the
        Configuring IP Failover on a Compute Instance guide to learn more about configuring IP failover using BGP. If you were using a now deprecated IPv6 /116 pool for IP failover, consider using an IPv6 /64 range instead. You can configure BGP ahead of time, but will not be able to test or use the configuration until after your Compute Instances are migrated to upgraded hardware.

      This page was originally published on

      Join the conversation.
      Read other comments or post your own below. Comments must be respectful,
      constructive, and relevant to the topic of the guide. Do not post external
      links or advertisements. Before posting, consider if your comment would be
      better addressed by contacting our
      Support team or asking on
      Community Site.

      Source link

      20,000 Upgrades Later: Lessons From a Year of Managed Kubernetes Upgrades

      This Tech Talk will be streaming live on Wednesday, September 2, 2020, 1:00–2:00 p.m. ET.
      RSVP for free on Eventbrite here to receive a link to join.

      About the Talk

      Upgrading to a new release is one of the most disruptive operations we regularly inflict on our Kubernetes clusters. There are multiple strategies for doing an upgrade, but they all require rescheduling workloads and restarting cluster components.

      We started offering upgrades on our managed Kubernetes platform, DigitalOcean Kubernetes Service (DOKS), in May 2019. Since then, our customers have kicked off about 20,000 automated patch and minor release upgrades on their clusters. Most of those upgrades went well, but some didn’t and we’ve learned a few things from the ones that went wrong.

      In this talk, we will share lessons from a year of automated Kubernetes upgrades: what we got right, what we got wrong, workloads that caused us trouble, and changes we’ve made to make the process smoother. We hope these lessons will help others avoid pain in their Kubernetes upgrades.

      What You’ll Learn

      • How DigitalOcean coordinates Kubernetes upgrades for managed clusters.
      • What Kubernetes users, especially those using DigitalOcean managed Kubernetes, can do to ensure their workloads tolerate upgrades.

      This Talk is Designed For

      • Kubernetes administrators/operators who are interested in the details of how DigitalOcean performs Kubernetes upgrades, what we’ve seen go wrong, and what we’ve learned.
      • Developers running applications on Kubernetes who are interested in how to configure your workloads to avoid problems during upgrades.


      Knowledge of the components of a Kubernetes cluster and how applications are deployed.

      About the Presenter

      Adam Wolfe Gordon is the tech lead for managed Kubernetes and container registry at DigitalOcean. He previously worked on block storage at DigitalOcean and EMC. Adam is a regular conference speaker and a frequent attendee of and presenter at local meetups in Edmonton, Alberta, Canada. He likes building and debugging microservices, observability, and occasional forays into lower-level software.

      How to Join

      This Tech Talk is free and open to everyone. Join the live event on Wednesday, September 2, 2020, 1:00–2:00 p.m. ET by registering on Eventbrite here and Adam Wolfe Gordon will be answering questions at the end.

      If you can’t make the live event, the video recording will be published here as soon as it’s available.

      Source link