Dylan  Iqbal

Dylan Iqbal

1643273029

Linkerd2 Proxy: Ultralight Service Mesh for Kubernetes, Written in Rus

This repo contains the transparent proxy component of Linkerd2. While the Linkerd2 proxy is heavily influenced by the Linkerd 1.X proxy, it comprises an entirely new codebase implemented in the Rust programming language.

This proxy's features include:

  • Transparent, zero-config proxying for HTTP, HTTP/2, and arbitrary TCP protocols.
  • Automatic Prometheus metrics export for HTTP and TCP traffic;
  • Transparent, zero-config WebSocket proxying;
  • Automatic, latency-aware, layer-7 load balancing;
  • Automatic layer-4 load balancing for non-HTTP traffic;
  • Automatic TLS (experimental);
  • An on-demand diagnostic tap API.

This proxy is primarily intended to run on Linux in containerized environments like Kubernetes, though it may also work on other Unix-like systems (like macOS).

The proxy supports service discovery via DNS and the linkerd2 Destination gRPC API.

The Linkerd project is hosted by the Cloud Native Computing Foundation (CNCF).

Building the project

A Makefile is provided to automate most build tasks. It provides the following targets:

  • make build -- Compiles the proxy on your local system using cargo
  • make clean -- Cleans the build target on the local system using cargo clean
  • make test -- Runs unit and integration tests on your local system using cargo
  • make test-flakey -- Runs all tests, including those that may fail spuriously
  • make package -- Builds a tarball at target/release/linkerd2-proxy-${PACKAGE_VERSION}.tar.gz. If PACKAGE_VERSION is not set in the environment, the local git SHA is used.
  • make docker -- Builds a Docker container image that can be used for testing. If the DOCKER_TAG environment variable is set, the image is given this name. Otherwise, the image is not named.

Cargo

Usually, Cargo, Rust's package manager, is used to build and test this project. If you don't have Cargo installed, we suggest getting it via https://rustup.rs/.

Repository Structure

This project is broken into many small libraries, or crates, so that components may be compiled & tested independently. The following crate targets are especially important:

Code of conduct

This project is for everyone. We ask that our users and contributors take a few minutes to review our code of conduct.

Security

We test our code by way of fuzzing and this is described in FUZZING.md.

A third party security audit focused on fuzzing Linkerd2-proxy was performed by Ada Logics in 2021. The full report is available here.

Download Details: 
Author: linkerd
Source Code: https://github.com/linkerd/linkerd2-proxy 
License: Apache-2.0
 

#rust #programming #developer #linkerd #kubernetes

What is GEEK

Buddha Community

Linkerd2 Proxy: Ultralight Service Mesh for Kubernetes, Written in Rus
Christa  Stehr

Christa Stehr

1602964260

50+ Useful Kubernetes Tools for 2020 - Part 2

Introduction

Last year, we provided a list of Kubernetes tools that proved so popular we have decided to curate another list of some useful additions for working with the platform—among which are many tools that we personally use here at Caylent. Check out the original tools list here in case you missed it.

According to a recent survey done by Stackrox, the dominance Kubernetes enjoys in the market continues to be reinforced, with 86% of respondents using it for container orchestration.

(State of Kubernetes and Container Security, 2020)

And as you can see below, more and more companies are jumping into containerization for their apps. If you’re among them, here are some tools to aid you going forward as Kubernetes continues its rapid growth.

(State of Kubernetes and Container Security, 2020)

