This is especially relevant if you’re not actively job hunting and suddenly receive an interview invitation, leaving you with limited time to prepare but a strong desire to maximize your chances of success.

Disclaimer: The tips described in this post may be more useful for senior engineers with hands-on experience and engineering intuition.

HR Interview

The internet is full of articles listing all possible HR interview questions. I recommend spending a bit of time on them just to understand what to expect and not be surprised.

However, in my humble opinion, there are two main points to focus on during HR interview preparation.

First, you need a short story that tells your experience briefly. Avoid listing every bullet point from your CV. Instead, focus on highlighting your key achievements. Also, your story must be aligned with the position you are applying to. Yes, you might need to adjust your story for different jobs at different companies.

Second, it’s important to have a clear motivation. Why do you want to change your job, and why this company/role? What kind of job are you looking for?

System Design

If you have some experience doing System Design interviews or have never done it, start by learning the Delivery framework. Understand each section.

Watch at least one video on how it’s done. The more, the better. These videos from Hello Interview channel are really good, though.

If you are applying to a FAANG company, you may search for leaked system design questions from that company and spend some time preparing for them. But there is no guarantee that you will get the same topic, thus I would not recommend spending all your time here.

If you can, do a mock interview. Ask a friend or find someone to practice with. If you can’t, then try to walk through alone, but talk through everything out loud.

During the interview, treat the interviewer as a colleague, ask questions, ensure you understand the problem, and that you have not missed any important requirements before building the design of the system.

Don’t rush.

Live coding

This part is really tricky. If the company tends to use LeetCode-style interviews, there is no shortcut here. You need to solve hundreds of them to really feel confident. You may need to refresh your memory on algorithms you feel less confident about (for example, I always forget about corner cases for binary search).

Again, if it’s a big / well-known company, you can try to search for leaked coding interview questions.

Behavioral interview

S.T.A.R (situation task action result) & C.A.R.L (context action result learning)

There are dozens of questions you could be asked in behavioral interviews. And you’re expected to structure your answers using the STAR framework. This means you need to tell a story by defining a context, your actions, and results. You could go and just prepare a STAR format answer to all such questions, but it will take a lot of time, and it’s suboptimal. This, combined with the fact that the same stories can be used for different questions, makes the situation easier for you. You can prepare 7–10 stories that will cover most of the questions. During preparation, you can write them as text, but don’t read them during the interview. It tends to sound unnatural.

When telling your story using the STAR method, make sure your final sentence clearly highlights a positive outcome. Adjust your tone to emphasize this closing part so it stands out.

The STAR framework is a standard. But also check CARL in some questions, it would be good to tell what you have learned from that story.

Here are some materials that helped me to prepare for a behavioral interview:

• Hello Interview - Behavioral Interview Discussion with Ex-Meta Hiring Committee Member- must watch Behavioral interview, although I would recommend watching it even before the HR interview, because it gives a bunch of helpful tips about self-presentation
• https://thebehavioral.substack.com/ - Strategies, tips, and resources to prepare for your next behavioral interview from a FAANG+ insider.

Project Walkthrough

Some companies have such an interview stage. It’s quite unpopular but still exists. You’re asked to present a project or problem you worked on. You explain the context, problem, solution, results, and your role in this story. It’s like showing the result of your work to colleagues from different departments/teams.

This stage is very open-ended. You are not given specific instructions, and there is not much information on the internet with recommendations on how to prepare and conduct such interviews. When I found out I would have this interview, I was initially shocked and unsure how to prepare, as I didn’t know what to expect. It wasn’t until I realized that in reality, it’s you, the interviewee, who rules this interview. You choose the project, decide what to include and omit, control the level of detail, and you are coming up with the story you know, with all the answers for all possible questions, because it’s your story.

So, make the most of this stage. Prepare your story, make a few slides / notes / architecture sketches.

Don’t dig into details too much. Leave a space for the questions.

And even if there is no dedicated interview, you may be asked to tell in detail about a certain problem/project you were working on. So, be prepared. Have your story!

Final thoughts

When answering open-ended questions, aim to tell stories where the scale of the problem matches the level of the role you’re applying for. For example, if you are asked, “Tell me about a challenging/interesting problem/task you were working on recently.” Optimizing an SQL query by adding an index may be fine for junior roles, but it won’t carry enough weight for senior positions. Interviewers would expect to hear something bigger, challenging, higher stakes, and often involving cross-team collaboration, such as migrating a large system to Kubernetes.

Question back. You should ask questions to learn more about the company, their culture, the hiring manager’s management style, and what they like or dislike about their work. Prepare a list of questions before the interview.

Start preparing in advance. Even if you’re not planning to change jobs anytime soon, you can begin investing in your future by:

• solving one LeetCode problem a day
• keeping track of tasks/projects you’ve completed, along with your achievements (many companies require this anyway for performance reviews) – this would be a foundation for your stories in behavioral and project walkthrough interviews.
• keeping your CV and LinkedIn up to date.

Recently, I’ve deployed microbin, minimalistic opensource “pastebin”-like service, into my homelab to share temporal files/text between devices. It works quite well.

A few days ago, I started wondering: could I upload files or paste text into Microbin directly from the iOS Share menu?

The short answer is yes. It could be done using iOS’s builtin “Shortcuts”.

Use cases

I have two general cases of using microbin from my corporate iPhone to my personal devices:

1. Share some text / link
2. Share file(s)

For simplicity, I decided to create dedicated shortcuts for each use case.

Paste text into microbin

1. Open Shortcuts app and create new empty shortcut, rename it into “Paste into microbin”.

2. Add Share action, click at Input and select Shortcut Input. New Receive action will pop up.

3. Click at Nowhere in Receive … from action, enable Show in Share Sheet toggle and disable Show in Search, click ✅ at the top right.

4. Next to the if there’s no input, click Continue and select Ask For and Text

5. Delete Share action, we don’t need it anymore.

6. Add Get contents of URL action.

7. Put your microbin url into URL field. For example https://pub.microbin.eu/upload

8. Expand action configuration by clicking ▶︎ button, then:

   • Set Method as POST
   • Add Content-Type header with value multipart/form-data
   • Select Form as Request Body type
   • Add content field as File type (important!) and select Shortcut Input as value.

9. That’s all. Test it by clicking ▶︎ Play button in the bottom menu. If you did everything correctly you’ll see preview with the link.

Upload files into microbin

A shortcut for file upload is configured in very similar way. I won’t describe it in detail but mention only notable changes:

• Duplicate the Paste into Microbin shortcut to not start from scratch.
• In Receive action, select Files type and allow multiple files
• Add Repeat with each item action loop to iterate over Selected input
• In Get Contents of URL action everything stays the same, except content field - it gets renamed into file

Preview

Summary

If you did everything from above and it did not work, or you don’t want to bother with configuring it at all. You can import my shortcuts in your device and override microbin url:

• 📋 Paste Into Microbin

• 📤 Upload Files to Microbin

One of the core challenges is delivering content quickly to the end user. This is where a CDN comes into play.

A CDN stands for Content Delivery Network. Let’s break it down.

(Note: Modern CDN providers often bundle additional services such as WAF, DDoS protection, and bot management. Here, we focus on the static content delivery.)

Content

Content refers to any asset that needs to be loaded on the user’s device: images, audio/video files, JavaScript, CSS, and more.

Delivery

Delivery means that this content is not only available but also delivered efficiently and quickly.

Network

A CDN is a network of distributed nodes that cache content. Instead of fetching files directly from the origin server, users receive them from the nearest node, minimizing latency.

How Applications Work Without a CDN

Consider an online marketplace for digital assets, such as a photo stock or NFT platform. The application stores thousands of images on a central server. Whenever users open the app, those images must load quickly. If the application server is hosted in Paris, users in Paris will experience minimal ping. However:

• Users in Spain may see about 2× ping time.
• Users in the USA may see 6× ping time.
• Users in Australia may see 12× ping time.

These numbers only reflect simple ICMP ping times. Actual file delivery involves additional overhead such as TCP connections and TLS handshakes, which increase delays even further.

How a CDN Solves This Problem

With a CDN, each user connects to the nearest edge node instead of the origin server. This is typically achieved via GeoDNS. Importantly, only the CDN knows the actual address of the origin server, which also improves security by reducing exposure to direct DDoS attacks.

CDN providers usually operate edge nodes in major world cities. When a request is made:

1. If the requested file is already cached on the edge node (cache hit), it is delivered instantly.

2. If not (cache miss), the edge node requests it from the CDN shield.

   • If the shield has the file cached, it is returned to the edge and then served to the user.

   • If not, the shield fetches it from the origin server, caching it along the way.

For popular websites, the cache hit rate approaches but rarely reaches 100% due to purges, new files, or new users.

The shield node plays a critical role. Without it, each cache miss from any edge node would hit the origin server directly, increasing load. Many providers offer shields as an optional feature, and enabling them can significantly reduce origin stress.

Measuring CDN Effectiveness

Beyond cache hits and misses, performance can be measured with concrete indicators:

• Time to First Byte (TTFB): How long it takes for the first data to arrive after a request. CDNs usually reduce TTFB by terminating connections closer to the user.

• Latency reduction: The difference in round-trip time between delivery from the origin versus delivery from an edge node.

• Cache hit ratio: The percentage of requests served directly from edge caches.

These KPIs provide a real, measurable view of CDN efficiency rather than theoretical assumptions.

Which CDN is Best?

The closer the edge node is to the end user, the faster the content loads. The key questions are: Where are the users located? Which CDN providers have the best edge coverage for those locations?

But don’t rely on maps alone. Measure real performance with Real User Monitoring (RUM) using metrics like TTFB and Core Web Vitals. There are plenty of ready-made tools available. If you’re interested in building your own RUM system, leave a comment or reaction – I can cover that in a follow-up post.

This workaround never felt right. As an engineer, I wanted a solution that reflected the actual lifecycle of an application rather than its worst moment.

I opened an issue in the Kubernetes repository describing the problem and proposing an approach to adjust pod resources dynamically without restarts. The issue received little discussion but quietly accumulated interest over time (13 👍 emoji reaction). Every few months, an automation bot attempted to mark it as stale, and every time, I removed the label. This went on for nearly six years…

Until the release of Kubernetes 1.35 where In-Place Pod Resize feature was marked as stable.

What In-Place Pod Resize Brings

In-Place Pod Resize allows Kubernetes to update CPU and memory requests and limits without restarting pods, whenever it is safe to do so. This significantly reduces unnecessary restarts caused by resource changes, leading to fewer disruptions and more reliable workloads.

