DEV Community: Christine Kim

The K8 Gateway API 🚀

Christine Kim — Thu, 03 Nov 2022 15:20:26 +0000

If you follow the K8s world, you have probably heard that the Gateway API has been released as beta this past summer!

As a superset of the Ingress API, the Gateway API provides a lot of power to teams, by letting non-admin folks get non-admin tasks completed.

If you wanted to try out the Gateway API, but weren't sure where to start, I created a simple and easy demo that walks through 3 common use cases, and you can see how simple it is!

The steps are outlined on my repo here.

A rough overview is that you will deploy a sample application httpbin, and create a Gateway with the Istio Gateway Controller.
Then you can try out 3 scenarios:

Adding a new route to your HTTPRoute
Traffic shifting between v1 and v2 of your application
Trying a new Gateway! (this one is my personal fave)

Try it out, and leave any questions that you might have here! :)

which gateway?? ⛩

Christine Kim — Thu, 20 Oct 2022 13:52:22 +0000

If you search up the term gateway with kubernetes, it's likely you will see the (new-ish) Gateway API, which was released as beta July 2022. This short article is a run down of what the "gateway" is in kubernetes land!

Naming is hard. And throw in jargon on top of it in an ever changing ecosystem makes it even tougher.

The concept of a gateway is to allow for traffic from outside your cluster to hit your services.

A 'gateway' that people refer to is the Ingress Gateways. For example, Istio has a Gateway resource (aka a "gateway"). This Gateway resource configures a Gateway Deployment (also called a "gateway" as well). Usually, you will have decipher which gateway is being referenced in. So that's already 2 mentions of the gateway in jargon form.

Next up, we have the new Gateway API. This is a standardized API designed to be the superset of the Ingress API. It has been created out of inspiration from Istio's Gateway and other gateway
The Gateway API's resources is comprised of "GatewayClass", "Gateway" (referred to as 'gateway'), and routes, such as "HTTPRoute", "TLSRoute", etc.

That's a wrap on different gateways you might face in the k8's land!

what north-south-east-west traffic means 🧭

Christine Kim — Mon, 21 Mar 2022 13:35:18 +0000

Continuing with my short intro articles of microservice-related concepts, the next question I wanted to tackle is traffic. All these articles are short, so hopefully you can read through something quick while getting a cup of coffee.

I'm sure you've heard of north south, or east west traffic. This article hopefully will explain this in terms of microservices, and the lingo that goes along side these terms.

North-South

When you have a kubernetes cluster with your services running, how does the outside end-user actually come into contact with your service? Or maybe it's something that trying to access a microservice in your cluster. This is what's considered to be north traffic - i.e an outside request coming to your cluster. To handle this incoming traffic, you can set up a load balancer. A kubernetes load balancers (LB) gives a single external IP address that will forward all your incoming traffic to your service.
South traffic is for when you have requests leaving your cluster (maybe you are returning a response, or you need to call an external API). While there is an ingress resource type provided by the Kubernetes API, there is no egress resource type :( . This is where something like Istio's Egress Resource comes in handy.

East-West

East-West traffic is considered to be your services communication with each other. Generally speaking, this is traffic within a data centre ("server to server traffic"), and the definition translated to reflect traffic within one's cluster. This is more straightforward than North-West.

Hope this quick read taught you something! Have a great day 🌟
twitter: @christineskim_

what do you wish you knew about kubernetes? 🤔 some getting started resources

Christine Kim — Sun, 20 Feb 2022 03:15:11 +0000

Learning tech is constant and a skill. If you have any q at all, let's see if we can get some a's!

I recall when I was trying to learn kubernetes, it took a few tries to grasp concepts. For any newbies interested in trying out kubernetes, need an explanation, or want a good metaphor, leave a comment below! I (or anyone!) can try to explain it :)
Personally for me, being a developer first, learning k8 was great with examples and being hands on. Here are some resources if you are interested in getting started:

Kubernetes in 100s by Fireship.io: a digestable/quick intro to k8s
Kubernetes docs are well written, and you can't go wrong with them
Learn kubernetes the hard way is a tutorial that you can run through. It's well written and descriptive.
minikube is a tool for creating local k8 clusters. It's a great intro to actually trying out kubectl

this was everyone once upon a time I promise

twitter: @christineskim_

A quick n' gentle intro into Service Meshes 🕸

Christine Kim — Fri, 14 Jan 2022 16:06:39 +0000

I recently started at Google as a DPE (developer programs engineer). Part of my job is to keep tabs on what happens in the open source world.
I have been looking around the CNCF landscape recently, and after attending some virtual talks at the end of last year, I wanted to dedicate time to have a better understanding of the world of OSS (open source software).

This article is just a soft intro in service meshes. With security being such a hot topic last year, I believe that service meshes will be highlighted (it already is!) into being leveraged as a security tool.

