StackPointCloud, provider of a cloud-native management platform for Istio and Kubernetes, has added a series of tools to help enterprises deploy and use microservices and containers. Users can now manage Istio service meshes across Kubernetes clusters using their preferred cloud providers and StackPointCloud has partnered with Packet Host to help customers use ARM with their Kubernetes clusters.
Among the major updates to StackPointCloud's StackPoint.io platform is the ability for users to manage traffic rules in their Istio service meshes across Amazon Web Services, Google Kubernetes Engine, Microsoft Azure, Google Cloud Platform, Digital Ocean and Packet via a dashboard. Users also can now build and manage their ARM Kubernetes clusters in StackPointCloud. StackPointCloud has also achieved certified Kubernetes support for version 1.10.
Matt Baldwin, CEO of StackPointCloud, spoke to InfoQ about the announcement in more detail:
InfoQ: What is the significance of the new Kubernetes certification?
Matt Baldwin: Without certification, enterprises are not aware if the vendor they choose conforms to the current version of Kubernetes or not. This is why the Cloud Native Computing Foundation (CNCF) has established a process to constantly re-certify providers for each version of Kubernetes that ships. We are certified on 1.8, 1.9, and 1.10. This should give confidence to any enterprise that chooses StackPointCloud as their cloud native infrastructure management platform that they are running upstream, 'vanilla' Kubernetes that has not been modified and is stable. If a company cannot pass conformance and be certified, this suggests that they are shipping their own Kubernetes distribution, forked from the main project. This isn't ideal for customers as some features may not work or may work in unexpected ways. We believe trust is built on certification.
InfoQ: The new StackPoint.io update continues to focus on both the operator and developer and allows organisations to perform canary, A/B or blue/green deployments across one or many Kubernetes clusters regardless of provider. Users also can choose one or many Kubernetes services and configure Istio traffic rules around them. How are these traffic rules configured?
Baldwin: With our version one release of the Istio Dashboard component in StackPoint.io we are allowing users to configure routing rules. The core use cases we're focused on right now are: canary deployments, blue/green deployments, and A/B deployments. These are all surfaced in a wizard through which the user chooses the current version of their service, then selects the next version of their service, and finally configures the traffic distribution to those destinations, e.g. 50/50 or maybe just send 1% of traffic to the latest service to test it out. These are use cases common with deploying microservices into production environments. Over time, we will begin to introduce more and more complexity around the type of route rules that can be administered and created within our product. Users can also set a schedule for when the rule should be applied versus doing it immediately. They can choose to build a custom rule or use Stackpoint.io wizards to configure Istio routing for their services. Along with setting up various traffic rules, users can visually manage other aspects of their Istio service mesh via a dashboard, including VirtualServices and Destinations.
InfoQ: Can users set the schedule to the rule: 'continuous integration tests passed'?
Baldwin: No, the scheduling right now is simpler than that. The primary use case here is to allow an operations team to schedule, say, a blue/green deployment to go live during a change control window. We will be introducing the ability to expire a rule, too. So, if you're running a canary you can set it to run for a set period of time. But we are heading into the continuous integration and delivery territory - we're figuring out that scenario right now.
InfoQ: To help customers begin using ARM with their Kubernetes clusters, StackPointCloud has partnered with Packet Host. The joint solution includes previously available Stackpoint.io features, such as the ability to add or remove notes from an ARM cluster, autoscaling of ARM instances, and upgrading ARM Kubernetes clusters. What's different about this enhancement with PacketHost, then?
Baldwin: Packet offers bare metal - so if you want to run Kubernetes the way Google itself does (i.e. on bare metal), using Packet through Stackpoint is a way to get a single-tenant environment with access to the system resources.
InfoQ: What exactly does StackPoint.io mean when it uses the term 'ARM instances'?
Baldwin: Packet also gives users access to various processors, including x86 by Intel and AMD (EPYC) as well as robust ARMv8 systems from Cavium (ThunderX) and soon Qualcomm (Centriq). As we re-integrated with Packet we moved to support not only Packet's x86 systems, but also their ARM systems. This is a natural next step for Kubernetes and cloud native, with the promise to 'run your workload on whatever, wherever'; and we believe a first for a Kubernetes control plane. And to be clear: this isn't your 'Raspberry Pi' style, lower powered ARM; Packet's current configuration has 96 cores and 128GB of RAM for $.50/hr.
InfoQ: Why does ARM matter?
Baldwin: We see that underlying compute is getting more diverse - from architectures like ARM to GPU's and specialty offloads (even smartphones and laptops). And when you get into custom silicon, you're guaranteed to find a lot of ARM. We see both ARM and Kubernetes playing a huge role in new use cases like Internet of Things (IoT) and edge computing. Prior to this, organisations had no way to stand-up or manage these diverse types of environments. We let you build out Intel x86 alongside ARM infrastructure.