New Workshop: Load Balanced Kubernetes Cluster with Cluster API
Did you know that you can take advantage of Equinix Metal Load Balancers while quickly provisioning a Kubernetes cluster? You can try this hands-on in our latest workshop that takes advantage of two Equinix integrations with the Kubernetes API: Cloud Provider Equinix Metal (CPEM) and Cluster API Provider Packet (CAPP). This workshop takes a user step-by-step through gathering configuration details from the Metal Console, setting up the launch environment, and deploying a sample application on the load balanced cluster. You’ll use CAPP to deploy the cluster on Equinix Metal machines, including three control plane nodes and two worker nodes to demonstrate the load balancing functionality. By changing the configuration in CPEM, it is enabled to set up the load balancing service in front of the control plane nodes. Later, the user deploys and verifies nginx as a sample application. This produces a website that can be accessed via an external IP managed by a dynamically provisioned Equinix Metal Load Balancer, which can be reviewed in the Equinix Metal console. Make sure to permanently delete the cluster using the workshop instructions since Cluster API clusters will attempt to repair themselves if servers and load balancers are deleted manually. This workshop is a wonderful way to gain comfort using a diverse set of Kubernetes related tools as well as Equinix load balancing and bare metal.Multi-cloud Routing via Pulumi Templates
Quickly spin up a Fabric Cloud Router instance for routing between GCP and AWS with available Pulumi templates (programs) and these step by step workshops: Equinix FCR to Google Cloud Platform with Pulumi (Workshop) Equinix FCR Multi-cloud with Pulumi (Workshop) By the end, you'll have seamless routing betweenGCPPartner Interconnectand GCPCloud Routeras well asAWS Direct Connect. You can also find this information on the deploy site here.Terraform-Provider-Equinix v1.16.0 Release
Equinix Terraform Provider v1.16.0not only has the ability to createFabric Cloud Routerresources directly, but also layer 2 connections to AWS, GCP, and specific fabric ports in Equinix. Connections to Azure and Oracle via Terraform are coming soon! FCR is a great option for those who want to quickly route between clouds using BGP or static networks without worrying about specific OS, vendor requirements, or advanced configuration. For those who use Network Edge, this Terraform release allows you to disable the default internet connectivity before provisioning specific firewalls (Palo Alto Networks NGFW, CiscoFTDv, and AviatrixFireNet)just like you can in the console.Ansible-Collection-Equinix v0.1.0 Release
This is the firstrelease of the Equinix Ansible Collection. This collection will mature to succeed the Ansible Equinix Metal collection. The big difference with this collection is that the goal of the project is to cover all Equinix APIs over time, starting with Metal, Fabric, and Network Edge. If you are just getting started with Ansible on Equinix, this is the project to use. Let us know which features you’ll need for your playbooks.We’ve stubbed out issues for all of the resources that will be needed to put this provider on parity with the Equinix Terraform provider which has thethe most complete IaC coverage today. Broader API coverage is being facilitated by the move away from legacy, hand-crafted, Python SDKs (packet-python). We will favor (and produce) SDKs generated from the OpenAPI spec for each Equinix API that will be supported. Metal Python is the first of these, an SDK built for wide adoption. Its readiness to simplify the API developer experience in Pythonis demonstrated throughout the Equinix Ansible collection. Additionally, this collection is applying some of the best practices seen in other Cloud Provider Ansible modules. This is most visible in the name of the module and how it is imported. See the project's E2E tests for working examples of how this collection can be used.Equinix Provider for Terraform v1.14.3 Release
The 1.14.3 release of the Equinix Terraform provider includes bug fixes and documentation improvements to provide a more consistent experience. The spot market request resource and data source have been updated to avoid unnecessary changes when the order of `facilities` changes for a spot market request, the virtual circuit resource has been updated to reduce the occurrence of API errors due to invalid requests, and the documentation for the `equinix_metal_device` resource has been updated to more accurately describe the `user_ssh_key_ids` and `project_ssh_key_ids` fields.Cluster-API-Provider-Packet v0.7.0 Release
Version 0.7.0 of cluster-api-provider-packet, introduces metro level support vs facility level in accordance with the soon-to-be updated Metal API. Users ofprevious versions will want to take advantage of this immediately. The basic requirements to upgrade your existing clusters can be found here. Please work with your Equinix support team to determine the best migration path for your architecture. Assistance can also be found in theCommunity Slack andCommunity site. Read more at our Metros Quick Reference and see the facility deprecation announcement. *Please note that if devices are already in the correct metros you’ve specified, no disruption will happen to clusters or their devices. As with any production change, test your changes before applying them to clusters in production. In addition to metro-level support, this release installs the latestcloud-provider-equinix-metal v3.6.1 by default and is built on golang version 1.19 and cluster-api 1.3. The default OS used is Ubuntu 20.04 and kube-vip is updated to v0.5.12 in the kube-vip flavor templates. Lastly, the CI workflow has been refactored with caching removed and updated tests considering cluster-api 1.3 dependencies. See more at the github release here! https://github.com/kubernetes-sigs/cluster-api-provider-packet/releases/tag/v0.7.0