#blog #tools #amazon elastic kubernetes service #application security #aws kms #botkube #caylent #cli #container monitoring #container orchestration tools #container security #containers #continuous delivery #continuous deployment #continuous integration #contour #developers #development #developments #draft #eksctl #firewall #gcp #github #harbor #helm #helm charts #helm-2to3 #helm-aws-secret-plugin #helm-docs #helm-operator-get-started #helm-secrets #iam #json #k-rail #k3s #k3sup #k8s #keel.sh #keycloak #kiali #kiam #klum #knative #krew #ksniff #kube #kube-prod-runtime #kube-ps1 #kube-scan #kube-state-metrics #kube2iam #kubeapps #kubebuilder #kubeconfig #kubectl #kubectl-aws-secrets #kubefwd #kubernetes #kubernetes command line tool #kubernetes configuration #kubernetes deployment #kubernetes in development #kubernetes in production #kubernetes ingress #kubernetes interfaces #kubernetes monitoring #kubernetes networking #kubernetes observability #kubernetes plugins #kubernetes secrets #kubernetes security #kubernetes security best practices #kubernetes security vendors #kubernetes service discovery #kubernetic #kubesec #kubeterminal #kubeval #kudo #kuma #microsoft azure key vault #mozilla sops #octant #octarine #open source #palo alto kubernetes security #permission-manager #pgp #rafay #rakess #rancher #rook #secrets operations #serverless function #service mesh #shell-operator #snyk #snyk container #sonobuoy #strongdm #tcpdump #tenkai #testing #tigera #tilt #vert.x #wireshark #yaml

Roberta  Ward

Roberta Ward

1598169240

From Service Mess to Service Mesh

Introduction

Over the last 10 years, the rapid adoption of microservices architecture has resulted in enterprises with hundreds or (sometimes even thousands) of services. With the growth of containerization technologies like Docker and Kubernetes, microservice patterns have seen the strongest growth; resulting in a complex dependency matrix between these micro-services. For teams to monitor, support, and to maintain these services is becoming a challenge so most enterprises have invested in some kind of microservices management tool.

This article will explore some of the common aspects of microservice management. Then we’ll take a closer look at the centralized gateway pattern, as well as its limitations (most enterprises have started with or currently still use this pattern). Then we will look into a new pattern called “Service Mesh” which has gained a lot of attention in the last 3–4 years. Often this pattern is also referred to as the “Side Car Proxy”. So lets get started!

Micro-Services Management

As enterprises start building more and more microservices, it’s becoming clear that some of the aspects of microservices are common across all microservices. So it makes sense to provide a common platform for managing these common aspects. Below are some of the key common aspects:

Service Registration and Discovery: A commonplace to register, document, search and discover microservices

Service Version Management: Ability to run multiple versions of a microservice.

**Authentication and Authorization: **Handle authentication and authorization including Mutual TLS (MTLS) between services.

Service Observability: Ability to monitor end to end traffic between services, response times, and quickly identify failures and bottlenecks.

**Rate Limiting: **Define threshold limits that traffic services can handle.

Circuit Breaker: Ability to configure and introduce a circuit breaker in case of failure scenarios (to avoid flooding downstream services with requests).

**Retry Logic: **Ability to configure and introduce retry logic dynamically in services.

So it’s a good idea to build these concerns as part of a common framework or service management tool. As a result, micro-service development teams don’t have to build these aspects in the service itself.

#service-mesh #istio-service-mesh #microservices #gateway-service #envoy-proxy

A Kubernetes Service Mesh Tool Comparison for 2020

Service mesh is not a new concept, but its implementation for connecting microservices running on top of Kubernetes as a containerization platform makes the idea of having a service mesh more popular. Without a service mesh, each microservice needs to be configured to accept (and send) connections to other microservices it needs to communicate with. Service mesh changes that completely.

#kubernetes #kubernetes service mesh #service mesh tool comparison

Fannie  Zemlak

Fannie Zemlak

1597494060

Open Service Mesh — Microsoft’s SMI based Open Source Service Mesh Implementation

Microsoft’s Open Service Mesh is an SMI-compliant, lightweight service mesh being run as an open source project. Backed by service-mesh partners including HashiCorp, Solo.io, and Buoyant, Microsoft introduced the Service Mesh Interface last year with the goal of helping end users and software vendors work with the myriad choices presented by service mesh technology by providing a set of specification standards. OSM can be considered as a reference implementation of SMI, one that builds on existing service mesh components and concepts.

Open Service Mesh data plane is architecturally based on the Envoy proxy and implements the go-control-plane xDS v3 API. However, despite the fact that Envoy comes with OSM by default, using standard interfaces allows it to be integrated with other reverse proxies (compatible with xDS).

SMI follows in the footsteps of existing Kubernetes resources, like Ingress and Network Policy, which also do not provide an implementation where required interfaces to interact with Kubernetes are facilitated for providers to plug their products. The SMI specification instead defines a set of common APIs that allow mesh providers to deliver their own implementations. This means mesh providers can either use SMI APIs directly or build operators to translate SMI to native APIs.