So, what is a service mesh?
I think an important question to ask first is why did the need of service mesh ever happen?
Well, with the rise of microservices, all of the service-to-service communication needed to be monitored. Developers found that communication logic needed to be included in within their pods. That's more overhead for developers - they primarily want to focus on the business logic of their apps.

Enter the service mesh. To put it simply, a service mesh is a way to connect, manage, and monitor your services as they communicate with each other. This decouples the tools of communication from your apps (low coupling high cohesion mentality), and pushes this logic to the infrastructure layer.

So how does it work??
Each service that you have is configured to route traffic to a local proxy (installed as a sidecar). A proxy is a 'sidecar' that sits next to your business application container. It exposes primitives that manage communication logic (retry, encryption info, routing rules, etc).
So to recap what we know so far, each service for your app has a proxy that sits right next to it. All these proxies together form the 'mesh' - hence the service mesh!

This is a high level description of service meshes, please let me know if you have any questions!! I plan to do a deeper dive in the components of the service mesh soon😎 Stay tuned!
twitter: @christineskim_
Some useful reads
Istio - About
The Istio Architecture diagram is a great infographic for how it looks.

Digital certificates and what they do

Christine Kim — Mon, 12 Jul 2021 13:35:22 +0000

Digital certificates are a key component in the TLS handshake. We often hear digital 'certs', but what do they actually represent?
Digital certificates (also called public key certificate) is a way to prove the ownership of a public key. The contents are (but are not limited to):

Info about the key (what type of key it is)
Who the owner of the key
The owner's public key
The digital signature of a third party entity that verifies that whoever holds the certificate is who they say they are (this is called the issuer). This is (supposedly) unique, un-fakeable hash.
Who the issuer is
The expiry date of the certificate

Okay cool, so we have someone who approves the certificate.... how do we know they are a valid entity?! We do the same thing again - another third party signs on the issuer's certificate, till we get to the root certificate authority. Ok.... so who approves them? Well those certificates are self signed, and are stored on your laptop by the manufacturer.

Here is a helpful diagram to show how this waterfall of approvals happens (this is called the 'chain of trust'):

In the next article, I'll go through more TLS components, and break them down like this.

What's the difference between TLS 1.2 vs 1.3???

Christine Kim — Tue, 22 Jun 2021 17:39:02 +0000

Most people don't think twice of when they connect to a website. The split second it takes for a (new) website to load, an awesome protocol occurs behind the scene - to make sure that the website that you are requesting to view is who they say they are.
TLS stands for Transport Layer Security, and in my personal opinion, is under appreciated, especially for how widely used it is.
The goal of TLS is to have you (client) and the server, agree to using the same key to encrypt and decrypt any messages sent between you two. This is known as a symmetric key.
How do you agree to the same key? If either the client or the server sends they key over, then anyone eavesdropping can just steal the key and use it. To get the same key to both parties, asymmetrical encryption is used.

In TLS 1.2, the client proposes key exchange algorithms and a symmetric key encryption algorithms, and the server sends back which one it prefers to use. This agreement doesn't exist in TLS 1.3, by assuming that the key exchange is going to be in a certain key exchange method, and therefore doesn't have to go through that round trip. Furthermore, TLS 1.3 depreciated insecure features, such as SHA-1, DES, MD5, AES-CBC (and some more). Another cool thing about TLS 1.3 is that it mandates perfect forward secrecy - meaning that there's an assurance that a session's key will not be compromised even if the secrets used in the session key exchange are compromised.

I'm going to make a future post going into the details of the actual exchange of keys and the math behind it. Stay tuned!

What's the diff? Snowpack vs Webpack

Christine Kim — Mon, 14 Jun 2021 14:06:39 +0000

Recently, I tried out a new project with Snowpack. I have always used Webpack in my projects, but it seemed like a good opportunity to try something new out. This post is a short read on Webpack and Snowpack, and a little talk about my experience with it.

First off, what is Webpack?
On its website, it is a module bundler. When web apps started getting much larger, Webpacks became the answer to the size of these dependencies and overall project size. Webpack goes through the packages you have in your project, and creates a dependency graph that contains modules that your web app needs to function. Pretty much, it's tasked with taking your JS files, imported NPM modules, images, CSS, other assets, and throw it into a build file that the browser can run. Every time you make a change, your files have to be re-bundled, making it quite tedious.

Then what's snowpack?
Snowpack, is much newer, coming on to the scene in 2019. It a front-end build tool for JS, and was created to be an alternative to webpack. Snowpack is able to be light weight by taking advantage of JavaScript's native module system, to only do the bare minimum. It uses ES modules to run within the browser, and only use modules when it's needed. There is also an ability to imports modules from CDN servers. If you don't need have a large request waterfall, and want to gave as little tooling as possible, then you would benefit to using Snowpack.

