Skip to content

Commit

Permalink
Merge pull request #11 from ppeble/1.14-updates
Browse files Browse the repository at this point in the history 
 Fix metadata for 1.14 navigation (and drop old 2.X versions) #10
  • Loading branch information
@ppeble
ppeble authored Sep 9, 2024
2 parents fba5585 + c0afada commit 67f03b0
Show file tree
Hide file tree
Showing 1,364 changed files with 1,528 additions and 94,315 deletions.
4 changes: 4 additions & 0 deletions content/en/docs/1.14/about/_index.md
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,4 @@
---
title: "About"
weight: 10
---
10 changes: 6 additions & 4 deletions content/en/docs/1.14/about/alternatives.md
View file
Original file line number Diff line number Diff line change
@@ -1,6 +1,8 @@
# $productName$ vs. other software
---
title: "Alternatives"
---

Alternatives to the $productName$ fall into three basic categories:
Alternatives to the Emissary fall into three basic categories:

* Hosted API gateways, such as the [Amazon API gateway](https://aws.amazon.com/api-gateway/).
* Traditional API gateways, such as [Kong](https://konghq.org/).
Expand All @@ -12,8 +14,8 @@ Both hosted API gateways and traditional API gateways are:
* Not Kubernetes-native. They're typically configured using REST APIs, making it challenging to adopt cloud-native patterns such as GitOps and declarative configuration.
* [Designed for API management, versus microservices](../../topics/concepts/microservices-api-gateways).

A Layer 7 proxy can be used as an API gateway, but typically requires additional bespoke development to support microservices use cases. In fact, many API gateways package the additional features needed for an API gateway on top of an L7 proxy. The $productName$ uses Envoy, while Kong uses NGINX. If you're interested in deploying Envoy directly, we've written an [introductory tutorial](https://www.datawire.io/guide/traffic/getting-started-lyft-envoy-microservices-resilience/).
A Layer 7 proxy can be used as an API gateway, but typically requires additional bespoke development to support microservices use cases. In fact, many API gateways package the additional features needed for an API gateway on top of an L7 proxy. The Emissary uses Envoy, while Kong uses NGINX. If you're interested in deploying Envoy directly, we've written an [introductory tutorial](https://www.datawire.io/guide/traffic/getting-started-lyft-envoy-microservices-resilience/).

## Istio

[Istio](https://istio.io) is an open-source service mesh, built on Envoy. A service mesh is designed to manage East/West traffic (traffic between servers and your data center), while an API gateway manages North/South traffic (in and out of your data center). Documentation on how to deploy the $productName$ with Istio is [here](../../howtos/istio). In general, we've found that North/South traffic is quite different from East/West traffic (i.e., you don't control the client in the North/South use case).
[Istio](https://istio.io) is an open-source service mesh, built on Envoy. A service mesh is designed to manage East/West traffic (traffic between servers and your data center), while an API gateway manages North/South traffic (in and out of your data center). Documentation on how to deploy the Emissary with Istio is [here](../../howtos/istio). In general, we've found that North/South traffic is quite different from East/West traffic (i.e., you don't control the client in the North/South use case).
56 changes: 29 additions & 27 deletions content/en/docs/1.14/about/faq.md
View file
Original file line number Diff line number Diff line change
@@ -1,53 +1,55 @@
# Frequently Asked Questions
---
title: Frequently Asked Questions
---

## General

### Why $productName$?
### Why Emissary?

Kubernetes shifts application architecture for microservices, as well as the
development workflow for a full-cycle development. $productName$ is designed for
development workflow for a full-cycle development. Emissary is designed for
the Kubernetes world with:

* Sophisticated traffic management capabilities (thanks to its use of [Envoy Proxy](https://www.envoyproxy.io)), such as load balancing, circuit breakers, rate limits, and automatic retries.
* API management capabilities such as a developer portal and OpenID Connect integration for Single Sign-On.
* A declarative, self-service management model built on Kubernetes Custom Resource Definitions, enabling GitOps-style continuous delivery workflows.

We've written about [the history of $productName$](https://blog.getambassador.io/building-ambassador-an-open-source-api-gateway-on-kubernetes-and-envoy-ed01ed520844), [Why $productName$ In Depth](../why-ambassador), [Features and Benefits](../features-and-benefits) and about the [evolution of API Gateways](../../topics/concepts/microservices-api-gateways/).
We've written about [the history of Emissary](https://blog.getambassador.io/building-ambassador-an-open-source-api-gateway-on-kubernetes-and-envoy-ed01ed520844), [Why Emissary In Depth](../why-ambassador), [Features and Benefits](../features-and-benefits) and about the [evolution of API Gateways](../../topics/concepts/microservices-api-gateways/).

### What's the difference between the $OSSproductName$ and the $AESproductName$?
### What's the difference between the Emissary and the Ambassador Edge Stack?

The $OSSproductName$ was the name of the original open-source project. As the project evolved, we realized that the functionality we were building had extended far beyond an API Gateway. In particular, the $AESproductName$ is intended to provide all the functionality you need at the edge -- hence, an "edge stack." This includes an API Gateway, ingress controller, load balancer, developer portal, and more.
The Emissary was the name of the original open-source project. As the project evolved, we realized that the functionality we were building had extended far beyond an API Gateway. In particular, the Ambassador Edge Stack is intended to provide all the functionality you need at the edge -- hence, an "edge stack." This includes an API Gateway, ingress controller, load balancer, developer portal, and more.

### How is $AESproductName$ licensed?
### How is Ambassador Edge Stack licensed?

The core $OSSproductName$ is open source under the Apache Software License 2.0. The GitHub repository for the core is [https://github.com/datawire/ambassador](https://github.com/datawire/ambassador). Some additional features of the $AESproductName$ (e.g., Single Sign-On) are not open source and available under a proprietary license.
The core Emissary is open source under the Apache Software License 2.0. The GitHub repository for the core is [https://github.com/datawire/ambassador](https://github.com/datawire/ambassador). Some additional features of the Ambassador Edge Stack (e.g., Single Sign-On) are not open source and available under a proprietary license.

### Can I use the add-on features for $AESproductName$ for free?
### Can I use the add-on features for Ambassador Edge Stack for free?

Yes! The core functionality of the $AESproductName$ is free and has no limits whatsoever. If you wish to use one of our additional, proprietary features such as Single Sign-On, you can get a free community license for up to 5 requests per second. Please contact [sales](/contact-us/) if you need more than 5 RPS.
Yes! The core functionality of the Ambassador Edge Stack is free and has no limits whatsoever. If you wish to use one of our additional, proprietary features such as Single Sign-On, you can get a free community license for up to 5 requests per second. Please contact [sales](/contact-us/) if you need more than 5 RPS.

For more details on core unlimited features and premium features, see the [editions page](/editions).

### How does $productName$ use Envoy Proxy?
### How does Emissary use Envoy Proxy?

$productName$ uses [Envoy Proxy](https://www.envoyproxy.io) as its core proxy. Envoy is an open-source, high-performance proxy originally written by Lyft. Envoy is now part of the Cloud Native Computing Foundation.
Emissary uses [Envoy Proxy](https://www.envoyproxy.io) as its core proxy. Envoy is an open-source, high-performance proxy originally written by Lyft. Envoy is now part of the Cloud Native Computing Foundation.

### Is $productName$ production ready?
### Is Emissary production ready?

Yes. Thousands of organizations, large and small, run $productName$ in production.
Yes. Thousands of organizations, large and small, run Emissary in production.
Public users include Chick-Fil-A, ADP, Microsoft, NVidia, and AppDirect, among others.

### What is the performance of $productName$?
### What is the performance of Emissary?

There are many dimensions to performance. We published a benchmark of [$productName$ performance on Kubernetes](/resources/envoyproxy-performance-on-k8s/). Our internal performance regressions cover many other scenarios; we expect to publish more data in the future.
There are many dimensions to performance. We published a benchmark of [Emissary performance on Kubernetes](/resources/envoyproxy-performance-on-k8s/). Our internal performance regressions cover many other scenarios; we expect to publish more data in the future.

### What's the difference between a service mesh (such as Istio) and $productName$?
### What's the difference between a service mesh (such as Istio) and Emissary?

Service meshes focus on routing internal traffic from service to service
("east-west"). $productName$ focuses on traffic into your cluster ("north-south").
While both a service mesh and $productName$ can route L7 traffic, the reality is that
these use cases are quite different. Many users will integrate $productName$ with a
service mesh. Production customers of $productName$ have integrated with Consul,
("east-west"). Emissary focuses on traffic into your cluster ("north-south").
While both a service mesh and Emissary can route L7 traffic, the reality is that
these use cases are quite different. Many users will integrate Emissary with a
service mesh. Production customers of Emissary have integrated with Consul,
Istio, and Linkerd2.

## Common Configurations
Expand All @@ -56,7 +58,7 @@ Istio, and Linkerd2.

Established users will want to better control 404 behavior both for usability and
security. You can leverage the Mapping resource to implement this functionality to
your cluster. $productName$ users can use a 'catch-all' mapping using the '/'
your cluster. Emissary users can use a 'catch-all' mapping using the '/'
prefix in a mapping configuration. The simplest mapping, described below, returns only 404 text.
To use a custom 404 landing page, simply insert your service and remove the rewrite value.

Expand All @@ -78,7 +80,7 @@ For more information on the Mapping resource, see [Advanced Mapping Configuratio
In a production environment, public access to the console and admin endpoints is not an
ideal situation. To solve this, we will be using an Ambassador Module to remove the default
mappings and create a new, host-based mapping to expose the Admin endpoint more securely. The
Ambassador module applies system-wide configuration settings for $productName$ to follow.
Ambassador module applies system-wide configuration settings for Emissary to follow.
```yaml
apiVersion: getambassador.io/v2
Expand Down Expand Up @@ -113,7 +115,7 @@ learn more about Ambassador Module configurations, see [Ambassador Module](../..
## Troubleshooting
### How do I get help for $productName$?
### How do I get help for Emissary?
We have an online [Slack community](http://a8r.io/slack) with thousands of
users. We try to help out as often as possible, although we can't promise a
Expand All @@ -122,10 +124,10 @@ contracts. [Contact sales](/contact-us/) for more information.
### What do I do when I get the error `no healthy upstream`?

This error means that $productName$ could not connect to your backend service.
This error means that Emissary could not connect to your backend service.
Start by verifying that your backend service is actually available and
responding by sending an HTTP response directly to the pod. Then, verify that
$productName$ is routing by deploying a test service and seeing if the mapping
Emissary is routing by deploying a test service and seeing if the mapping
works. Then, verify that your load balancer is properly routing requests to
$productName$. In general, verifying each network hop between your client and
Emissary. In general, verifying each network hop between your client and
backend service is critical to finding the source of the problem.
26 changes: 14 additions & 12 deletions content/en/docs/1.14/about/features-and-benefits.md
View file
Original file line number Diff line number Diff line change
@@ -1,39 +1,41 @@
# Features and benefits
---
title: Features and Benefits
---

In cloud-native organizations, developers frequently take on responsibility for the full development lifecycle of a service, from development to QA to operations. $productName$ was specifically designed for these organizations where developers have operational responsibility for their service(s).
In cloud-native organizations, developers frequently take on responsibility for the full development lifecycle of a service, from development to QA to operations. Emissary was specifically designed for these organizations where developers have operational responsibility for their service(s).

As such, the $productName$ is designed to be used by both developers and operators.
As such, the Emissary is designed to be used by both developers and operators.

## Self-Service via Kubernetes Annotations

$productName$ is built from the start to support _self-service_ deployments -- a developer working on a new service doesn't have to go to Operations to get their service added to the mesh, they can do it themselves in a matter of seconds. Likewise, a developer can remove their service from the mesh, or merge services, or separate services, as needed, at their convenience. All of these operations are performed via Kubernetes annotations, so it can easily integrate with your existing development workflow.
Emissary is built from the start to support _self-service_ deployments -- a developer working on a new service doesn't have to go to Operations to get their service added to the mesh, they can do it themselves in a matter of seconds. Likewise, a developer can remove their service from the mesh, or merge services, or separate services, as needed, at their convenience. All of these operations are performed via Kubernetes annotations, so it can easily integrate with your existing development workflow.

## Flexible canary deployments

Canary deployments are an essential component of cloud-native development workflows. In a canary deployment, a small percentage of production traffic is routed to a new version of a service to test it under real-world conditions. $productName$ allows developers to easily control and manage the amount of traffic routed to a given service through annotations. [This tutorial](https://www.datawire.io/faster/canary-workflow/) covers a complete canary workflow using the $productName$.
Canary deployments are an essential component of cloud-native development workflows. In a canary deployment, a small percentage of production traffic is routed to a new version of a service to test it under real-world conditions. Emissary allows developers to easily control and manage the amount of traffic routed to a given service through annotations. [This tutorial](https://www.datawire.io/faster/canary-workflow/) covers a complete canary workflow using the Emissary.

## Kubernetes-native architecture

$productName$ relies entirely on Kubernetes for reliability, availability, and scalability. For example, $productName$ persists all state in Kubernetes, instead of requiring a separate database. Scaling the $productName$ is as simple as changing the replicas in your deployment, or using a [horizontal pod autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/).
Emissary relies entirely on Kubernetes for reliability, availability, and scalability. For example, Emissary persists all state in Kubernetes, instead of requiring a separate database. Scaling the Emissary is as simple as changing the replicas in your deployment, or using a [horizontal pod autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/).

$productName$ uses [Envoy](https://www.envoyproxy.io) for all traffic routing and proxying. Envoy is a modern L7 proxy that is used in production at companies including Lyft, Apple, Google, and Stripe.
Emissary uses [Envoy](https://www.envoyproxy.io) for all traffic routing and proxying. Envoy is a modern L7 proxy that is used in production at companies including Lyft, Apple, Google, and Stripe.

## gRPC and HTTP/2 support

$productName$ fully supports gRPC and HTTP/2 routing, thanks to Envoy's extensive capabilities in this area. See [gRPC and the $productName$](../../howtos/grpc) for more information.
Emissary fully supports gRPC and HTTP/2 routing, thanks to Envoy's extensive capabilities in this area. See [gRPC and the Emissary](../../howtos/grpc) for more information.

## Istio Integration

$productName$ integrates with the [Istio](https://istio.io) service mesh as the edge proxy. In this configuration, $productName$ routes external traffic to the internal Istio service mesh. See [Istio and the $productName$](../../howtos/istio) for details.
Emissary integrates with the [Istio](https://istio.io) service mesh as the edge proxy. In this configuration, Emissary routes external traffic to the internal Istio service mesh. See [Istio and the Emissary](../../howtos/istio) for details.

## Authentication

$productName$ supports authenticating incoming requests with a [custom authentication service](../../howtos/basic-auth/), and $AESproductName$ natively supports OAuth/OpenID Connect, or JWT. When configured, the $AESproductName$ will check with a third party authentication service prior to routing an incoming request. For more information, see the [authentication guide](/docs/edge-stack/latest/topics/using/filters/).
Emissary supports authenticating incoming requests with a [custom authentication service](../../howtos/basic-auth/), and Ambassador Edge Stack natively supports OAuth/OpenID Connect, or JWT. When configured, the Ambassador Edge Stack will check with a third party authentication service prior to routing an incoming request. For more information, see the [authentication guide](/docs/edge-stack/latest/topics/using/filters/).

## Rate limiting

$productName$ supports rate limiting incoming requests. When configured, the $productName$ will check with a third party rate limit service prior to routing an incoming request. For more information, see the [rate limiting guide](../../topics/using/rate-limits/).
Emissary supports rate limiting incoming requests. When configured, the Emissary will check with a third party rate limit service prior to routing an incoming request. For more information, see the [rate limiting guide](../../topics/using/rate-limits/).

## Integrated UI

$productName$ includes a diagnostics service so that you can quickly debug issues associated with configuring the $productName$. For more information, see [running $productName$ in Production](../../topics/running).
Emissary includes a diagnostics service so that you can quickly debug issues associated with configuring the Emissary. For more information, see [running Emissary in Production](../../topics/running).
Loading

0 comments on commit 67f03b0

Please sign in to comment.