For applications whose resource needs evolve over time, especially after startup, this feature provides a long-missing building block.

Impact on VerticalPodAutoscaler

The new resizePolicy field is configured at the pod spec level. While it is technically possible to change pod resources manually, doing so does not scale. In practice, this feature should be driven by a workload controller.

At the moment, the only controller that supports in-place pod resize is the Vertical Pod Autoscaler (VPA).

There are two enhancement proposals enable this behavior:

• AEP-4016: Support for in place updates in VPA which introduces InPlaceOrRecreate update mode

• AEP-7862: CPU Startup Boost which is about temporarily boosting pod by giving more cpu during pod startup. This is conceptually similar to the approach proposed in my original issue.

Here is an example of Deployment and VPA using both AEP features:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example
spec:
  replicas: 1
  selector:
    matchLabels:
      app: example
  template:
    metadata:
      labels:
        app: example
    spec:
      containers:
        - name: app
          image: my-heavy-java-app:stable
          ports:
            - containerPort: 80
          resources:
            requests:
              cpu: 1000m
              memory: 1024Mi
            limits:
              cpu: 2000m
              memory: 2048Mi

---

apiVersion: "autoscaling.k8s.io/v1"
kind: VerticalPodAutoscaler
metadata:
  name: example-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: example
  updatePolicy:
    updateMode: "InPlaceOrRecreate"
  resourcePolicy:
    containerPolicies:
      - containerName: "app"
        minAllowed:
          cpu: "250m"
          memory: "512Mi"
        maxAllowed:
          cpu: "3000m"
          memory: "8192Mi"
        # The CPU boosted resources can go beyond maxAllowed.
        startupBoost:
          cpu:
            type: "Factor"
            quantity: "2"

With such configuration pod will have doubled cpu requests and limits during startup. During the boost period no resizing will happen.

Once the pod reaches the Ready state, the VPA controller scales CPU down to the currently recommended value.

After that, VPA continues operating normally, with the key difference that resource updates are applied in place whenever possible.

Limitations

Does this feature fully solve the problem described above? Only partially.

First, most application runtimes still impose fundamental constraints. Java and Python runtimes do not currently support resizing memory limits without a restart. This limitation exists outside of Kubernetes itself and is tracked in the OpenJDK project via an open ticket.

Second, Kubernetes does not yet support decreasing memory limits, even with in-place Pod Resize enabled. This is a known limitation documented in the enhancement proposal for memory limit decreases.

As a result, while in-place Pod Resize effectively addresses CPU-related startup spikes, memory resizing remains an open problem.

Final thoughts

In place Pod Resize gives a foundation for cool new features like StartupBoost and makes use of VPA more reliable. While important gaps remain, such as memory decrease support and scheduling race condition, this change represents a meaningful step forward.

For workloads with distinct startup and steady-state phases, Kubernetes is finally beginning to model reality more closely.

Why?

First of all, why should you contribute to open source?

Giving back

Everyone, from freelance engineers to Big Tech companies and even governments, uses Open Source Software (OSS). Some use it less, others more, but almost everyone depends on it in one way or another. Most of us are consumers of open source.

Contributing to OSS means giving something back. This is especially important given the many cases of projects (e.g nginx-ingress, external-secrets) being deprecated due to maintainer burnout, lack of community support, or overwhelming workloads.

It is true that some OSS projects are backed by large companies and maintained by engineers who are paid to work on them. However, the half of open source projects are still maintained by individuals in their spare time for free (source).

In this sense, contributing to OSS can be seen as a form of digital volunteering. Some companies (Criteo, Futurice) even offer paid volunteer time (VPTO) specifically for open-source contributions.

Learning

Another strong reason to contribute to open source is personal growth.

Every contribution becomes a learning opportunity because it places you inside a real, production-grade codebase rather than a controlled tutorial environment. You learn how projects are structured, how architectural decisions are made, how backward compatibility is maintained, and how trade-offs are handled in practice. Often this means working with unfamiliar tools, languages, or ecosystems, which naturally expands your technical range.

At the same time, open source strongly develops communication and collaboration skills. Issues and pull requests force you to articulate problems clearly, propose solutions in a way others can evaluate, and explain why a particular approach makes sense. Feedback from maintainers and contributors exposes you to different perspectives and constraints, requiring you to adapt, clarify, and sometimes rethink your ideas.

Because most collaboration happens asynchronously and in writing, you also improve your ability to communicate precisely and concisely. Over time, this structured, public collaboration sharpens how you discuss technical topics, handle reviews, and work effectively with distributed teams. These are the same skills required in modern engineering organizations, making open source a highly practical training ground.

Networking and professional reputation

Open source contribution naturally leads to networking, even if you are not actively trying to “network.” By participating in issues, code reviews, and pull requests, you start interacting with maintainers and contributors from different companies, countries, and levels of seniority. Over time, these repeated interactions build familiarity and trust. People begin to recognize your name, your areas of expertise, and the quality of your work.

Regular contributions can turn these lightweight interactions into professional relationships. Maintainers may invite you to collaborate more closely, grant you additional responsibilities, or even recommend you for roles on their teams. In many cases, job opportunities arise not from formal applications, but from someone already knowing how you work.

Another important, and often underestimated, benefit of open source contribution is visibility. Most professional work is hidden behind NDAs and internal repositories, making it difficult to demonstrate your real impact. Open source work, on the other hand, is public by default. Your commits, pull requests, discussions, and design decisions are all visible and attributable to you.

This public track record allows you to clearly show not only what you built or improved, but also how you collaborate, communicate, and respond to feedback. For recruiters and hiring managers, this is far more convincing than a list of skills on a résumé. In practice, open source contributions often function as a living portfolio and a long-term investment in your professional reputation.

How?

Now that you understand why contributing matters, let’s look at how to get started.

The Natural way

You might think that contributing to open source requires skills you do not have, a brilliant idea for a new library, or deep expertise in a specific domain. These beliefs often make OSS contribution feel unreachable.

That is not the case.

You do not need a revolutionary idea or special credentials. If you are an engineer who already writes code, you are capable of contributing.

Here is a simple approach: the next time you are solving a problem using an open source tool and notice that it does not work as expected (a bug) or lacks a feature you need, do not immediately abandon the tool. Use your skills, and an LLM if needed, to investigate and try to fix the issue.

If you succeed, open a pull request to the upstream repository. If you do not, create an issue and share your findings. That is still a contribution, and you will have learned something in the process.

Good first issue

If everything you use works perfectly and you do not notice any gaps, you can take a more deliberate approach.

Make a list of projects you like, use, or want to learn more about. Browse their open issues and look for ones labeled “good first issue” or similar. Pick something that matches your current skill level and try to tackle it.

If your list is short or you cannot find suitable issues, there are also curated lists of projects actively looking for contributors.

• https://goodfirstissue.dev/
• https://forgoodfirstissue.github.com/
• https://goodfirstissues.com/

Summary

Open source is great, but keeping it that way requires people to contribute. It is not hard or unreachable. Anyone can do it, and the community needs more people like you. Start small, pick a project you love, and take your first step

The problem

As engineer who works with kubernetes everyday I use kubectl a lot. Actually, more than 50% of my terminal history commands are related to kubernetes. Here is a top 10 commands:

1	2079  46.7611%    kubectl
2	425   9.55915%    git
3	324   7.28745%    helm
4	156   3.50877%    cd
5	146   3.28385%    ssh
6	130   2.92398%    kctx
7	114   2.5641%     kns
8	80    1.79937%    gcloud-auth
9	78    1.75439%    curl
10	66    1.48448%    docker
...

Run this command if you are curious what about yours the most popular commands in terminal history.

I use kubectl to check status of the pods, delete orphaned resources, trigger sync on ExternalSecrets and much more. When I realized half my terminal history was just kubectl commands, I thought — there must be a better way to find things in Kubernetes without chaining pipes with grep / awk / xargs. And I imagined how nice it would be to have a UNIX find-like tool — something that lets you search for exactly what you need in the cluster and then perform actions directly on the matching resources. I searched for a krew plugin like this but there was not any. For that reason, I decided to develop one!

Development

I used sample-cli-plugin as a starting point. Its clean repository structure and straightforward design make it a great reference for working with the Kubernetes API. Additionally, it allows easy reuse of the extensive Kubernetes client libraries.

Almost everything in the Kubernetes ecosystem is written in Go, and this plugin is no exception — which is great, as it allows building binaries for a wide range of CPU architectures and operating systems.

Features overview

Filters

Find by resource name using regex

kubectl fd pods -r dev

Find pods with restarted containers

kubectl fd pods --restarted

Find pods with image matching regex

kubectl fd pods --image bitnami

Find pods by status

kubectl fd pods --status Pending

Find pods running on nodes matching regex

kubectl fd pods --node '*spot'

Find any resource by custom condition

Use jq filter to find any resource by any custom condition. kubectl-find uses gojq implementation of jq.

# find Services with trafficDistribution set to PreferClose
kubectl fd svc -j '.spec.trafficDistribution == "PreferClose"'

# find pods with unset nodeSelector
kubectl fd pods -j '.spec.nodeSelector == null' -A

# find pods with undefined resources
kubectl fd pods -j 'any( .spec.containers[]; .resources == {} )' -A

Actions

By default, fd will print found resources to Stdout. However, there flags that you can provide to perform action on found resources:

• --delete - to delete them
• --patch - to patch with provided JSON
• --exec - to run command on pods

Getting started

Use krew to install the plugin:

krew install fd

What’s next

I’m currently working on adding:

• JSON/YAML output format
• More filters
• Saved queries

If you’re tired of writing long kubectl | grep | xargs chains, give kubectl fd a try — it’s already saved me countless keystrokes.

Check out the repo ⭐ github.com/alikhil/kubectl-find and share your ideas or issues — I’d love to hear how you use it!

And usually, we don’t really have such a luxury as hours of uninterrupted time.

Nevertheless, sometimes we catch the flow of productive and focused work at the end of the workday. Imagine you come up with an elegant solution to a problem you’ve been tackling all day, or maybe even the whole past week. You can’t wait to implement and test your solution. And of course, you are so driven by your idea that you decide to continue working despite your working day being over. “20 minutes more and I will finish it,” you think. Obviously, this is not the case; some edge cases and new issues will inevitably arise. You come to your senses only 2–3 hours later—tired, hungry, demotivated, and still struggling with your problem. You just wasted your evening, with nothing to show for it. Worse, you overworked and didn’t recover that night. Thus, you were already exhausted when you started working.