Image for post

SMI Implementation

With OSM, users can use SMI and Envoy on Kubernetes and get a simplified service-mesh implementation. The SMI ecosystem already has multiple providers like Istio, Linkerd, Consul Connect, now Open Service Mesh etc. some of them have implemented SMI compatibility using adaptors (Istio, Consul Connect) and others (OSM, Linkerd etc.) consume the SMI APIs directly.

OSM implementation is very similar to Linkerd which also directly consumes SMI APIs without any need for an adaptor like Istio, but one key difference is that OSM uses Envoy for its proxy and communication bus, whereas Linkerd uses linkerd2-proxy (rust based — lighter than Envoy).

Architecture & Components

OSM control plane comprise four core components. All these four components are implemented as a single controller entity (Kubernetes pod/deployment), this is much lighter in weight when compared with older versions of Istio where there are 4 control plane components (Istio-1.6 introduced istiod which unifies all the control plane components into one binary).

Image for post

OSM Architecture — Components

OSM Data Plane — Uses Envoy as reverse-proxy by default — similar to most other Service Mesh providers (Linkerd is unique in this case which uses ultralight transparent proxy written in Rust). While by default OSM ships with Envoy, the design utilizes interfaces (An interface type in Go is kind of definition. It defines and describes the exact methods that some other type must have), which enable integrations with any xDS compatible reverse-proxy. The dynamic configuration of all the proxies is handled by OSM controller using Envoy xDS go-control-plane.

#service-mesh #istio-service-mesh #kubernetes #azure #microsoft

Dylan  Iqbal

Dylan Iqbal

1643273029

Linkerd2 Proxy: Ultralight Service Mesh for Kubernetes, Written in Rus

This repo contains the transparent proxy component of Linkerd2. While the Linkerd2 proxy is heavily influenced by the Linkerd 1.X proxy, it comprises an entirely new codebase implemented in the Rust programming language.

This proxy's features include:

  • Transparent, zero-config proxying for HTTP, HTTP/2, and arbitrary TCP protocols.
  • Automatic Prometheus metrics export for HTTP and TCP traffic;
  • Transparent, zero-config WebSocket proxying;
  • Automatic, latency-aware, layer-7 load balancing;
  • Automatic layer-4 load balancing for non-HTTP traffic;
  • Automatic TLS (experimental);
  • An on-demand diagnostic tap API.

This proxy is primarily intended to run on Linux in containerized environments like Kubernetes, though it may also work on other Unix-like systems (like macOS).

The proxy supports service discovery via DNS and the linkerd2 Destination gRPC API.

The Linkerd project is hosted by the Cloud Native Computing Foundation (CNCF).

Building the project

A Makefile is provided to automate most build tasks. It provides the following targets:

  • make build -- Compiles the proxy on your local system using cargo
  • make clean -- Cleans the build target on the local system using cargo clean
  • make test -- Runs unit and integration tests on your local system using cargo
  • make test-flakey -- Runs all tests, including those that may fail spuriously
  • make package -- Builds a tarball at target/release/linkerd2-proxy-${PACKAGE_VERSION}.tar.gz. If PACKAGE_VERSION is not set in the environment, the local git SHA is used.
  • make docker -- Builds a Docker container image that can be used for testing. If the DOCKER_TAG environment variable is set, the image is given this name. Otherwise, the image is not named.

Cargo

Usually, Cargo, Rust's package manager, is used to build and test this project. If you don't have Cargo installed, we suggest getting it via https://rustup.rs/.

Repository Structure

This project is broken into many small libraries, or crates, so that components may be compiled & tested independently. The following crate targets are especially important:

Code of conduct

This project is for everyone. We ask that our users and contributors take a few minutes to review our code of conduct.

Security

We test our code by way of fuzzing and this is described in FUZZING.md.

A third party security audit focused on fuzzing Linkerd2-proxy was performed by Ada Logics in 2021. The full report is available here.

Download Details: 
Author: linkerd
Source Code: https://github.com/linkerd/linkerd2-proxy 
License: Apache-2.0
 

#rust #programming #developer #linkerd #kubernetes