Loading video player...
Welcome to another episode of the
gateway API series for Kubernetes. If
you're new to the Kubernetes Gateway API
and this is your first time hearing of
it, this video is probably not for you.
You need to watch this video first,
which is our introduction to Gateway
API. In that video, we cover what
Gateway API is, how it works, how to
enable it in your cluster, and how to
use all of the traffic routing features.
In this video, we'll use our gateway API
enabled cluster we created in the
previous episode and we'll focus on a
specific implementation of gateway API
called traffic. This series is aimed to
help you understand the capabilities of
the different gateway API
implementations so you get a feel for
their features, their pros and cons, and
it helps you decide which one is best
for you. So, be sure to like, subscribe,
hit the bell so you know when the next
episode drops. And without further ado,
let's go. [music]
[music]
In a previous video, we've created a
Kubernetes cluster using a utility
called kind. We installed the gateway
API CRDs using cubectl. This gave us
access to some of the new CRDs like
gateway class, gateways, HTTP routes,
TLS routes, TCP routes, UDP routes, and
more. We also created some example
applications. So a Python micros
service, a Go micros service as well as
a HTML front end that makes an HTTP post
call to the Go service. We've applied
all of this using cubectl. This gave us
a proper micros service environment that
we can use for testing. We also created
some test domains like exampleapp.com
that can be used as a central domain. So
we can use it like an API gateway
[music] and route traffic based on path.
We also have domains for each specific
service. So we can route by domain. Now
this will go ahead and enable our
Kubernetes cluster with gateway API
capabilities and also give us some
example applications we can use for
testing. Now we know by now that the
first thing we're going to need to use
gateway API is to define a gateway
class. So the gateway class basically
define what controllers are available to
the cluster. So since in this video
we're taking a look at traffic, we're
going to need a gateway class to tell
our cluster that we support a traffic
gateway API controller. So this is a
simple YAML file with we apply to our
cluster. And this is what the gateway
API class looks like. We give it a name
called traffic. And the controller name
is going to be set to the controller
that we will install in our cluster. So
remember gateway classes are the things
the infrastructure providers provide to
the Kubernetes cluster which defines the
load balancing technology available for
us to use. So the first thing I'm going
to do is apply that gateway class. So I
pop over to my terminal and I go ahead
and paste that. That creates the gateway
class for us. I can then say cubectl get
gateway class and we can see it's there
but it's not yet accepted. You see
accepted is unknown. I always like to
use the describe command to describe the
resource to take a look at it. And we
can see that it is waiting on the
controller. It's pending. It's not yet
accepted. That's because we don't have a
gateway API controller yet. This is a
good way to troubleshoot whether your
gateway API installation is actually
working. Start by taking a look at the
gateway class. So we start with the
gateway class. Define the load balancing
technology for our cluster. Then we take
a look at a gateway. Now the gateway
class can live at a global level. It's
not in a namespace. The gateway however
can be in a namespace which means we can
do quite a lot with it. We can have a
different gateway per namespace which is
taken care of by a different gateway
class. We can have one central gateway
for our traffic controller. That depends
on how granular you want to set it up.
It's very modular. The gateway is
basically just a YAML object that
describes how traffic is accepted into
our cluster. things like ports and TLS
certificates. So then we can proceed by
just applying the gateway for traffic.
Now the gateway has a little bit more to
it. It's kind of as gateway. You can
give it a name. So you can either call
it something like traffic gateway API or
traffic gateway so people can see the
implementation of the gateway they can
attach routes to or we can just use a
generic name and hide the
implementation. That's totally up to
you. I call my gateway gateway API. I'm
going to put it in the default name
space because that's where all my
example apps are. Then I give it a
class. This is the class name of the
gateway class we defined earlier. This
means that this gateway will know what
controller will implement it by looking
at this class. This also gives us the
flexibility to have different gateways
attaching to different classes. So you
can have a traffic gateway API, you can
have an STO one, an envoy and separate
them by classes. And this is the most
important field on the gateway is the
listeners. Listeners allow us to define
how traffic comes into the cluster.
Basically their port configuration. So
here we have a listener for HTTP and one
for HTTPS. So I can define the protocol
as well as the port. So here I have port
80 and on this one here I have port 443.
Protocol is HTTPS. The only difference
here is that the HTTPS one has a TLS
setting. basically telling the gateway
how we want to deal with TLS. In this
case, I'm going to terminate TLS at the
gateway level. This means I don't have
to worry about passing TLS certificates
upstream. So, if I have a lot of
microservices, they don't need to
implement TLS. They can simply run on
HTTP and TLS gets offloaded at the
gateway API level. Here I specify my
certificate and the cool thing here is I
can put my certificate in any name
space. So we can centralize the
certificate even further. In the old
ingress implementations, you used to
have to put TLS certificates in each
namespace where the ingresses were
running. Now with gateway API, you can
move them and centralize them and
specify them in the gateway. So that's
the only difference between the HTTP and
the HTTPS. The other field that's
important is the allowed routes field.
This is where we define what routes are
allowed to attach to this listener. So
here we can say same. That means only
routes in this same namespace as this
gateway which is in the default
namespace. Only those routes are allowed
to be attached. We can say all which
means across all namespaces or we can
use a selector which uses label
selectors. So we can be really specific
here about what routes can be accepted
by this gateway. The same setting is
also on the TLS listener. So I can then
hop over to my terminal go ahead and
apply that gateway. I can then do
cubectl get gateway and we can see that
it is unknown. We don't have a gateway
controller deployed just yet. I can then
go ahead and say cubectl describe and
take a look at that gateway and we can
see it's still pending has not yet been
accepted. So the next step for us is to
go ahead and deploy a gateway API
controller. In our case we're going to
be taking a look at traffic. Notice that
so far we've just been dealing with
generic gateway API objects. These are
the same across all the different
gateway APIs. So nothing here is
specific to traffic at this stage. Now
the first thing to know about traffic is
that it's a single static binary. It
runs in one pod by default which you can
scale up and it's extremely simple to
use. Its configuration is really simple
and it can also run as an ingress
controller as well as a gateway API.
This means you can use this controller
to support both of the implementations.
So the best place to start with traffic
is the documentation. So what is
traffic? Traffic is a proxy. So it
allows us to take traffic into our
cluster either internal or external. It
provides security features, traffic
management integration and
extensibility. We'll take a look at this
as well as observability. And then it
has the capability to route to upstream
back-end servers. These can be any type
of servers. In this video, we'll take a
look at specifically on Kubernetes. And
at the top here, it indicates that it
supports ingress as well as gateway API.
The documentation has a getting started
guide so you can run traffic as a docker
container as well as a pod in kubernetes
deploying it using helm. Traffic
provides a helm chart that we can use to
install the traffic controller. By
default, it opens up port 80 and 443. It
has a dashboard and it enables the
kubernetes gateway API provider. It also
gives you a basic values file that you
can take a look at here. Now there are
some defaults here. So for example, if
you enable the Kubernetes gateway, what
traffic will do is it will go ahead and
install the CRDs we've done manually. So
you can skip the setup steps with we
followed earlier by manually installing
the CRDs. I prefer to decouple that
process from the gateway API
implementation. I'd prefer not to have
traffic install the CRDs for me just in
case I want a different gateway API
controller. I'd like to decouple this
and use something like a GitHops
process, something like Flux to deploy
your CRDs for you and keep it separate
from the gateway API. And on GitHub,
you'll find the default values file. So
here you can do a lot of things like set
the image if you're building it
yourself. Here you can set values for
the deployment like number of replicas,
pod disruption budgets. You can set the
ingress class names because remember
that traffic is an ingress controller as
well. And here you can set things like
gateway enabled equals true which is
true by default. And if you have
providers Kubernetes gateway enabled,
it'll also deploy a default gateway. So
by default, this Helm chart can deploy
the CRDs that we've done earlier. It can
also deploy a gateway and a gateway
class automatically. So it provides this
capability to automatically deploy a
gateway if you wanted to and the CRDs
under the provider section. Here you can
customize listeners on the gateway like
the port names and things like that. And
here's the gateway class defaults. You
can customize the gateway class over
here. If you have this enabled which is
enabled by default and if you have the
providers Kubernetes gateway enabled as
well, it'll automatically deploy the
gateway class here. So feel free to take
a look at this extensive values file
where you can customize almost every
aspects of the traffic ingress and
gateway API controller. So I've gone
ahead and created my own values file
that I find quite important with a
couple of fields. Let's first start at
the bottom. I have the gateway which I
disabled because I don't want the
helmchart to deploy a gateway for me. So
I've set up my gateway and my gateway
class already. I've also set up my
gateway class. So I've disabled that
here. So this Helmchart will not install
the gateway and the gateway class. I
have enabled the gateway API controller
provider here. So this will tell the
traffic controller, the actual pod, the
application that runs to enable those
features. If you turn this off, it will
not run as a Kubernetes gateway API.
I've also turned the experimental
channel on because I like to experiment
with all the new features. Remember that
gateway API is quite new and it is
evolving very quickly. And then let's
take a look at the ports section. So I
have specified to open up port 80. This
is useful if you have health probes such
as load balancer health probes in the
cloud or customers may hit port 80 and
you want to force redirect them to 443.
So we have this port open and then we
have our web secure port open which is
443. So when we define our gateway, we
had those listeners, the listener ports
mapped to these ones. And one other
thing that I'd like to enable is just
logs. So log access and log format. So
access logs that I enable like so as
well as the format of those logs. This
is really useful because if you want to
see and monitor the traffic coming in to
your gateway API, you want to turn this
on. and JSON format can be really useful
if you need to parse these logs. So if
you send them to something like Graphana
Loki or Elastic Search, you can parse
the logs and search them quite easily.
And I've left a link here showing the
full field list of what you can enable
in the access logs with an example here
how to drop certain fields. So router
name, I just dropped that as an example.
You can enable to log certain header
values and custom fields that traffic
provides. You can either log them or you
can discard and drop certain logs. So
I've left a link to my values file and I
find these things quite important.
Firstly, I mentioned access logs, the
ports to expose, infrastructure
annotations and labels which you can
also set on the values file. This is
useful if you're using an Azure load
balancer or an AWS load balancer and you
need to set annotations or labels on the
Kubernetes service so that the cloud
controller can make changes for a
specific cloud environment. Then I like
to be able to control the gateway API
things such as the CRDs, the default
classes and default gateways. This means
I can either customize them here or turn
them off completely and manage them
outside with tools like Flux. I've also
put a link here to the default values
file. So installing traffic is very
simple. I simply set a chart version
that I'd like to deploy. Then I run helm
repo add the traffic repo. Do helm repo
update. These are the standard things
you generally do for helm. I also like
to have the helm search repo command
here and list the versions just in case
I want to bump up my version here. This
allows me to pin the version for this
guide. And then I do helm install. I set
the chart version. I set my values file
we've taken a look at. I'm going to
install it in the traffic namespace and
I'm going to ask Helm to create that
namespace. So I go to my terminal, go
ahead and paste that and that will
install my traffic gateway API
controller. So now you can go ahead and
describe those values. Again, if I use
cubectl get, we can see there's no issue
under programmed and our gateway class
has been accepted. If we ever need to
make changes, we can just make changes
in the values file and then just refer
to the helm upgrade command to make any
changes to the gateway API controller.
After the install, I always like to do
cubectl get pods. Make sure the pods are
running. I also like to use cubectl logs
to make sure that the controller is
running. You can see that there's been
an error here. We can ignore that. That
is because our secret for our TLS
certificate [clears throat] is not yet
installed. I'm going to go ahead and
apply the secret in a little bit when we
take a look at setting up TLS. So, we
can just ignore that for now. To start
using the gateway API, what I can do is
just port forward to the traffic
service. And this is useful in testing
environments where you don't have a
cloud load balancer. And you technically
don't need a load balancer to test all
the features of ingress or gateway API.
You can simply port forward. And then we
can just leave this running in the
background. And because we have our host
file set up, we can start making
requests to our example applications.
Now, the gateway API has some native
traffic management features built into
the CRD specification, basic traffic
management, and advanced routing. One
important thing to know is that if you
have a gateway API controller like
traffic or any other one, you should be
able to achieve all of these basic
routing features. So firstly, we can
route by host name. So if you have a
bunch of different domains that need to
go to different upstream services, you
can do so. So I can route example app
python.com to a python service and I can
route example go.com to a go service and
I can do this with the http route. Here
I have two HTTP routes. The first one is
a python one in the default namespace. I
use the parent ref field. This is
important to tell the HTTP route which
gateway to attach to. So we'll be
attaching to the gateway we've just
installed and this is our traffic
gateway. Then I specify the host name.
This is example apython.com. And then I
want to route it to a backend reference
which is my python service. This is a
very basic HTTP route by host name. I
have the same one here for the go
service. So http route give it a name
and name space. Attach it to our
gateway. specify the host name which is
exampleapp go.com and the backend
reference which is the go service. Here
you specify a kubernetes service and
port combination. I can go ahead and
apply that yaml file to create my http
routes and with my port forward running
I can route traffic to my go service by
hitting the go domain and I can hit my
python service by hitting the python
domain. I can also route by path. So I
can either do exact path or an exact
URL. So a URL like exampleapp-python.com
and route that to the python service or
I could use something like path prefix
which says anything. So /star go to the
python service and also pass the
remaining portion of the URL to the
upstream service. This means I can
access any path on the example app.com
and pass that path to my upstream
service. So to do that we can update our
HTTP route but this time under the rule
section we can add a match. So here we
can say match the exact path which is
slash. This means we can only visit the
root of this domain. So example
app-pon.com/
will go to the python service. It won't
support any other URL. We can do the
same with the go service. But exact URL
may not be useful. So we might want to
use something like path prefix. This
will allow us to visit any URL behind
that domain and pass the entire URL to
the upstream. I can jump to my terminal
and apply and update my HTTP route to
route by path. And now you can see I can
still access my application. But this
time I can also access any path
underneath. So here I have / status and
I route that to the status endpoint of
my go service. So routing by path allows
us to route based on a specific path and
we can define what to pass to the
upstream. We can do this by using URL
rewrite. URL rewriting is done by
telling the HTTP route what path we want
to pass to the upstream. So here we can
define a path for the request like
API/Python
and rewrite the URL to slash. We can do
the same for API/go. This means we can
merge our two microservices under the
same domain. This time we just use
exampleapp.com. This also means that we
can forward the remaining path up to the
upstream. So here we can say API/go/star
go up to the go service. This means we
can pass the status endpoint to the go
service like so. And to look at how to
do URL rewriting, we have the HTTP route
but this time we've updated our rules.
We have our match section as path
prefix. So our prefix is / API/python.
And then we specify the filter. And the
filter has a type. There are many types
you can pass in. And as gateway API
grows, more types may be added. You may
have things like cores, external,
oorthth, upstream authentication and
things like that. Here we're using the
type as URL rewrite and it takes these
fields. So it has a type to say what to
do. Here we say we want to replace the
prefix. So we want to replace this API/
Python with slash. This means we won't
pass API/Python to the upstream only
what's behind it. So this becomes our
prefix and we'll route that to the
Python service. I do the same thing with
the Go API. So I have my HTTP route and
I have the same match for the path
prefix and the same URL rewrite. I jump
to my terminal. I go ahead and update
that. And now I can go to
exampleapp.com/api/go/stus
and we can hit the status page. So this
is passing /st status to our upstream go
service and replacing the /appi/go
using URL rewrite with HTTP routes. We
can also modify request and response
headers. So we can do manipulation of
the request and the response headers
using this response and request header
modifier filter. In my introduction to
gateway API, I show this one in action
by doing a simple chorus header
manipulation. So to do that you have
your HTTP route and we still have our
rule that matches our path prefix such
as API/go but this time we add a type
filter which is called response header
modifier. This means we want to modify
the response header and we indicate
under the fields what type of action we
want to take. So we say add. You can say
add and remove and that sort of thing.
Allows you to manipulate headers either
add or remove them. Here I pass a name
and a value of the headers I would like
to add specifically course headers and
then I continue to have my URL rewrite
over here. So if I port forward to the
basic web app that I have and I open up
localhost 8000 and I try to make a
request to this go API you can see I get
a cause error. I can then go ahead and
apply this header modifier. Go ahead and
apply that port forward again. Go back
and make that request again. And we can
see it now succeeds. If you use the
browser tools and you look at that
request, you can see the corores headers
have been added. Now, as of the time of
this recording, corores is not yet
supported. But there is a specific
filter type for cores coming in the
future. I believe it may be part of the
experimental channel, but it's not
implemented by all the gateway API
controllers just yet. You can also deal
with cores by using traffic's own
middleware, which we'll take a look at
in a bit. Now, with traffic, we can also
enable TLS. And I mentioned earlier that
we need a TLS certificate. So I like to
use makeert to make local browser
trusted certificates that I can use for
testing. I've left instructions here.
You can run curl to get makes it. You
specify the locations for the CA to use.
And then you run make itert to generate
a key and a certificate. And then we can
go ahead and say cubectl create secret
create a TLS secret in our cluster by
pointing to that certificate. So now I
can go ahead and create that TLS
certificate. This is the one we refer to
in our gateway. So in our gateway for
traffic that we've applied. We have an
HTTPS listener. We have a TLS section.
And under here, we specify the
certificate to use. And as I mentioned
before, this helps us be able to move
the certificate into any name space we
want. Our gateway will reference it from
here. Once our gateway is able to
reference the certificate, now we can go
ahead and update our HTTP route. And
what we need to do is actually add under
the parent reference, we'll need to add
the HTTPS listener as well. So that's
all I need to do under the HTTP route to
enable TLS for my Go. Everything else
remains the same. I jump into my
terminal and I go ahead and make that
change. Then I also have to remember to
go ahead and port forward to 443 because
HTTPS happens over 443. And now I can
hit the HTTPS endpoint for my Go
application. So these are all the basic
routing features for a gateway API.
[music]
One thing I find really powerful about
traffic is its middleware capability.
This is a specific feature to traffic
and you can think of this as plugins.
You can do a lot with middleware and
pretty much everything that you can do
with the native HTTP routes and traffic
management routing features that we've
just taken a look at, you can perform
using traffic middlewares. So things
like cores, modifying request and
response headers, doing URL rewrites and
routing by path, authentication,
rate limiting. You can do all of that
with middlewares. Traffic is also
extremely simple to use. Its
configuration is very similar to
Kubernetes HTTP routes that we've taken
a look at earlier. It's small YAML
snippets. So middleares make traffic
fully featured. It's also extremely
simple to use. And one other cool thing
is middleware is also highly portable
between gateway API and ingress. So you
can have an ingress object and you can
attach a middleware to that. You can
also have a gateway API object such as
an HTTP route and attach a middleware to
that. So if you already use traffic and
you're on something like ingress and you
want to move to gateway API and you're
using middlewares, it becomes quite easy
to do so. I can take my OOTH
authentication middleware that I use on
my ingress and then simply plug it into
my gateway API. The only downside is
that middlewares are sort of vendor
locked to traffic. I can't move over to
ISTTO or another gateway API when it
comes to middleware. So this is traffic
specific as gateway API is still new.
There's a lot of features not yet part
of the HTTP route specification as I
mentioned earlier with cores and there
are other HTTP route features that are
still coming along such as external orth
to allow you to authenticate with an
upstream oorthth server. These features
are still coming but traffic allows you
to get these features by using
middlewares. So one of the key strengths
of traffic is that they have a catalog
of middlewares that you can use and
there are many middlewares available. If
we take a look at the documentation they
can be attached to routers and they're
pieces of middleware which are a means
of tweaking the request before they send
to a service or before the answer from
the service is sent to the client. So it
allows you to modify requests and
response the headers and do some
redirections authentications and so
forth. So there are some middlewares
that allows you to add prefixes. You
have basic authentication. You've got
compression. You can delegate
authentication, add or update headers.
You can do IP whitelisting, rate
limiting, automatic retries, and there's
also a catalog of communitybuilt
middlewares. If middlewares are
something that interests you, there are
also ways to write your own middlewares
using Go. So this can be useful if you
want to write your own custom ones. The
way to use a middleware in traffic is
under the HTTP route object where we
have filters you can add extensions. So
there's a specific type called extension
reference. So you add that as a new item
underneath a filter and then you say
extension reference and then you can
pass a specific type of CRD and a name
of that middleware. So here you say
group is traffic.io and the kind is
middleware. This is specific to the
traffic installation. So that is how you
plug in a middleware to an existing HTTP
route. In order to have extension
references work, you have to add the
Kubernetes CRD enabled underneath the
provider section in your Helmchart. And
we've enabled that in our YAML file
already. So with a simple example, by
using the add prefix middleware, we can
take a path like this and add any prefix
to that. So let's say we have
exampleapp.com/
anything. We can route that to /prefix/
anything and we do that by taking our
http route that we have. Let's take the
go route as an example. We have our
parent reference and our existing match
and this time we're going to under
filter add an extension. And that's how
we plug in a middleware into our HTTP
route. And to configure this middleware,
we need to go ahead and create this as a
YAML object. So if we scroll down, we
can see I have this new object here
called middleware. Its name is add
prefix. And here are its settings. I can
then say my prefix is / prefix. And it
will add this prefix to any URL that is
part of this HTTP route that basically
matches this match. So I can go ahead
and deploy that middleware by saying
cubectl apply and update our HTTP route.
Now if I go to the URL in the browser
and I just say / anything, you can see
I'm hitting a 404 page not found. If I
look at the logs of my Go app, we can
see that we've got a get request with
our prefix being added there. So there
is the add prefix that we specified and
the anything path we're hitting. This
path doesn't exist in my go service, but
you can see our prefix has been added
here. With traffic middleares, we can
also do something like basic HTTP
authentication. This allows users to
access secured resources protected by
usernames and passwords. To do that, I
can use the basic orthare. So here I
have an HTTP route for my GO service.
All the fields remain as is. Here's my
path prefix. We're basically saying all
traffic go to the go service. But here
we plug in an extension middleware
called basic orth. And then if I scroll
down, this is my middleware. So the
middleware for basic orth takes in a
specific secret which is a kubernetes
basic or secret. So I've defined that
down here. I have a secret called
basic-th. Its type is
kubernetes.io/basicorth.
It's basic authentication for http. I
give a username and password. So if I go
ahead and update that, you can see it
will create the secret. It'll create our
middleware and update our HTTP route for
the gateway API. Now if I try to access
my Go application, you can see that I
have a username and password that I have
to fill out. Now I go and specify that
and you can see we're now logged in.
Another example is the headers
middleware and traffic allows us to
manipulate headers too just like the
gateway API specification but this is
traffic's official way to deal with
cores which is actually supported. So we
can deal with cores by using the headers
middleware. Corores is cross origin
resource sharing. So if I go ahead and
port forward to our web app again and we
have our corors demonstration app. We
try to make the request. It's obviously
blocked. This time we can use a traffic
middleware to update our HTTP route and
perform course header manipulation. And
this is how you use the headers
middleware. So we have our HTTP route.
Everything as per normal. We have our
gateway reference, our rules. So this
time I'm going to have my path prefixes
API/go with my URL rewrite that we had
before, but this time I'm going to add
an extension reference for the headers
middleware. And if we scroll down, this
is how you define that middleware. So
kind is middleware. The name is just
headers. That's what I like to call it
so it makes sense. And here is the type.
So this is the headers middleware and
all the fields it supports. So you
provide the access control allow
methods. Here you say what access
control headers you want to allow the
origin list. In this case I'm just using
localhost 8000 because that's where my
request is coming from. And the max age
as well as the vary header. I go to the
terminal. I apply that. And that'll
create my traffic headers middleware and
reference it in my go route. I can then
go back to the app, make another
request, and this time it works. So that
is how you deal with cores using traffic
middleware. It's also worth noting that
there are some advanced middleware
available for things like OOTH
authentication. So, if you're using
something like Google authentication or
Microsoft single sign on or you're using
an open-source oorthth server, you can
route traffic to an external
authentication source using a traffic
middleware. Now, as far as I know, the
native gateway API specification is
planning to support external
authentication in the future. So, that
means in the future you may not need a
middleware in order to do this. But for
now, you can go ahead and use the
forward or middleware. This one
delegates authentication to an external
service. So this middleware looks like
this. Just kind middleware provide a
name and an external address where you
want to forward authentication to. It
also has a bunch of configuration
options specifically around headers and
cookies. This means that your gateway
API will pass authentication through to
an external server like an oorthth
server or an oorthth proxy. When it
comes back, it'll set a cookie in the
browser. If the cookie is not there,
it'll forward back to the signin.
One other thing that I noticed about
traffic is that it has pretty good
observability. Not only does it have its
own dashboard, but it supports the key
pillars of observability like logs,
metrics, and traces. And they're very
easy to turn on and configure. So on the
documentation, there's an observe
section. And under here are logs and
access logs, metrics and tracing. And as
I showed you before, you can customize
your logs and access logs using the
Helm's values file. So we can turn
access logs on. You can do filtering on
status codes, customize the fields, you
can even log headers, and you can also
drop some of the fields in the logs as
well. And very importantly, you can set
the format for the logs as well as well
as set access log filters. The traffic
proxy also supports metrics. And it
looks like this supports metrics with
Prometheus or open telemetry. So you can
also turn this on using the Helm values
in the Helm chart. So it supports
Prometheus metrics and also OTP. So open
telemetry. So you can point it to an
open telemetry collector. It also
supports tracing. This is cool because
then you can trace requests coming
through your cluster. any downstream
services that also uses open telemetry
will also benefit from this because
you'll be able to see transactions
flowing through your whole system. This
is also very easy to enable using the
Helm chart. So you just have a tracing
section and enable OTP and specify your
open telemetry endpoint. Now, if you're
dealing with the latest news of the
EngineX ingress deprecation, you may be
interested in seeing that traffic now
also started supporting ingress engine X
capability. This enables seamless
migration from EngineX ingress to
traffic ingress with some engineext
annotation compatibility. I'd highly
recommend reading through the
documentations here, but it's good to
know that they do have some annotation
support. So if you're currently using
EngineX ingress, these annotations will
look familiar to you. And these are some
of the annotations that traffic now
supports if you're wanting to move from
an enginex ingress controller to a
traffic ingress controller and then
eventually make the hop to gateway API
if you wanted to do so. Now there are a
bunch of annotations supported. So you
can see there are authentication
annotations, SSL and TLS annotations,
session affinity, load balancing and
backend cores and routing ones as well
as some limitations.
So here is my verdict. Traffic is
extremely extremely simple simple to
configure. The configuration options are
self-explanatory. The documentation is
also great at describing all of the
configuration options. What I like about
traffic is that all of the different
configuration snippets are small and
self-explanatory. They are not super
complicated and they are in YAML format
as well. So, they're really readable.
Everything appears to be plugandplay.
For example, you saw that I took some
middleware as small YAML snippets and
plugged them into my gateway API HTTP
route and that they're portable between
ingress and gateway API. So it's a fully
functional ingress controller as well as
gateway API implementation. This means
you don't need highly complex
configuration. You don't need a whole
control plane or a service mesh. You
don't need custom network plugins in
order to support a control plane as you
don't interfere with the cluster
traffic. It's extremely simple and you
can even see that by doing cubectl get
pods. It runs as a single pod with a
single static binary inside. And that is
probably the most attractive thing to me
is just its simplicity. Also, the
middleware system is very simple. It's a
simple plug-andplay feature and it
doesn't seem like something that will
become really messy over time. So, this
to me makes it a great solution as an
ingress controller as well as a stepping
stone into gateway API. So, hopefully
this video helped you learn more about
gateway API by deep diving into traffic.
We'll take a look at more gateway API
implementation in upcoming videos. Let
me know down in the comments below what
gateway API are you using and what is
your experience. And if you like the
video, be sure to like, subscribe, and
hit the bell. And if you want to follow
the DevOps road map, be sure to do so on
Instagram. If you want to [music]
support the channel even further, hit
the join button down below to become a
YouTube member. And as always, thanks
for watching and until next time.
Peace.
Follow the DevOps roadmapππ½ https://www.instagram.com/marceldempers My DevOps Roadmap ππ½ https://marceldempers.dev Patreon ππ½https://patreon.com/marceldempers Checkout the source code below ππ½ and follow along π€ Also if you want to support the channel further, become a member π https://marceldempers.dev/join Checkout "That DevOps Community" too https://marceldempers.dev/community Source Code π§ -------------------------------------------------------------- https://github.com/marcel-dempers/docker-development-youtube-series Like and Subscribe for more :) Follow me on socials! Instagram | https://www.instagram.com/marceldempers X | https://x.com/marceldempers GitHub | https://github.com/marcel-dempers LinkedIn | https://www.linkedin.com/in/marceldempers Music: Track: Reckoner - lofi hip hop chill beats for study~game~sleep | is licensed under a Creative Commons Attribution licence (https://creativecommons.org/licenses/by/3.0/) Listen: https://soundcloud.com/reckonero/reckoner-lofi-hip-hop-chill-beats-for-studygamesleep Track: souKo - souKo - Parallel | is licensed under a Creative Commons Attribution licence (https://creativecommons.org/licenses/by/3.0/) Listen: https://soundcloud.com/soukomusic/parallel