Articles

Traffic Management With Istio (1): Unified Management of TCP Ingress Traffic Routing Based on Istio Rules

,

The Istio traffic management model basically allows for the decoupling of traffic from infrastructure scaling, allowing operations personnel to specify the rules to apply to traffic using Pilot instead of specifying which pods/VMS should receive traffic. Decoupling traffic from infrastructure scaling allows Istio to provide a variety of traffic management functions independent of application code. The Envoy sidecar proxy implements these functions.

In a typical mesh, you often have one or more finalizing external TLS connections at the end to guide traffic into the mesh’s load balancer (known as a gateway); the traffic then flows through internal services after the sidecar gateway. The following figure illustrates the use of gateways in a mesh:

Source de l’article sur DZONE

/0 Commentaires/par

With Kubernetes, Cloud Providers Are the New Hardware Vendors

,

In the ’90s, server software came in boxes containing floppies and CDs that required expert knowledge and hours of setup before it was production-ready. Nowadays, launching server application and infrastructure software is just a few clicks away in all of the major cloud vendors’ marketplaces. However, some fundamental platform challenges around standardization still need to be solved, and Kubernetes seems to be the likely solution to overcome these issues.

First, a Little History

In the early days of computing, software and hardware were tightly coupled. Applications written for a specific computer would not work on machines from other vendors. Third-party application providers, also known as ISVs (Independent Software Vendors), that wanted to target multiple platforms typically had to rewrite or modify large chunks of their software to address differences in the underlying hardware. The arrival of cross-platform operating systems and languages changed all of this, allowing ISVs to write their software to a single set of APIs and offloading the responsibility of porting to different hardware platforms to the operating system vendor.

Source de l’article sur DZONE

/0 Commentaires/par

Managing Secrets in Kubernetes

,

In part one of this series on Best Practices for Building and Designing Containers for Kubernetes, we looked at how to separate config from code in Kubernetes and why you need to do that. Specifically, we examined how config maps and environment variables are defined and configured. In this post, we continue that important discussion with a look at secrets management, what secrets are, and how you manage them.

Managing Public Configuration Information in Kubernetes

Not all configuration information is safe to keep out in the “public” and many, if not most, Kubernetes-hosted workloads need usernames/passwords, tokens, keys or other private information to securely connect to other services. There are a variety of options worth exploring here, each with its own set of positives and negatives.

Source de l’article sur DZONE

/0 Commentaires/par

Keycloak Cluster Setup With kube_ping

,

Keycloak is an open source software which provides single sign-on with Identity Management and access management. Keycoak uses different types of pings to discover other members of cluster. We are going to use kube_ping as discovery (JGROUPS_DISCOVERY_PROTOCOL).

How kube_ping Works

Let’s assume we launch a cluster of 3 pods in Kubernetes in the default Namespace. When discovery starts, kube_ping asks for a list of the IP addresses of all pods from Kubernetes.

Source de l’article sur DZONE

/0 Commentaires/par