You can imagine what will follow next. Nothing good, really.

I remember this happening back when I worked at a fast-growing startup, KazanExpress, while living in Innopolis. Our office was buzzing with energy, and the pace was intense—we often pushed ourselves late into the night. One evening, I felt like I had finally cracked a tricky part of our infrastructure. I thought, “Just 20 more minutes and I’ll finish it.” Of course, those 20 minutes stretched into well over three hours. By the time I left the office, I was tired, hungry, and frustrated—without any real progress to show. The next morning, walking back to the office, I realized how drained I already felt before even starting work. That was when it became clear to me: it’s better to stop, write down the next steps, and come back with a fresh head.

Of course, some might argue, “But you are considering only a negative scenario; one could really finish that job in 20 minutes and go home happy…”. Sure, but I think this risk is not worth it. Instead, I would suggest doing another thing.

Rather than trying to complete your task in 20 minutes, take this time to write down your thoughts, and a step-by-step action plan of what you think you need to do to finish your task. Then go home. Rest. A feeling of incompleteness will motivate you to come back and finalize your work the next day. Only you will be full of energy, together with a settled plan. No doubt you’ll accomplish your task before lunch.

Writing down the next steps helps to clear your mind after a workday. You write and forget about your work until the next morning.

As a bonus, there is a chance that new, better ideas will come while you sleep or rest.

I have been using this trick for more than 5 years now, and it helps me to keep my work and life balanced. Here are the two main ideas of it:

• Don’t overwork
• Write down the next steps before finishing your workday

What we have

We have a Kubernetes cluster with several web services deployed for internal use.

What we want to achieve

We want to expose our internal web services to the Internet, but restrict access by requiring authorization. Access should be granted only to users authenticated through our Identity Provider (such as Google, GitHub, Keycloak, etc.).

Assumptions

For simplicity, let’s assume that both ingress-nginx and cert-manager are already deployed in the cluster.

I will use Pocket ID as Identity Provider in this tutorial. Configuration slightly differs for different providers. Check the official documentation for your provider.

For the examples in this guide, I’ll use my alikhil.dev domain:

– pocket-id.k8s.alikhil.dev - will be used for Pocket ID

• k8s.alikhil.dev - will be used for oauth2-proxy. I recommend to have higher domain for oauth2-proxy service for easier cookie setup.

• *.k8s.alikhil.dev - reserved for services deployed for internal usage

Preparation

DNS

I have added two DNS records:

1. A record for k8s.alikhil.dev pointing to ingress-nginx LoadBalancer IP address in the cluster (kubectl get svc -n ingress-nginx | grep LoadBalancer)
2. CNAME record for *.k8s.alikhil.dev pointing to k8s.alikhil.dev

Install Pocket ID

helm repo add anza-labs https://anza-labs.github.io/charts
helm upgrade --install pocket-id anza-labs/pocket-id -f ./values/pocket-id.yaml

persistence:
  data:
    enabled: true

ingress:
  # -- Specifies whether ingress should be enabled.
  enabled: true
  # -- Ingress class name.
  className: "nginx"
  # -- Annotations to add to the ingress.
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    kubernetes.io/ingress.allow-http: "true"
    kubernetes.io/tls-acme: "true"
  # -- Ingress host configuration.
  host: pocket-id.k8s.alikhil.dev
  paths:
    - path: /
      pathType: ImplementationSpecific
  # -- List of TLS configurations for the ingress.
  tls:
   - secretName: pocket-id-tls
     hosts:
       - pocket-id.k8s.alikhil.dev

Configure PocketID

Go to https://pocket-id.k8s.alikhil.dev/signup/setup and set initial configuration for Pocket ID.

Then add your passkey.

Create developers group and add yourself to the list of members.

After that, go to OIDC clients page and create one for oauth2-proxy. Set proper callback url.

Save generated Client ID and Client Secret for later use.

Installing oauth2-proxy

I am using raw k8s secrets in this tutorial, but I highly recommend storing secrets in Vault or similar services and use External Secretes Operator to deliver them to kubernetes.

kubectl create secret generic oauth2-proxy-secrets --from-literal=client-id=$CLIENT_ID --from-literal=client-secret=$CLIENT_SECRET --from-literal=cookie-secret=$(openssl rand -base64 32 | head -c 32 | base64)

helm repo add oauth2-proxy https://oauth2-proxy.github.io/manifests
helm install oauth2-proxy oauth2-proxy/oauth2-proxy -f values/oauth2-proxy.yaml

# Oauth client configuration specifics
config:
  existingSecret: oauth2-proxy-secrets

  cookieName: "general-oauth2"
  # Default configuration, to be overridden
  configFile: |-
    email_domains = [ "*" ]
    upstreams = [ "file:///dev/null" ]
    skip_provider_button = true
    allowed_groups = [ "developers", "admins" ]
    cookie_secure = false
    cookie_domains = [".k8s.alikhil.dev", "k8s.alikhil.dev"]
    whitelist_domains = [ "*.k8s.alikhil.dev", "k8s.alikhil.dev" ]
    cookie_samesite = "lax"
    cookie_csrf_per_request = true
    cookie_csrf_expire = "15m"
    pass_access_token = true
    pass_authorization_header = true
    provider = "oidc"
    provider_display_name = "PocketID"
    reverse_proxy = true
    scope = "openid profile email groups"
    session_store_type = "redis"
    set_xauthrequest = true
    set_authorization_header = true
    silence_ping_logging = true
    skip_auth_preflight = true
    ssl_insecure_skip_verify = true
    ssl_upstream_insecure_skip_verify = true
    insecure_oidc_allow_unverified_email = true
    oidc_issuer_url = "https://pocket-id.k8s.alikhil.dev"
    redirect_url = "https://k8s.alikhil.dev/oauth2/callback"
    # to reduce log amount
    request_logging = false


ingress:
  enabled: true
  className: nginx
  path: /
  # Only used if API capabilities (networking.k8s.io/v1) allow it
  pathType: ImplementationSpecific
  # Used to create an Ingress record.
  hosts:
    - k8s.alikhil.dev
  labels: {}
  annotations:
    kubernetes.io/tls-acme: "true"
    nginx.ingress.kubernetes.io/cors-allow-origin: '*'
    nginx.ingress.kubernetes.io/enable-cors: 'true'
    kubernetes.io/ingress.allow-http: "false"
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
  tls:
    # Secrets must be manually created in the namespace.
    - secretName: oauth2-proxy-tls
      hosts:
        - k8s.alikhil.dev

# Configure the session storage type, between cookie and redis
sessionStorage:
  # Can be one of the supported session storage cookie|redis
  type: redis
  redis:
    existingSecret: ""
    password: ""
    passwordKey: "redis-password"
    clientType: "standalone"

# Enables and configure the automatic deployment of the redis subchart
redis:
  # provision an instance of the redis sub-chart
  enabled: true
  architecture: standalone
  auth:
    enabled: false
  master:
    persistence:
      enabled: false

    requests:
      cpu: 100m
      memory: 128Mi
    limits:
      cpu: 1
      memory: 1Gi

Testing

Install whoami

To check oauth2-proxy we need a dummy service. I will use whoami helm chart for this.

helm repo add cowboysysop https://cowboysysop.github.io/charts/
helm install whoami cowboysysop/whoami

ingress:
  enabled: true
  ingressClassName: nginx
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    kubernetes.io/ingress.allow-http: "true"
    kubernetes.io/tls-acme: "true"
    # put oauth2-proxy domain here
    nginx.ingress.kubernetes.io/auth-signin: "https://k8s.alikhil.dev/oauth2/start?rd=https://$host$request_uri$is_args$args"
    # service-name.namespace-name
    nginx.ingress.kubernetes.io/auth-url: http://oauth2-proxy.oauth-example.svc.cluster.local:80/oauth2/auth
  hosts:
  - host: whoami.k8s.alikhil.dev
    paths:
    - /
  tls:
  - hosts:
    - whoami.k8s.alikhil.dev
    secretName: whoami-cert

Perform test

Go to whoami url and check if oauth2-proxy redirects you to Pocket ID like in the demo:

Takeaways

Later, when you need to protect any service in Kubernetes with oauth2-proxy, you simply need to add two annotations to your Ingress resource:

annotations:
  nginx.ingress.kubernetes.io/auth-signin: "https://k8s.alikhil.dev/oauth2/start?rd=https://$host$request_uri$is_args$args"
  nginx.ingress.kubernetes.io/auth-url: http://oauth2-proxy.oauth-example.svc.cluster.local:80/oauth2/auth

I’ve got a medium-sized table, about 120 by 80 cm. It’s wide (deep) but not too long. I need to keep everything in order and clean so I can work comfortably.

Here’s what my setup looked like before I made all the changes I mentioned.

As you can see, I’ve got a work laptop, a Mac mini, a monitor on its own stand, a journal, AirPods, and a few other things. I also bought a USB switch at some point because I got tired of plugging and unplugging my webcam manually in my KVM-less setup.

Here’s what I’ve done

• I mounted the monitor to the arm, which freed up space below the screen.
• I set up my Mac mini under the table.
• I’ve got my MacBook pro mounted under the table.
• I installed the USB hub into the monitor arm. It’s a solid connection point, but the switch button on it is a bit uncomfortable to press. So,
• Put the extended switch button under the table, close to the chair.
• There’s a mounted headphones holder under the table.
• The cables that ran next to each other were routed through the sleeves.
• Bind cables together with hook and loops tie

List of things that I’ve used

• The cable sleeve is super handy for binding the cables together!
• This cable sleeve is a bit pricey, but it lets you pull cables out from the middle without damaging it.
• MacBook under desk mount support. Antiscratch stickers came loose at the second day. So don’t recommend this one.
• Mac Mini under desk support
• Hook and loops tie
• Cable clips
• Adjustable monitor support arm

What I’ve got

Before	After

My devices

Computers

• Macbook Air M2 14" – work Laptop.
• Mac Mini M1 – my personal computer.
• ClockworkPi uConsole, based on RPI CM4 is a portable device for Linux tinkering.

Peripheral devices

• The UGREEN Vertical Wireless - can connect up to three devices: Two via Bluetooth and one via a 2.4GHz USB dongle.
• The Keychrone K15 Max allows me to connect up to three devices via Bluetooth.
• The Monitor Dell 27 4K UHD con USB-C (S2722QC) with two HDMI inputs and one USB-C port which allows me to connect it up to three devices.

