Ask Sendai

Istio is a popular open-source service mesh with powerful service-to-service capabilities such as request-routing control, metric collection, distributed tracing, security, et. al. Istio also ships with an ingress-gateway component that makes it easy to get traffic into your service mesh. The Istio ingress gateway allows you to control what protocols, security requirements, and ports get exposed to the outside world, and then use Istio-native routing capabilities to route traffic to services. Gloo is an open-source API Gateway based on Envoy Proxy with advanced API Gateway capabilities like request/response transformation, function routing (Swagger, gRPC, cloud functions like Lambda, etc), a pluggable and extensible control plane and discovery system for Envoy, and more. As outlined in our “API Gateways are going through an identity crisis” blog, using an API gateway can give definition to your microservices, decouple front-end users/services from backend APIs, aggregate multiple APIs, and do more complex routing.

Solve common Kubernetes deployment issues using the Init Container build pattern and Knative build, which can be applied to any Kubernetes deployment. With Kubernetes evolving at supersonic speed and seeing a lot of adoption in the enterprise world, the developer community is now looking for solutions to common Kubernetes problems, such as patterns. In this article, I will explore a new Kubernetes pattern using Init Containers.

Knative is talked about a great deal, especially around how its capabilities can help provide more standard building blocks on top of Kubernetes for building microservices and serverless like services, e.g., scale to zero, and scale on demand. Knative high level has three capability areas: building, serving, and eventing. This post will provide some examples around Knative Build and Knative Serving with Solo.io Gloo. Knative Serving initially included all of Istio only to use a small fraction of its capabilities around Kubernetes cluster ingress. Recently the Knative team added Gloo as an alternative to Istio. More details are available in Gloo, Knative and the future of Serverless and Gloo, by Solo.io, is the first alternative to Istio on Knative.

The release also includes additional new features, secure workflow enhancements, general improvements, and bug fixes. The Vault 1.1 changelog provides a full list of features, enhancements, and bug fixes. Vault agent now supports client-side caching of leased secrets. An agent may now cache a response to a token managed client-side via auto auth. This allows for applications to work completely with Vault agent to manage a token’s lifecycle, simplifying edge computing use cases or use cases where encoding logic for an application to manage token expiry with a Vault cluster may be complicated (e.g.: bootstrapping an embedded system, container management use cases, etc.) There are many new features in Vault 1.1 that have been developed over the course of the 1.0.x releases.

Since we released 1.0 back in July, we’ve done a lot of work to help people get into production. Not surprisingly, we had to do some patch releases (6 so far!), but we’ve also been hard at work adding new features to the product. The theme for 1.1 is Enterprise Ready. We’ve been very pleased to see more and more companies using Istio in production, but as some larger companies tried to adopt Istio they hit some limits. One of our prime areas of focus has been performance and scalability. As people moved into production with larger clusters running more services at higher volume, they hit some scaling and performance issues.

Hyper-scale, microservice-based cloud environments have been exciting to build but challenging to manage. Along came Kubernetes (container orchestration) in 2014, followed by Istio (container service management) in 2017. Both open-source projects enable developers to scale container-based applications without spending too much time on administration tasks. Now, new enhancements in Istio 1.1 deliver scale-up with improved application performance and service management efficiency. Simulations using our sample commercial airline reservation application show the following improvements, compared to Istio 1.0.

KubeEdge becomes the first Kubernetes Native Edge Computing Platform with both Edge and Cloud components open sourced! Open source edge computing is going through its most dynamic phase of development in the industry. So many open source platforms, so many consolidations and so many initiatives for standardization! This shows the strong drive to build better platforms to bring cloud computing to the edges to meet ever increasing demand. KubeEdge, which was announced last year, now brings great news for cloud native computing! It provides a complete edge computing solution based on Kubernetes with separate cloud and edge core modules.

Let’s review some of the use cases of connecting multiple Kubernetes clusters before we dive into the implementation details. High availability is the most obvious use case for most. This use case includes operating Kubernetes clusters in multiple regions or availability zones and runs the replicas of the same services in each cluster. Upon failure, requests can fail over to other clusters. The failure scenario covered in this use case is not primarily the complete unavailability of the entire region or failure domain. A more likely scenario is temporary unavailability of resources or misconfiguration in one cluster leading to inability to run or scale particular services in one cluster.

Kubernetes is a Container Orchestration Engine designed to host containerized applications on a set of nodes, commonly referred to as a cluster. Using a systems modeling approach, this series aims to advance the understanding of Kubernetes and its underlying concepts. The Kubernetes API is an Http API that provides Create/Read/Update/Delete access to query and modify the Kubernetes Object Store. Kubernetes supports multiple authentication and authorization strategies to control the access to the API. This post provides a concise, detailed model of Kubernetes’ Role-based Access Control (RBAC), but may not be suitable as introductory material. The model is supported by partial specifications in TLA+.

Back in 2015, a revolution was under way. We were moving from manual, handcrafted infrastructures, to container-based, industrial, and human-free platforms. In those dark ages of orchestration, edge traffic was remarkably difficult to manage. On one side, we had traditional reverse-proxies that were built for static infrastructures, on the other side, we were building dynamic clusters made to deploy and manage thousands of microservices. The idea of having a simple and automatic edge router, all in one binary, was appealing, but also idealistic. The foundation of Traefik was laid that year, paving the way to building a project with strong values: simplicity of configuration, modern features, and open to the community.