Kubernetes – The Players

TL;DR: Kubernetes has different object types which work together to run the application:

• Pods – atomic unit of scheduling
• Service – stable networking and load balancing
• Replica set – scale pods and maintain desired state (similar to replication controllers, but we’re being told to move away from those)
• Deployments – replication using replica sets, plus rolling updates and rollbacks

Kubernetes – Architecture

In the previous post, we saw what a container was and why they were useful. That’s great, if you have a really small application with not much traffic, and one container serves your needs. In practice, you’d need several containers running instances of your application, and some sort of manager to direct traffic and manage them all for you. As a developer, you don’t care anymore about the low level detail of which server your app is running on, you just care that it is up and running and can serve traffic. Kubernetes is a container orchestration tool which handles the management of all your containers for you. It works on a declarative model, whereby you tell it what you want the world to look like and it will do the work behind the scenes to make that happen. Think wedding planner.

Containers – a history lesson

Something I’ve been looking into recently is containers and Kubernetes. It’s all the rage right now, and very quickly being adopted by several companies. As always, to test and solidify my own understanding, I’m writing up what I’m learning – hence this next series of blog posts! To understand why containers are useful, we first need to know what problem they solve, and that requires a little history lesson.

JDBC, C3P0 and connection pooling

This week we hit a strange issue at work which required us to understand some of the interactions between MySQL, JDBC (the API for a Java application to connect to a database) and C3P0 (a common connection pooling library). This sort of thing is something I’ve never really looked into, so I thought it was prime time to do a bit of background reading (and writing!). Below I’ve summarised my understanding of how connection pooling works for applications in general.

Networking – Security

SSL (now called TLS)

At the end of the last post, we were at the stage where a client and server could communicate via TCP once they had performed the necessary handshake. The problem with this is that anyone can eavesdrop on this connection, and intercept the messages being sent across. That may be absolutely fine in some cases, but where the data is more sensitive we probably want some additional confidence not only that we are actually communicating with our intended recipient, but that only that recipient will be able to understand our messages.

This is where TLS (Transport Layer Security) comes in. (Aside: TLS Used to be called SSL (Secure Sockets Layer)). This involves yet another handshake (you’ve got to be really good friends before you get to hear each other’s secrets!), which is done in the following way:

1. The client sends the server an initial “hello” message, which tells the server which encoding it can handle
2. The server responds with its own “hello” message, which contains a few different bits of information for the client:
   • Which encodings it would like to use (CipherSuite)
   • A session ID – This can be used in future by the client to restart the session, so that the handshake doesn’t need to be repeated
   • A server certificate
   • Public key of the public/private pair (for encoding/decoding)
   • The signature of the server, so the client knows they’re talking to the right one
3. The client verifies the server certificate
4. Diffie-Hellman key exchange (more on this later)
5. The client (optionally) sends a client certificate
6. The server verifies that certificate
7. The client sends a FINISHED message. This is the first message that is encrypted using the shared key.
8. The server sends a FINISHED message. Once both the server and client have decrypted each others FINISHED messages, we know they can understand each other
9. Finally, messages can be exchanged securely! Yay!

Diffie-Hellman Key Exchange

This is a method where two (or more) individuals can collaboratively create a shared secret despite sharing information in the public sphere. It’s actually pretty smart, here’s how it works:
Suppose Harry and Ron are trying to communicate securely. They both come up with a public key which they share, e.g. . Next, they each come up with their own secret integer , and send to the other. So
Harry: secret integer 3, send to Ron
Ron: secret integer 4, send to Harry

Harry and Ron then take the number they were sent (), and use that number with their secret integer () to calculate , i.e.
Harry: receives 1 from Ron, calculates
Ron: receives 3 from Harry, calculates

This result is the same! And always will be – i.e. this is their shared secret. Now they can use this to encrypt/decrypt messages to and from one another using it.

Let’s look at what would happen if Draco tried to intercept the messages:
He would know the public key – , and the result of the first calculation, but neither of the secret integers. Therefore, to get to the result of 1 like the other two, he’d have to look at the numbers sent (3 and 1) and try and work out at least one of the secret integers, to then use it in step 2:

Since we’re using small numbers in this example, finding and is a fairly simple task, but in practice with much larger primes this becomes a much more significant ask, even for the most powerful computers. He’s much better off trying Fred and George’s Extendable Ears for eavesdropping…

Networking – The Lower Layers of the OSI Model

There’s a lot of things that I’ve still got no idea about in this vast technical world – and one of those things is how things work under the hood. When faced with the question “What actually happens when you type www.google.com in your browser?” I found myself staring blank faced at the person who posed the question, which prompted a conversation about networking and how data gets transmitted from one place to another. I’ve attempted to summarise some of the concepts discussed in that conversation in this post.

I Am Not A Feature Machine

It’s easy to have a bias of thinking that you and the company you work for have different interests, and there is a trade off between being selfish or doing what the company wants. With this mindset, self improvement feels like something that shouldn’t be done on the company’s dime, or should at least be regulated, so that the employee and the employer can both strike a compromise where both interests are met to some degree. In other words, you think of your role at work to be that of a “Feature Machine”.

How to Beat Blue Monday – Apply The Toyota/Improvement Kata!

The title of this blog sounds more like a self help blog than a technical one! However, I actually find it really interesting to see how models and processes we apply at work can help in many different walks of life. The Toyota Kata is one such concept which actually makes a lot of sense to apply to various different situations.

For those who have not heard of the Toyota Kata, it is a pattern for continuous improvement. It works by allowing yourself to focus on an immediate goal to make incremental steps towards a larger objective.

Continuous Deployment – A Whole New World

At my previous company, I’d experienced release cycles of 1 to 3 months, and release day was usually pretty stressful, especially when a big change was going in! We had various branching strategies to make sure only the code we expected to be released would go in. (Whilst in theory it should be fairly simple because no new code should be committed after taking the release cut, in practice, there was always last minute changes going in and I remember keeping these branches up to date, or merging code between master and the release branch sometimes turned into an absolute nightmare.)

Immutability

It’s been a while since I’ve written a post on here – and a lot has happened in that time! I’ve started working at another company – a much smaller place with a greater focus on technology and culture, and I’m loving it so far! I’ve learnt a huge deal even in the short time (one month) that I’ve been there, and had many interesting conversations with people.

I do need to start writing again, as I’m worried the huge amount of stuff I’ve learnt will very rapidly fall out of my head, so here’s the first post of a series of random musings based on interesting conversations I’m having or facts I’m picking up along the way. This one’s on a conversation I had this week about immutability.