As you can see, all peripheral devices could connect to all my computers. At least in theory.

Connecting devices

Historically my devices were numbered as follows:

1. uConsole
2. Macbook Air
3. Mac Mini

Keyboard

The keyboard connection scheme is straightforward: uConsole connects via Bluetooth to the first device, the MacBook Air, as the second device, and the Mac Mini as the third device.

Later, I can use the Fn + 1/2/3 hotkey to switch the keyboard between devices.

Mouse

The first connection of the Ugreen mouse is reserved for the 2.4 GHz USB dongle. I plugged it into my uConsole, and then my MacBook Air and Mac mini connected as the second and third devices, respectively.

To switch devices with the mouse, press the red button on the bottom.

Monitor

The MacBook Air is connected to the USB-C port, which charges the computer.

The Mac Mini connects via HDMI-1, and the uConsole connects via HDMI-2.

Easiest way to switch devices

The easiest way to switch devices on the monitor is to press the small, round button in the bottom right corner to open the settings menu.

Then, choose the desired port.

However, “easiest” does not mean “most comfortable”. Changing the monitor’s input source this way requires pressing these small buttons several times. You also need to keep track of which devices are connected to HDMI-1 and HDMI-2.

The comfortable way to switch devices

Instead of pressing buttons on the monitor and navigating its menu, I could press a hotkey on my keyboard to trigger the monitor to change input sources via its API (Display Data Channel/Command Interface Standard (DDC/CI).).

I have explained in detail how one could do it on a Mac in my another post - Monitor input source control on Mac.

I won’t go into detail here. I’ll just say that on my Mac Mini and MacBook Air, I have configured the following:

