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.