Two years ago, I made the transition from a Tech engineer in the Silicon Valley to a digital nomad roaming the world while working remotely. Here is how my journey to the digital nomad life began.
So long as my memory takes me, I always pictured myself that I would travel the world, experience new cultures and uncover new dimensions to life. I promised myself to fulfill this desire as soon as the opportunity allows.
After my graduation in 2015, I started out as a software engineer with a major tech company. Within my first year, my desire to travel was getting stronger by the day. Because I frequently looked up places to travel in my free time, a lot of ads were showing up about remote work packages whenever I surfed the internet. These programs were enticing because not only you get to travel with with a group of people for a year, but also hop from one country to another each month or so without having to worry about logistics. Since I wasn’t on a remote job, I couldn’t join any of these fully remote, duration-extended programs, but that didn’t prevent me from pursuing remote work every now and then. I took these rather short trips which were undoubtedly great, but if they did one thing, they invigorated my desire to travel and explore even more. …
If you’re using kubernetes in production, chances are you’re using a private registry to securely store your application images. There’s few ways on how to make those private images available for use in your cluster as mentioned by the official doc.
In this blog, we explain some of these options with examples:
First, create a pull secret with docker Credentials:
kubectl create secret docker-registry my-registry-cred \
--docker-server=[REGISTRY_URL] --docker-username=[REGISTRY_USERNAME] --docker-password=[REGISTRY_PASSWORD] --docker-email=[YOUR_EMAIL]
Alternatively you can create the secret from the docker config file directly:
kubectl create secret generic my-registry-cred \
Create a pod that uses the secret as shown…
Lately, with containers becoming the mainstream of packaging, shipping and running code for both stateless and stateful applications, the kubernetes community is trying to fill the gap of managing stateful apps alongside the stateless ones by improving the set of abstractions and features that deals with storage and stateful workloads and creating standards when dealing with storage and containers namely CSI or container storage interface.
In this blog, we will attempt to explain with examples the different storage options that exists currently in kubernetes by looking at the different abstractions it offers to manage storage and when and how you can use them to have an optimal experience managing state. …
If you have been using Kubernetes for a while, you probably know by now that Kubernetes does not offer any built in mechanism for defining and managing users. This means that Kubernetes does not store any reference to users or groups they belong to in its object store ETCD. This allows admins to integrate their organization identity service provider and for cloud providers to integrate their cloud identity service offering with the likes of Google Cloud identity and Microsoft AD to work with kubernetes and not having to recreate those users or manage them twice.
In this blog we will go over the details of how users are created with Google Kubernetes Engine — GKE and how Google Cloud IAM and RBAC play together to achieve a better authentication and authorization strategy for your cluster. …
With the emergence of containers and container orchestration systems such as Kubernetes, microservices architectures have become more and more prevalent. Because of this, many new sets of challenges have appeared. It is true that each microservice in itself is simpler, but the system as a whole is now more complex and difficult to manage. In this context, service mesh solutions were designed to tackle these issues. One such solution in particular stands out in the market: “Istio”.