Mac Mini (#3)

• On CMD + F1 triggers switch to uConsole
• On CMD + F2 triggers switch to Macbook Air

Macbook Air (#2)

• On CMD + F1 triggers switch to uConsole
• On CMD + F3 triggers switch to Mac mini

For uConsole Linux machine (#1) I used ddcutil and configured the following hotkeys:

• Ctrl + F2 triggers switch to Macbook Air
• Ctrl + F3 triggers switch to Mac Mini

Switch sequence

Once all the devices are connected and the hotkeys are configured, the following sequence of actions is needed to switch to device #N (where N is 1, 2, or 3):

1. Switch the monitor input source by pressing CMD + F#N.
2. Switch the keyboard device by pressing Fn + #N.
3. Switch the mouse by pressing red button on the bottom of it until the indicator is under #N is blinking.

For example, let’s assume I am currently using my third device – Mac Mini, to switch to Macbook Air (#2) I do:

1. Press CMD + F2
2. Press Fn + 2
3. Press red button on the bottom of the mouse until indicator under 2 is on.

Here is a demo video:

Pros and Cons

Pros

• I don’t need a special KVM switch to switch between devices.
• I use my keyboard to switch (for two-thirds of the KVM).

Cons

• Switching the mouse takes longer since there is only one way iteration over the connected devices.
• Three actions are needed to switch all peripheral devices, as opposed to one action with a KVM.
• I still need to manually reconnect other peripheral devices, e.g. web camera.

Final thoughts

It has some limitations, but if you have a keyboard and mouse that support multiple connected devices, as well as a monitor, you won’t need a special KVM switch to switch between computers.

Thank you for reading this!

There is a common misconception in the Kubernetes world that bothers me. The official Kubernetes documentation and most guides claim that “if you want zero downtime upgrades, just use rolling update mode on deployments”. I have learned the hard way that this simply it is not true - rolling updates alone are NOT enough for true zero-downtime deployments.

And it is not just about deployments. Your pods can be terminated for many other reasons: scaling events, node maintenance, preemption, resource constraints, and more. Without proper graceful shutdown handling, any of these events can lead to dropped requests and frustrated users.

In this post, I will share what I have learned about implementing proper graceful shutdown in Kubernetes. I will show you exactly what happens behind the scenes, provide working code examples, and back everything with real test results that clearly demonstrate the difference.

The Problem: Hidden Errors During Pod Termination

If you are running services on Kubernetes, you have probably noticed that even with rolling updates (where Kubernetes gradually replaces pods), you might still see errors during deployment. This is especially annoying when you are trying to maintain “zero-downtime” systems.

When Kubernetes needs to terminate a pod (for any reason), it follows this sequence:

1. Sends a SIGTERM signal to your container
2. Waits for a grace period (30 seconds by default)
3. If the container does not exit after the grace period, it gets brutal and sends a SIGKILL signal

The problem? Most applications do not properly handle that SIGTERM signal. They just die immediately, dropping any in-flight requests. In the real world, while most API requests complete in 100-300ms, there are often those long-running operations that take 5-15 seconds or more. Think about processing uploads, generating reports, or running complex database queries. When these longer operations get cut off, that’s when users really feel the pain.

When Does Kubernetes Terminate Pods?

Rolling updates are just one scenario where your pods might be terminated. Here are other common situations that can lead to pod terminations:

• Horizontal Pod Autoscaler Events: When HPA scales down during low-traffic periods, some pods get terminated.

• Resource Pressure: If your nodes are under resource pressure, the Kubernetes scheduler might decide to evict certain pods.

• Node Maintenance: During cluster upgrades, node draining causes many pods to be evicted.

• Spot/Preemptible Instances: If you are using cost-saving node types like spot instances, these can be reclaimed with minimal notice.

All these scenarios follow the same termination process, so implementing proper graceful shutdown handling protects you from errors in all of these cases - not just during upgrades.

Let’s Test It: Basic vs. Graceful Service

Instead of just talking about theory, I built a small lab to demonstrate the difference between proper and improper shutdown handling. I created two nearly identical Go services:

• Basic Service: A standard HTTP server with no special shutdown handling
• Graceful Service: The same service but with proper SIGTERM handling

Both services:

• Process requests that take about 4 seconds to complete (intentionally configured for easier demonstration)
• Run in the same Kubernetes cluster with identical configurations
• Serve the same endpoints

I specifically chose a 4-second processing time to make the problem obvious. While this might seem long compared to typical 100-300ms API calls, it perfectly simulates those problematic long-running operations that occur in real-world applications. The only difference between the services is how they respond to termination signals.

To test them, I wrote a simple k6 script that hammers both services with requests while triggering rolling restart of service’s deployment. Here is what happened:

Basic Service: The Error-Prone One

checks_total.......................: 695    11.450339/s
checks_succeeded...................: 97.98% 681 out of 695
checks_failed......................: 2.01%  14 out of 695

✗ status is 200
  ↳  97% — ✓ 681 / ✗ 14

http_req_failed....................: 2.01%  14 out of 696

Graceful Service: The Reliable One

checks_total.......................: 750     11.724824/s
checks_succeeded...................: 100.00% 750 out of 750
checks_failed......................: 0.00%   0 out of 750

✓ status is 200

http_req_failed........... ........: 0.00%  0 out of 751

The results speak for themselves. The basic service dropped 14 requests during the update (that is 2% of all traffic), while the graceful service handled everything perfectly without a single error.

You might think “2% it is not that bad” — but if you are doing several deployments per day and have thousands of users, that adds up to a lot of errors. Plus, in my experience, these errors tend to happen at the worst possible times.

So How Do We Fix It? The Graceful Shutdown Recipe

After digging into this problem and testing different solutions, I have put together a simple recipe for proper graceful shutdown. While my examples are in Go, the fundamental principles apply to any language or framework you are using.

Here are the key ingredients:

1. Listen for SIGTERM Signals

First, your app needs to catch that SIGTERM signal instead of ignoring it:

// Set up channel for shutdown signals
stop := make(chan os.Signal, 1)
signal.Notify(stop, os.Interrupt, syscall.SIGTERM)

// Block until we receive a shutdown signal
<-stop
log.Println("Shutdown signal received")

This part is easy - you are just telling your app to wake up when Kubernetes asks it to shut down.

2. Track Your In-Flight Requests

You need to know when it is safe to shut down, so keep track of ongoing requests:

// Create a request counter
var inFlightRequests atomic.Int64

http.HandleFunc("/process", func(w http.ResponseWriter, r *http.Request) {
    // Increment counter when request starts
    inFlightRequests.Add(1)
    // do not forget to decrement when done!
    defer inFlightRequests.Add(-1)

    // Your normal request handling...
    time.Sleep(4 * time.Second)  // Simulating long-running work
})

This counter lets you check if there are still requests being processed before shutting down. it is especially important for those long-running operations that users have already waited several seconds for - the last thing they want is to see an error right before completion!

3. Separate Your Health Checks

Here is a commonly overlooked trick - you need different health check endpoints for liveness and readiness:

// Track shutdown state
var isShuttingDown atomic.Bool

// Readiness probe - returns 503 when shutting down
http.HandleFunc("/ready", func(w http.ResponseWriter, r *http.Request) {
    if isShuttingDown.Load() {
        w.WriteHeader(http.StatusServiceUnavailable)
        fmt.Fprintf(w, "Shutting down, not ready")
        return
    }

    w.WriteHeader(http.StatusOK)
    fmt.Fprintf(w, "Ready for traffic")
})

// Liveness probe - always returns 200 (we are still alive!)
http.HandleFunc("/alive", func(w http.ResponseWriter, r *http.Request) {
    w.WriteHeader(http.StatusOK)
    fmt.Fprintf(w, "I'm alive")
})

This separation is crucial. The readiness probe tells Kubernetes to stop sending new traffic, while the liveness probe says “do not kill me yet, I’m still working!”

4. The Shutdown Dance

Now for the most important part - the shutdown sequence:

// Step 1: Mark service as shutting down
isShuttingDown.Store(true)

// Step 2: Let Kubernetes notice the readiness probe failing
time.Sleep(5 * time.Second)

// Step 3: Wait for in-flight requests to finish
for inFlightRequests.Load() > 0 {
    time.Sleep(1 * time.Second)
}

// Step 4: Finally, shut down the server gracefully
ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
defer cancel()

if err := server.Shutdown(ctx); err != nil {
    log.Fatalf("Forced shutdown: %v", err)
}

I’ve found this sequence to be optimal. First, we mark ourselves as “not ready” but keep running. We pause to give Kubernetes time to notice and update its routing. Then we patiently wait until all in-flight requests finish before actually shutting down the server.

5. Configure Kubernetes Correctly

Do not forget to adjust your Kubernetes configuration:

# Use different probes for liveness and readiness
livenessProbe:
  httpGet:
    path: /alive  # Always returns OK
    port: 8080
  periodSeconds: 10

readinessProbe:
  httpGet:
    path: /ready  # Returns 503 during shutdown
    port: 8080
  periodSeconds: 3
  failureThreshold: 2

# Give pods enough time to shut down gracefully
terminationGracePeriodSeconds: 30 # Stops routing traffic after 2 failed checks (6 seconds)

This tells Kubernetes to wait up to 30 seconds for your app to finish processing requests before forcefully terminating it.

TL; DR; Quick Tips

If you are in a hurry, here are the key takeaways:

1. Catch SIGTERM Signals: Do not let your app be surprised when Kubernetes wants it to shut down.

2. Track In-Flight Requests: Know when it is safe to exit by counting active requests.

3. Split Your Health Checks: Use separate endpoints for liveness (am I running?) and readiness (can I take traffic?).

4. Fail Readiness First: As soon as shutdown begins, start returning “not ready” on your readiness endpoint.

5. Wait for Requests: Do not just shut down - wait for all active requests to complete first.

6. Use Built-In Shutdown: Most modern web frameworks have graceful shutdown options; use them!

7. Configure Terminaton Grace Period: Give your pods enough time to complete the shutdown sequence.

8. Test Under Load: You will not catch these issues in simple tests - you need realistic traffic patterns.

Wrap Up: Is It Worth the Extra Code?

You might be wondering if adding all this extra code is really worth it. After all, we’re only talking about a 2% error rate during pod termination events.

From my experience working with high-traffic services, I would say absolutely yes - for three reasons:

1. User Experience: Even small error rates look bad to users. Nobody wants to see “Something went wrong” messages, especially after waiting 10+ seconds for a long-running operation to complete.

2. Cascading Failures: Those errors can cascade through your system, especially if services depend on each other. Long-running requests often touch multiple critical systems.

3. Deployment Confidence: With proper graceful shutdown, you can deploy more frequently without worrying about causing problems.

The good news is that once you have implemented this pattern once, it is easy to reuse across your services. You can even create a small library or template for your organization.

In production environments where I have implemented these patterns, we have gone from seeing a spike of errors with every deployment to deploying multiple times per day with zero impact on users. that is a win in my book!

Further Reading

If you want to dive deeper into this topic, I recommend checking out the article Graceful shutdown and zero downtime deployments in Kubernetes from learnk8s.io. It provides additional technical details about graceful shutdown in Kubernetes, though it does not emphasize the critical role of readiness probes in properly implementing the pattern as we have discussed here.

For those interested in seeing the actual code I used in my testing lab, I’ve published it on GitHub with instructions for running the demo yourself.

Have you implemented graceful shutdown in your services? Did you encounter any other edge cases I didn’t cover? Let me know in the comments how this pattern has worked for you!

Requirements

What I have

• A Mikrotik Hex S router with a dynamic public IP address.

• Services in a cloud VM (Ubuntu 22) with a static public IP address.

• Services in a VM on my home network.

• Clients - laptops and phones - that need to access the services in my home and cloud network.

What I want

• Clients outside of my home network should be able to access services both on my home and cloud network.

• Only traffic to my home and cloud network should be routed through the VPN.

• Clients inside my home network should be able to access services on my cloud network without additional configuration.

• No external centralized service should be used.

• No open ports on my home router.

Implementation

Nowadays, there are plenty of VPN solutions like zero-tier and tailscale. However, I think they are too bloated for my humble needs and WireGuard is more than enough for that.

Because of last requirement, it’s obvious that traffic to home network should be routed though my cloud server.
So, I will use WireGuard to create a tunnel between mikrotik router and cloud server.
This way, I can access my home network from anywhere without exposing any ports on my home router.

I. Initial configuration of WireGuard on cloud VM

For the sake of reproducibility and simplicity I will use vanilla wireguard and configure it on OS level, not in docker container.

1. Install wireguard on Ubuntu 22.04

sudo apt update
sudo apt install wireguard -y

# Edit the configuration file
sudo nano /etc/sysctl.conf
# Find and uncomment the line:
net.ipv4.ip_forward=1
# Save and exit

# Then apply the changes:
sudo sysctl -p

2. Create public and private key

sudo su -
cd /etc/wireguard
# Generate private and public keys
wg genkey | tee privatekey | wg pubkey > publickey

# Check the keys
cat privatekey
cat publickey

3. Create the configuration file

I will use 172.16.10.0/24 subnet for Wireguard network.

sudo nano /etc/wireguard/wg0.conf
# Add the following lines:
[Interface]
Address = 172.16.10.1/24
ListenPort = 27277 # You can choose any port you want
Privatekey = <your_private_key> # from previous step

# These are placeholder lines for next steps, keep them commented for now
# # Mikrotik peer
# [Peer]
# AllowedIPs = 172.16.10.0/24,192.168.0.0/16
# PublicKey = mikrotik public key

# # client peer
# [Peer]
# AllowedIPs = 172.16.10.2/32
# PublicKey = first client device public key

# CRTL+X: save and exit

# Change the permissions of the configuration file
chmod 600 wg0.conf

4. Start the WireGuard interface

# Enable service to start on boot
systemctl enable wg-quick@wg0.service
systemctl daemon-reload

# Start the service
systemctl start wg-quick@wg0
# Check wg status
wg

It should show the interface is up like this

More commands to check the status of the service:

# Check the status of the service
systemctl status wg-quick@wg0
# Restart the service if needed
systemctl restart wg-quick@wg0

II. Mikrotik configuration

I will use Mikrotik command line interface (CLI) to configure the router. You can use Winbox or WebFig if you prefer.

1. Create WireGuard interface

# Create WireGuard interface and it will automatically generate private and public keys
/interface wireguard add listen-port=13231 mtu=1420 name=cloud-wg
# Add the IP address to the interface
/ip add address=172.16.10.3/24 interface=cloud-wg network=172.16.10.0

# Print the keys, you will need only the public key later
/interface/wireguard/print

2. Create the peer

Here we add cloud vm as a peer to the Mikrotik router’s wireguard. The public key of the cloud server is needed here.

# In allowed-address we add IP ranges which will be routed through this peer
# 172.21.0.0/16 - subnet of docker containers on cloud server
# 172.16.10.0/16 - subnet of wireguard network
/interface wireguard peers add allowed-address=172.16.10.0/24,172.21.0.0/16 \
    endpoint-address=cloud.vm.ip.address \
    endpoint-port=27277 \
    interface=cloud-wg \
    public-key="PUT CLOUD SERVER PUBLIC KEY HERE" \
    name=peer1 persistent-keepalive=25s

# Here is a tricky part
# Routing rule for subnet of wireguard network is added automatically on adding IP address to the interface
# But we need to add explicitly the route for docker containers subnet
# You may need to adjust the distance and routing-table values
/ip route disabled=no distance=1 dst-address=172.21.0.0/16 gateway=cloud-wg routing-table=main scope=30 suppress-hw-offload=no target-scope=10

3. Add WireGuard peer (VM)

sudo nano /etc/wireguard/wg0.conf
# Uncomment the lines for Mikrotik peer
# Mikrotik peer
[Peer]
AllowedIPs = 172.16.10.0/24,192.168.0.0/16
PublicKey = mikrotik public key

# Save and exit

# Restart the WireGuard service
sudo systemctl restart wg-quick@wg0
# Check if changes are applied
wg show

You should see the Mikrotik peer in the list of peers.

# ping wireguard IP of cloud server
ping 172.16.10.1

# resolve google.com via adguard container on cloud vm
put [resolve google.com server 172.21.0.114]

# ping wireguard IP of Mikrotik router
ping 172.168.10.3

# resolve google.com via adguard container on home adguard
dig google.com @192.168.11.2

# ping wireguard IP of cloud server
ping 172.16.10.1

# resolve google.com via adguard container on cloud adguard
dig google.com @172.121.0.114

IV. Add first client device as a peer

I recommend you to use your smartphone as first client device, because it can work from both home WiFi and mobile data. This way you can test the connection from both networks.

Also, install on your smartphone:

• WireGuard app (iOS, Android)
• Network debugging app (iOS, Android)

1. Create keys for the client

Install Wireguard app for your client OS.

Then, generate public and private keys on the device, for that create config from scratch in the app and then click on Generate keypair button.

Or you can generate keys on the cloud server and then copy them to the client device.

wg genkey | tee peer-privatekey | wg pubkey > peer-publickey

2. Add the client as a peer to WireGuard config on cloud server

On the cloud server, edit the WireGuard config file and add the client as a peer.

Each time increment previous peer address by 1.

sudo nano /etc/wireguard/wg0.conf
# Uncomment the lines for client peer
# client peer
[Peer]
AllowedIPs = 172.16.10.2/32
PublicKey = put public key

# CRTL+X: save and exit

# Restart the WireGuard service
sudo systemctl restart wg-quick@wg0

# Check if changes are applied
wg show

3. Continue configuring the client device

You already have public and private keys for the client device, other configuration parameters are:

Interface

• Address - It’s address of peer in wireguard subnet. Put the same address you set in AllowedIPs field in previous step.
• DNS servers - if you have adguard/pihole running on the cloud server, you can use it as a DNS server. Put it’s IP address here.
• MTU and ListenPort - you can leave them empty, they will be set automatically.

Peer

• Endpoint - cloud server IP address and port (27277)
• Public key - public key of the cloud server
• AllowedIPs - here we put all subnets that we want to access from this current client device

Here is an example of the configuration file for the client device:

[Interface]
PrivateKey = private-key-of-client-device
Address = 172.16.10.2/32
DNS = 172.21.0.114 # IP of adguard container on cloud server

[Peer]
PublicKey = public-key-of-cloud-server
AllowedIPs = 192.168.0.0/16, 172.16.10.0/24, 172.21.0.0/16 # subnets of home, cloud and wireguard network
Endpoint = ip.of.cloud.servner:27277

That’s it! Disconnect your device from the home Wi-Fi, switch to mobile data and connect to the VPN.

Then try to:

• ping the cloud server and Mikrotik router IP addresses in wireguard subnet.
• check ports of services in docker containers on cloud and home server VM.

ping cloud	ping home	check adguard port

V. Bonus. DNS configuration

Since I have 2 adguard instances and I use them as DNS servers everywhere, I will add DNS records for accessing my services:

• *.cloud.domain.com - pointing to traefik docker container on cloud server
• *.home.domain.com - pointing to traefik docker container on home server

Thus, I can access my services using domain names instead of IP addresses.

VI. Final thoughts

I hope this tutorial was helpful for you. I will keep it updated if I find any issues or improvements.

If you have any questions or suggestions, feel free to leave a comment below.

Credits to @laroberto for their guide on LAN access with WireGuard. I followed it to set up the initial configuration and then adapted it to my needs.

When I started writing my first scripts I faced a problem: how to store and use secrets in my scripts. I have found a solution and I want to share it with you.

The problem

Let’s say I want to write a script that will send me telegram notifications. To do so I need to store my telegram bot token and chat id. Since I keep my RouterOS configuration in a git repository, I don’t want to hardcode my secrets in the script.

:global sendTelegramMessage do={
    :local botToken "1234567890:ABCDEFGHIJKLMN"
    :local chatId "10000000"
    :local message "$1"

    # telegram notification
    /tool fetch url="https://api.telegram.org/bot$botToken/sendMessage\?chat_id=$chatId&text=$message" keep-result=no
}

The solution

RouterOS has low level feature /ppp secret which can be used to store secrets. However, it could be inconvenient and a bit messy to use it directly in scripts. Instead, I would like to have more high level API to store and use secrets.

And, I have one. There is post in mikrotik forum by user with nickname Amm0. Ammo has shared a script of global function which can be used to store and retrieve secrets like this:

$SECRET set mySecret password="mySecretPassword"
:put [$SECRET get mySecret]

Now, I modify my script to use this function to keep it clean and secure:

:global sendTelegramMessage do={
    :local botToken
    :set botToken "$[$SECRET get TELEGRAM_TOKEN]"
    :local chatId "$[$SECRET get CHAT_ID]"
    :local message "$1"

    # telegram notification
    /tool fetch url="https://api.telegram.org/bot$botToken/sendMessage\?chat_id=$chatId&text=$message" keep-result=no
}

### $SECRET
#   get <name>
#   set <name> password=<password>
#   remove <name
#   print
:global SECRET
:set $SECRET do={
    :global SECRET

    # helpers
    :local fixprofile do={
        :if ([/ppp profile find name="null"]) do={:put "nothing"} else={
            /ppp profile add bridge-learning=no change-tcp-mss=no local-address=0.0.0.0 name="null" only-one=yes remote-address=0.0.0.0 session-timeout=1s use-compression=no use-encryption=no use-mpls=no use-upnp=no
        }
    }
    :local lppp [:len [/ppp secret find where name=$2]]
    :local checkexist do={
        :if (lppp=0) do={
            :error "\$SECRET: cannot find $2 in secret store"
        }
    }

    # $SECRET
    :if ([:typeof $1]!="str") do={
        :put "\$SECRET"
        :put "   uses /ppp/secrets to store stuff like REST apikeys, or other sensative data"
        :put "\t\$SECRET print - prints stored secret passwords"
        :put "\t\$SECRET get <name> - gets a stored secret"
        :put "\t\$SECRET set <name> password=\"YOUR_SECRET\" - sets a secret password"
        :put "\t\$SECRET remove <name> - removes a secret"
    }

    # $SECRET print
    :if ($1~"^pr") do={
        /ppp secret print where comment~"\\\$SECRET"
        :return [:nothing]
    }

    # $SECRET get
    :if ($1~"get") do={
        $checkexist
       :return [/ppp secret get $2 password]
    }

    # $SECRET set
    :if ($1~"set|add") do={
        :if ([:typeof $password]="str") do={} else={:error "\$SECRET: password= required"}
        :if (lppp=0) do={
            /ppp secret add name=$2 password=$password
        } else={
            /ppp secret set $2 password=$password
        }
        $fixprofile
        /ppp secret set $2 comment="used by \$SECRET"
        /ppp secret set $2 profile="null"
        /ppp secret set $2 service="async"
        :return [$SECRET get $2]
    }

    # $SECRET remove
    :if ($1~"rm|rem|del") do={
        $checkexist
        :return [/ppp secret remove $2]
    }
    :error "\$SECRET: bad command"
}

Conclusion

The good thing about this approach is that secrets storing and retrieving mechanism encapsulated and can be easily changed in the future without changing the scripts. Also, it is easy to use and understand.

Keep your secrets safe and happy scripting!

Today I want to share with you another reason why you should avoid using http.DefaultClient in your code.

The Story

As an SRE at Criteo, I both read and write code. Last week, I worked on patching Updatecli — an upgrade automation tool written in Go.

The patch itself was just ~15 lines of code. But then I spent three days debugging a strange authorization bug in an unrelated part of the code.

It happened because of code like this:

client := http.DefaultClient
client.Transport = &transport.PrivateToken{
    Token: s.Token,
    Base:  client.Client.Transport,
}

Since http.DefaultClient is a reference, not a value:

var DefaultClient = &Client{}

The code above is effectively the same as:

http.DefaultClient.Transport = &transport.PrivateToken{
    Token: s.Token,
    Base:  http.DefaultClient.Transport,
}

Later, in a third-party library, I found this:

if opts.Client == nil {
    opts.Client = http.DefaultClient
}

The Fix

To prevent this, I had to change the code to:

client := &http.Client{}
client.Transport = &transport.PrivateToken{
    Token: s.Token,
    Base:  client.Transport,
}

As a result, the patched client with the authorization transport got injected into the third-party library, causing unexpected failures.

Bugs like this are hard to catch just by reading the code, since they involve global state mutation. But could they be detected by linters?

What do you think? How do you find or prevent such issues in your projects?

If you’re dealing with multiple SIM cards and want to receive SMS in Telegram, I have a straightforward approach. You’ll need a Linux machine that’s always online, connected to the internet, and about $10.

What You’ll Need

• A physical SIM card
• A USB modem that’s supported by the Gammu library
• A Telegram bot token, chat or channel ID
• A Linux machine with a free USB port
• Docker and Docker Compose installed

Finding the Right Modem

If you have a USB modem at home, check if it’s supported by Gammu.

For our purposes, we don’t need an expensive 4G modem with advanced features. Any basic 2G/3G modem will work, and these are easy to find at a discounted price on sites like eBay or Wallapop.

Search for “Huawei USB modem,” sort by price, and look for unlocked options or ones with compatible firmware.

For instance:

Next, go to the Gammu website and look up the device. Make sure it appears on the list and that “SMS” is included in the “Supported features” column:

If the device meets these requirements, it’s good to go!

Setup Instructions

Before starting the setup, it’s best to connect the modem with the SIM card already inserted to your PC and check that it’s functioning properly.

Identify Device Path

Run the following command to identify the device path:

tree /dev/serial/by-id/

You should see a paths similar to:

/dev/serial/by-id
├── usb-HUAWEI_HUAWEI_Mobile-if00-port0 -> ../../ttyUSB0
├── usb-HUAWEI_HUAWEI_Mobile-if02-port0 -> ../../ttyUSB1
├── usb-HUAWEI_HUAWEI_Mobile-if03-port0 -> ../../ttyUSB2

Choose a path that ends with ttyUSB0, in my case it’s /dev/serial/by-id/usb-HUAWEI_HUAWEI_Mobile-if00-port0.

Running the Service

Using Docker Compose, set up your configuration:

services:
  gammu:
    image: ghcr.io/alikhil/sms-to-telegram:latest
    volumes:
    - type: bind
      source: /dev/serial/by-id/usb-HUAWEI_HUAWEI_Mobile-if00-port0 # Change this to your device path
      target: /dev/modem
    privileged: true
    environment:
      - BOT_TOKEN=<put your telegram bot token here>
      - PIN=<your sim card pin>
      - CHAT_ID=<telegram chat/channel ID>
      - DEVICE=/dev/modem
      - PROTOCOL=at
    cap_add:
    - NET_ADMIN
    - SYS_MODULE

Save the configuration to a docker-compose.yml file and run:

docker compose up -d
docker compose logs -f gammu

If everything is set up correctly, you should see the following log messages:

gammu-1  | Fri 2024/10/04 17:50:56 gammu-smsd[12]: Created POSIX RW shared memory at 0x7fcf90b21000
gammu-1  | Fri 2024/10/04 17:50:56 gammu-smsd[12]: Starting phone communication...
gammu-1  | Fri 2024/10/04 17:55:30 gammu-smsd[12]: Ignoring incoming SMS info as not a Status Report in SR memory.
gammu-1  | Fri 2024/10/04 17:55:33 gammu-smsd[12]: Read 1 messages
gammu-1  | Fri 2024/10/04 17:55:33 gammu-smsd[12]: Received IN20241004_195517_00_Celerity_00.txt
gammu-1  | Fri 2024/10/04 17:55:33 gammu-smsd[13]: Starting run on receive: /etc/sms_to_telegram.sh IN20241004_195517_00_Celerity_00.txt
gammu-1  | Fri 2024/10/04 17:55:33 gammu-smsd[12]: Process finished successfully

To test SMS reception, you can use free online SMS-sending services (search for “send SMS for free”) or try logging into Telegram, your bank account, etc.

How It Works

The Gammu library provides a unified interface for working with phones and modems from various manufacturers.

On top of that, there’s the Gammu SMS Daemon, which receives SMS messages and triggers a custom script—in our case, script to send the messages to Telegram.

Final Thoughts

Thanks to @kutovoys for the idea and Docker image!

This is a simple, affordable, and scalable solution—especially if you’re into self-hosting.

This post was originally written for vas3k.club.

In this post I will show you how to configure hotkeys for that.

Hardware

You will need a monitor with multiple input sources. For example, I have Dell S2722QC tt has 2 HDMI ports and 1 USB-C port where:

• Macbook Air connected to port HDMI-2
• Mac Mini connected to port USB-C-1

Software

There is app called BetterDisplay that has a lot of powerful features. But for our case we need only one feature - change display inputs using DDC.

Install it on both Macs. You will have 14 days trial period with all PRO features.

Enable Accessibility for BetterDisplay in System Settings -> Privacy & Security -> Accessibility.

Then try to switch input source by clicking on BetterDisplay icon in the menu bar -> DDC Input Source -> Select next port.

If it works, you can continue to the next step. Otherwise check if your monitor supports DDC protocol and ensure Accessibility is enabled for BetterDisplay.

Paid option

If you are ready to pay 19$/19€ x2 for both Macs you can buy BetterDisplay. And then configure hotkeys in the app settings Settings -> Keyboards -> Custom keyboard shortcuts -> DDC Input Source.

Click “Record Shortcut” and press the key combination you want to use, for example CMD + F1 and CMD + F2.

Free option

If you like me don’t want to pay for 40$ for single feature there is a hacky way to do it.

We need an app that can handle hotkeys and run shell commands. I use Raycast, so called “Spotlight on steroids” and it can handle custom hotkeys. Or you can use any other app you like.

Configuring shell command

Before configuring Raycast we need to know ddc value for each input source. To do so, go to Settings -> Displays -> “Your monitor name” -> DDC Input Sources, and save IDs from Value column for each input source:

In my case it’s 18 for HDMI-2 and 25 for USB-C-1.

Then create a directory ~/raycast-scripts and put there a script change-input-source.sh:

#!/bin/bash

# See full documentation here: https://github.com/raycast/script-commands
#
# Required parameters:
# @raycast.schemaVersion 1
# @raycast.title Switch Monitor Input Source
# @raycast.mode silent
#
# Optional parameters:
# @raycast.icon 🖥️
# @raycast.packageName Raycast Scripts

DEST_ID=18 <PUT YOUR DDC ID HERE>
DEST_NAME="Home Mac Mini"

# PUT YOUR ACTUAL HOSTNAME
if [ `hostname` == "Aliks-Mac-mini.local" ]; then
  DEST_ID=25 <PUT YOUR SECOND DDC ID HERE>
  DEST_NAME="Work Macbook Air"
fi

echo "Switching monitor input source to $DEST_NAME"
/Applications/BetterDisplay.app/Contents/MacOS/BetterDisplay set -ddc=$DEST_ID -vcp=inputSelect

After that try to run it in terminal:

chmod +x ~/raycast-scripts/change-input-source.sh
~/raycast-scripts/change-input-source.sh

If it works, you can continue to the next step.

Configuring Raycast

1. Open Raycast and go to Settings -> Extensions -> Search for Scripts
2. Click on Add Script Directory and select ~/raycast-scripts
3. Click on Record Shortcut for newly added script and press the key combination you want to use, for example CMD + F1 on first Mac and CMD + F2 on second.

And that’s it! Now you can switch input source using hotkeys.

In this post, I will quickly descibe how you can build your own drone.io docker image.

Drone is very popular container native CI/CD platform. Not long time ago, there was release of new 1.0 version of drone. Which brang a lot of cool features and new license. The license tells that we can use Enterprise version of drone for free without any limits by building our own docker image if we are individuals or startup (read the licence for more detail).

So, how to build it?

Instructions

First, clone the drone repo to your local machine.

git clone git@github.com:drone/drone.git

Second, checkout to version of drone you want to build. For example, I want to build v1.3.1:

git checkout v1.3.1

We will use single dockerfile to build the image. To do so, we need to add extra step to existing dockerfile which is in docker directory. Let’s say we want to build docker image for linux OS and amd64 architecture, then we will edit docker/Dockerfile.server.linux.amd64.

If you check the dockerfile you will see, that binaries are just copied into docker image during the build and they are built outside of the docker build. So, the step we will add to dockerfile is go build step.

To build the binary, we need to know what version of go is used for building binary in original docker image. We can find it in drone.yml build step. For version 1.3.1 of drone golang:1.12.9 docker image is used for building binaries.

Then, we use same image to build binary in our dockerfile:

docker/Dockerfile.server.linux.amd64

FROM golang:1.12.9 as builder

WORKDIR /go/src/github.com/drone/drone
COPY . .

ENV GOOS linux
ENV GOARCH amd64
ENV CGO_ENABLED 1
ENV REPO github.com/drone/drone
ENV GO111MODULE on
RUN go build -tags nolimit -ldflags "-extldflags \"-static\"" -o release/linux/${GOARCH}/drone-server ${REPO}/cmd/drone-server

FROM alpine:3.9 as alpine
RUN apk add -U --no-cache ca-certificates

FROM alpine:3.9
EXPOSE 80 443
VOLUME /data

ENV GODEBUG netdns=go
ENV XDG_CACHE_HOME /data
ENV DRONE_DATABASE_DRIVER sqlite3
ENV DRONE_DATABASE_DATASOURCE /data/database.sqlite
ENV DRONE_RUNNER_OS=linux
ENV DRONE_RUNNER_ARCH=amd64
ENV DRONE_SERVER_PORT=:80
ENV DRONE_SERVER_HOST=localhost
ENV DRONE_DATADOG_ENABLED=true
ENV DRONE_DATADOG_ENDPOINT=https://stats.drone.ci/api/v1/series

COPY --from=alpine /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/

COPY --from=builder /go/src/github.com/drone/drone/release/linux/amd64/drone-server /bin/
ENTRYPOINT ["/bin/drone-server"]

Also we need to delete .dockerignore file from root of the repo.

rm .dockerignore

Then we build docker image like:

docker build -t alikhil/drone:1.3.1 -f docker/Dockerfile.server.linux.amd64 .

That’s all! Now you can use own newly built docker image instead of official one if your use case meet license conditions.

Today I want you to share with you tutorial on how to deploy your SPA application to Kubernetes. Tutorial is oriented for those don’t very familiar with docker and k8s but want their single page application run in k8s.

Dockerize the application

I expect that you have docker installed in your machine. If it isn’t you can install it by following official installation guide.

As SPA project I will use vue-realworld-example-app as SPA project. You can your own SPA project if you have one.

So, I have cloned it, installed dependencies and built:

git clone https://github.com/gothinkster/vue-realworld-example-app
yarn
yarn build

Next step is to decide how our application will be served. There are bunch of possible solutions but I decided to use nginx since it recommends itself as one of the best http servers.

To serve SPA we need to return all requested files if they exist or otherwise fallback to index.html. To do so I wrote the following nginx config:

nginx.conf

# ...
# other configs

server {
  listen 80;
  root /app;

  location / {
    alias /app/;
    try_files $uri /index.html;
  }

}

Full config file can be found in my fork of the repo

Then, we need to write Dockerfile for building image with our application. Here it is:

FROM nginx
WORKDIR /root/
COPY ./dist /app
COPY ./nginx.conf /etc/nginx/conf.d/default.conf

We assume that artifacts of build placed in the dist directory and so that during the docker build the content of dist directory copied into containers /app directory.

Now, we are ready to build it:

docker build -t alikhil/my-spa:0.1 .

And run it:

docker run -p 8080:80 alikhil/my-spa:0.1

Then if we open http://localhost:8080 we will see something similar to:

Cool! It works!

We will need to use our newly builded docker image to deploy to k8s. So, we need to make it available from the k8s cluster by pulling to some docker registry. I will push image to DockerHub:

docker push alikhil/my-spa:0.1

Deploy to k8s

To run the application in k8s we will use Deployment resource type. Here it is:

deployment.yaml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: my-spa
  labels:
    app: my-spa
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: my-spa
    spec:
      containers:
      - image: alikhil/my-spa:0.1
        name: spa
        ports:
          - containerPort: 80
        resources:
          limits:
            cpu: 150m
            memory: 250Mi

Then we create deployment by running kubectl apply -f deployment.yaml and newly created pods can found:

$ kubectl get pods
NAME                      READY   STATUS    RESTARTS   AGE
my-spa-84b6dcd48d-mhv9f   1/1     Running   0          18s

Then we need to expose our app to the world. It can be done by using service of type NodePort or via Ingress. We will do it with Ingress. For that we will need service:

service.yaml

apiVersion: v1
kind: Service
metadata:
  name: my-spa
  labels:
    app: my-spa
spec:
  type: ClusterIP
  ports:
    - port: 80
      targetPort: 80
      protocol: TCP
      name: http
  selector:
    app: my-spa

And ingress itself:

ingress.yaml

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: my-spa-ing
  annotations:
    kubernetes.io/ingress.class: nginx
spec:
  tls:
  - hosts:
    - my-spa.example.com
    secretName: my-spa-cert-secret
  rules:
  - host: my-spa.example.com
    http:
      paths:
      - path: /
        backend:
          serviceName: my-spa
          servicePort: 80

kubectl apply -f ingress.yaml -f service.yaml

And here it is! Our SPA runs in the k8s!

Gamification

If you are only starting to learn then this will be helpful for you in double. Most of the people give up learning after several weeks or even days after they begin. It’s because of their motivation. It becomes lower with time. And in the beginning when you know almost nothing and understand that you should work hard and work a lot to learn. It really demotivates. And I think elements of gamification will help to increase motivation and turn learning process to habit. You can gamify your learning in any way you want. I recommend:

• Duolingo or Linguoleo - good for learning the basics of the language
• Tinycard - for learning/memorizing new words

Listen

As soon as you have learned basics, start listening to podcasts. There are some free audio podcasts oriented for beginners. For example, in Spanish, it’s a Notes in Spanish.

Create a playlist with up to 20 songs you like on language you learn and listen to them regularly. And keep listening until you will understand what a song about. You don’t have to translate all the words in each song. In fact, It is not very useful. But opposite, when you learn new words from textbook, tinycard or from anywhere else and you hear this word while you are listening to your playlist you learn better.

– Oh, wait. I know what this word means …

Watch

If you are fun of TV-shows, you can start watching them in the language you learn. With subtitles or without them. Of course, it requires some basic knowledge. If you care that you will miss some key points of the story and prefer to fully understand it, you can watch sitcoms which don’t have almost anything in common between series.

In this post, I will go through configuring Bitly OAuth2 proxy in a kubernetes cluster.

UPD 5/08/2025

There is a fresh tutorial about oauth2-proxy

A few days ago I was configuring SSO for our internal dev-services in KE Technologies.

And I spent the whole to make it work properly, and at the end I decided that I will share my experience by writing this post, hoping that it will help others(and possibly me in the future) to go through this process.

What do we want?

We have internal services in our k8s cluster that we want to be accessible for developers. It can be kubernetes-dashboard or kibana or anything else.

Before that we used Basic Auth, it’s easy to setup in ingresses. But this approach has several disadvantages:

1. We need to share a single pair of login and password for all services among all developers
2. Developers will be asked to enter credentials each time when they access service first time

What we want is that developer will log in once and will have access to all other services without additional authentication.

So, a possible scenario could be:

1. Developers open https://kibana.example.com which is internal service
2. Browser redirects them to https://auth.example.com where they sign in
3. After successful authentication browser redirects them to https://kibana.example.com

Preparation

Update

UPD 1.0(07/30/18)

Using kube-lego for configuring Let’s Encrypt certificates is depricated now. Consider using cert-manager instead.

UPD 2.0(08/24/18)

Initialy, when I was writing this post I was using old version of nginx 0.9.0, because it did not work correctly on newer version. Now, I found the problem and it have been fixed in 0.18.0 release. But ingress exposing private services should be updated(more details):

    nginx.ingress.kubernetes.io/auth-signin: https://auth.example.com/oauth2/start?rd=https://$host$request_uri$is_args$args

    nginx.ingress.kubernetes.io/auth-url: http://oauth2-proxy.oauth-proxy.svc.cluster.local:4180/oauth2/auth

Kubernetes

First of all, we need a Kubernetes cluster. I will use the newly created cluster in Google Cloud Platform with version 1.8.10-gke.0. If you have a cluster with configured ingress and https you can skip this step.

Then we need to install nginx ingress and kube lego. Let’s do it using helm:

Init helm

With RBAC:

# giving default accout admin role:
ACCOUNT=$(gcloud info --format='value(config.account)')

kubectl create clusterrolebinding owner-cluster-admin-binding \
    --clusterrole cluster-admin \
    --user $ACCOUNT


kubectl -n kube-system create sa tiller
kubectl create clusterrolebinding tiller --clusterrole cluster-admin --serviceaccount=kube-system:tiller
helm init --service-account tiller

without RBAC:

helm init

Install nginx-ingress

helm install stable/nginx-ingress --name nginx-ing --namespace nginx-ing \
    --set controller.image.repository=gcr.io/google_containers/nginx-ingress-controller \
    --set controller.image.tag="0.9.0-beta.15"
    --set rbac.create=true # if RBAC is enabled in the cluster
    # see all options here: https://github.com/kubernetes/charts/blob/master/stable/nginx-ingress/values.yaml

After it’s installed we can retrieve controller IP address:

kubectl --namespace nginx-ing get services -o wide -w nginx-ing-nginx-ingress-controller

and create DNS record to point our domain and subdomains to this IP address.

A       example.com     xxx.xxx.xx.xxx
CNAME   *.example.com   example.com

Install kube-lego

helm install --name kube-lego stable/kube-lego --namespace kube-lego \
    --set config.LEGO_SUPPORTED_INGRESS_CLASS=nginx \
    --set config.LEGO_SUPPORTED_INGRESS_PROVIDER=nginx \
    --set config.LEGO_DEFAULT_INGRESS_CLASS=nginx \
    --set config.LEGO_URL=https://acme-v01.api.letsencrypt.org/directory \
    --set rbac.create=true \
    --set image.tag=0.1.5 \
    --set config.LEGO_LOG_LEVEL=debug

Test it!

Let’s run simple HTTP server as service and expose it using nginx ingress:

kubectl run simple-http --image=strm/helloworld-http --port=80

kubectl expose deployment simple-http --name example-service --port=80 --target-port=80 --type=NodePort

example-ing.yaml

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: example
  annotations:
    kubernetes.io/ingress.class: nginx
    kubernetes.io/tls-acme: 'true'
spec:
  rules:
    - host: service.example.com
      http:
        paths:
          - backend:
              serviceName: example-service
              servicePort: 80
            path: /
  tls:
    - hosts:
        - "service.example.com"
      secretName: ing-tls

kubectl apply -f example-ing.yaml

Wait for a few seconds and open https://service.example.com and you should see something similar to this:

Example

GitHub application

In this post, we will use GitHub accounts for authentication.

So, go to https://github.com/settings/applications/new and create new OAuth application

Fill Authorization callback URL field with https://auth.example.com/oauth2/callback where example.com is your domain name.

GitHub Application

After creating an application you will have Client ID and Client Secret which we will need in next step.

Deploy OAuth Proxy

There are a lot of docker images for OAuth proxy, but we can not use them because they do not support domain white-listing. The problem is that such functionality has not implemented yet.

Actualy there are several PRs that solve that problem but seems to be they frozen for an unknown amount of time.

So, the only thing I could do is to merge one of the PRs to current master and build own image.

You also can use my image, but if you worry about security just clone my fork and build image yourself.

Let’s create a namespace and set it as current:

kubectl create ns oauth-proxy

kns oauth-proxy # I am using kubectx tool -> https://github.com/ahmetb/kubectx

Deploy secret

secret.yml

apiVersion: v1
kind: Secret
metadata:
  name: oauth-proxy-secret
  namespace: oauth-proxy
data:
  github-client-id: base64(YOUR_CLIENT_ID)
  github-client-secret: base64(YOUR_CLIENT_SECRET)
  cookie-secret: base64(random_string)

kubectl create -f secret.yml

Deploy deployment

oauth-proxy.deployment.yml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  labels:
    k8s-app: oauth2-proxy
  name: oauth2-proxy
  namespace: oauth-proxy
spec:
  replicas: 1
  selector:
    matchLabels:
      k8s-app: oauth2-proxy
  template:
    metadata:
      labels:
        k8s-app: oauth2-proxy
    spec:
      containers:
      - name: oauth2-proxy
        image: alikhil/oauth2_proxy:2.2.2
        imagePullPolicy: Always
        args:
        - --provider=github
        - --email-domain=*
        - --upstream=file:///dev/null
        - --http-address=0.0.0.0:4180
        - --whitelist-domain=.example.com
        - --cookie-domain=.example.com
        # - --cookie-expire duration: expire timeframe for cookie (default 168h0m0s)
        # - --cookie-name string: the name of the cookie that the oauth_proxy creates (default "_oauth2_proxy")
        # - --cookie-refresh duration: refresh the cookie after this duration; 0 to disable
        # - --cookie-secret string: the seed string for secure cookies (optionally base64 encoded)
        env:
        - name: OAUTH2_PROXY_CLIENT_ID
          valueFrom:
            secretKeyRef:
              name: oauth-proxy-secret
              key: github-client-id
        - name: OAUTH2_PROXY_CLIENT_SECRET
          valueFrom:
            secretKeyRef:
              name: oauth-proxy-secret
              key: github-client-secret
        - name: OAUTH2_PROXY_COOKIE_SECRET
          valueFrom:
            secretKeyRef:
              name: oauth-proxy-secret
              key: cookie-secret
        ports:
        - containerPort: 4180
          protocol: TCP

kubectl create -f oauth-proxy.deployment.yml

Deploy service

oauth-service.yml

apiVersion: v1
kind: Service
metadata:
  labels:
    k8s-app: oauth2-proxy
  name: oauth2-proxy
  namespace: oauth-proxy
spec:
  type: NodePort
  ports:
  - name: http
    port: 4180
    protocol: TCP
    targetPort: 4180
  selector:
    k8s-app: oauth2-proxy

kubectl create -f oauth-service.yml

Deploy ingress

oauth-ing.yml

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: oauth2-proxy
  namespace: oauth-proxy
  annotations:
    kubernetes.io/tls-acme: "true"
    kubernetes.io/ingress.class: "nginx"

spec:
  rules:
  - host: auth.example.com
    http:
      paths:
      - backend:
          serviceName: oauth2-proxy
          servicePort: 4180
        path: /oauth2
  tls:
  - hosts:
    - auth.example.com
    secretName: oauth-proxy-tls

kubectl create -f oauth-ing.yml

Test it!

You can update ingress that we used while configuring nginx-ingress or create a new one:

example-ing.yml

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: example
  annotations:
    kubernetes.io/ingress.class: nginx
    kubernetes.io/tls-acme: 'true'
    ingress.kubernetes.io/auth-url: https://auth.example.com/oauth2/auth
    ingress.kubernetes.io/auth-signin: https://auth.example.com/oauth2/start?rd=https://$host$request_uri$is_args$args
spec:
  rules:
    - host: service.example.com
      http:
        paths:
          - backend:
              serviceName: example-service
              servicePort: 80
            path: /
  tls:
    - hosts:
        - service.example.com
      secretName: ing-tls

kubectl apply -f example-ing.yml

Then visit service.example.com and you will be redirected to GitHub authorization page:

GitHub Authorization page

And once you authenticate, you will have access to all your services under ingress that point to auth.example.com until cookie expires.

And that’s it! Now you can put any of your internal services behind ingress with OAuth.

Resources

Here is a list of resources that helped me to go through this proccess first time:

• https://eng.fromatob.com/post/2017/02/lets-encrypt-oauth-2-and-kubernetes-ingress/
• https://www.midnightfreddie.com/oauth2-proxy.html
• https://thenewstack.io/single-sign-on-for-kubernetes-dashboard-experience/

There were only 2 posts in my last blog and I decided to not migrate the one about creating blog in Jekyll. Since it is not actual now.

In this tutorial, we will configure Go environment in VS Code and write our first program in Go.

Install Go

The first thing that you need to do it’s to install Go on your computer. To do so, download installer for your operating system from here and then run the installer.

Configure GOPATH

By language convention, Go developers store all their code in a single place called workspace. Go also puts dependency packages in the workspace. So, in order to Go perform correctly, we need to set GOPATH variable with the path to the workspace.

MacOS and Linux

Set the GOPATH envar with workspace

export GOPATH=$HOME/go

Also, we need to add GOPATH/bin to PATH in order to run compiler Go programs:

export PATH=$PATH:$GOPATH/bin

Configure VS Code

Install official Go extension.

Install delve debugger:

go get -u github.com/derekparker/delve/cmd/dlv

I recommend you to add the following lines to your VS Code user settings:

settings.json

{
    "go.autocompleteUnimportedPackages": true,
    "go.formatTool": "gofmt"
}

Windows

Create GOPATH envar:

set GOPATH=c:\Users\%USERNAME%\go

Also, we need to add GOPATH\bin to PATH in order to run compiler Go programs:

set PATH=%PATH%;%GOPATH%\bin

Create project

Move to your GOPATH/src directory. Create a directory for your project:

cd $GOPATH/src
mkdir -p github.com/alikhil/hello-world-with-go

Open it using vscode:

code github.com/alikhil/hello-world-with-go

Hello World

Let’s create a file named program.go and put the following code there:

program.go

package main

import "fmt"

func main() {
    fmt.Println("¡Hola, mundo!")
}

Run the program

Finally, to run the program by pressing the F5 button in VS Code and you should see the message printed to Debug Console.

That’s all! My congratulations, you have just written your first program in Go!

Troubleshooting

If you fail to run your program and there is some message like “Cannot find a path to go”. Try to add to your PATH envar with path directory where go binary is stored.

For example in MacOS I have added following line to my ~/.bash_profile:

export PATH=/usr/local/go/bin:$PATH