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.

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. Let’s start with the use case that gave birth to this problem: Quarkus—Supersonic and Subatomic Java—has excited the Java developer community with its amazing speed and all new native build artifact for Java applications.

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.

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.

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.

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.

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!

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.

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.

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.