The project I wanted to make was a React app, and deploy it through GitHub pages. The setup was quite simple, and I found that the documentation on the Snowpack page to be really thorough. However, reading more up on it, I heard it wasn't recommended to use with a no configuration tool like create-react-app, because I needed to figure plugins and configure some of my settings to get it to work. (I made a template here if you want to avoid the pain that I went through setting up and making your Snowpack React app work with gh-pages). But wither than that, I found it was much quicker and help speed up my workflow for my small project.

Overall, I would recommend trying out Snowpack, since it's pretty easy to figure out how to get up off the ground with. Leave a comment if I missed anything on comparing the two, and what preference you have if any!

How to redirect your hosted GitHub page to a custom domain

Christine Kim — Sat, 05 Jun 2021 02:52:00 +0000

If you have your own domain, and a Github account, you could take advantage of redirecting hosted pages to your own domain.

This article is assuming that you already deployed your GitHub page at yourUsername.github.io

For example, I have a website www.example.com through Google Domains. Below is a screen shot of my custom domain.

To point your GitHub page to your website, first add to your DNS records the url, CNAME record, and the IP addresses. CNAME means that it's a Custom Domain.

www , CNAME, and 'yourGitHubUsername'.github.io .

Next, add GitHub's IP addresses under the DNS - with an A record. The A indicates that it's an 'Alias'.
As of June 2021, the IPs are

185.199.108.153
185.199.109.153
185.199.110.153
185.199.111.153

@ , A , and the above IP addresses.
You can double check here.

Lastly, under the Settings tab on your GitHub repo for your site, go to the Pages section.
In the custom domain field, put your custom domain (www.example.com).
It might take a little time for it to load
Congrats, you are now pointing your page to your custom domain!

You can also host pages.
By deploying through Github pages, that are not username.github.io. If you deploy using gh pages, you can add themto your DNS configuration.

For example, if I had www.mywebsite.com, and deployed a page www.mywebsite.com/books
add into your DNS configuration
books , CNAME, and 'yourGitHubUsername'.github.io .

Javascript's import vs require?

Christine Kim — Fri, 28 May 2021 14:55:31 +0000

I was recently creating a script that requested data from a 3rd party API, and I was running this script within the server of a Sapper project. In order to correctly get this data, I went through promise chaining, and I had to use an '.mjs' extension on my script.

Since Node v12, ES modules has been enabled by default. Hence my use of '.mjs' to run my file including a node module.
Another way to resolve this issue is to use import with Node.js, you have to edit the package.json to 'type':'module'. However, using this caused my Sapper server to crash since it wasn't supported, as the rollup file outputs the format to commonjs Explained in (this GitHub issue).

Commonjs uses require and module.exports, while ES6 uses import and export. Import and Export are used to refer to an ES module, and can't be used with other file types.

Reading a little more up on it, here are some differences I found

import will be run in the beginning of the file, always, whereas require can be called anytime and anywhere
import gets sorted to the top of the file
import can be used to selectively load parts you need, and can save memory
import can be asynchronous, which apparently perform better, and require is synchronous

Are there any others that I missed?
tl;dr: ES6 -> import, export default, export vs commonjs -> require, module.exports, export.foo

Using Notion's new beta API

Christine Kim — Wed, 26 May 2021 14:50:11 +0000

Recently, Notion released a beta public API. This is amazing news, as an avid user of Notion, I am excited to find ways to integrate my Notion workplace more seamlessly across tools. The documentation for the API is found here.

This post is just an intro into hitting the API using Postman - instead of using the SDK- just in case if I choose to write an integration in another language.

Setting up the workplace is comprehensive.

Have a personal workspace
Go to the Notion integration page. This should already be linked up with your account. Name your project, copy and paste your token somewhere safe!
Make a page. Share a workspace with your integration, by clicking Share. Your integration you made should be listed.

Now here is a breakdown of the URLs, because I was slightly confused on how to get the ID of certain blocks.

First off, a POST request through Postman.
This is pretty straight forward. First, you need the ID of the database.

Say your workspace has this link (you can get this link by clicking Share, and clicking Copy link in the bottom right of the popup.

The link for this table page is for example is https://www.notion.so/904748e3b5214b28a5e6f74f32048e1f?v=4a8....
I changed the IDs of my pages, so clicking this link will result in a 404.

We want the 904748e3b5214b28a5e6f74f32048e1f part of the url. So copy your database ID down.

I created a page in this page, which contains a table already in my workspace.

With the database ID copied down, I go into Postman and fill a POST request.
In the url field, paste in https://api.notion.com/v1/pages

Remember the secret token we got earlier? Under the Authorization tab, select the TYPE as 'Bearer Token', and paste that token in the text field.

Then in the Body tab, we are going to fill in the data to write an entry into the table.

Make sure to change your database_id with your respective ID (mine was 9047e... ).

Now click Send. If everything was filled out correctly, you should get a JSON response with the id, and the properties of the page!
Congrats, you made your first POST request in Postman with Notion's beta API!