abhioncbr

Apache Superset in the production environment

Visualising data helps in building a much deeper understanding of the data and fastens analytics around the data. There are several mature paid products available in the market. Recently, I explored an open-source product name Apache-Superset which I found a very upbeat product in this space. Some prominent features of Superset are:

• A rich set of data visualisations
• An easy-to-use interface for exploring and visualising data
• Create and share dashboards

After reading about Superset, I wanted to try it, and as Superset is a python programming language based project, we can easily install it using pip, but I decided to set it up as a container based on Docker. Apache-Superset GitHub Repo contains code for building and running Superset as a container. Since I wan

abhioncbr

A couple of days back, I wrote the post about how to run Apache Superset in the production environment for serving hundreds or thousands of users. Superset community members and users appreciated the post for which I am thankful to them, however over the Superset Slack and Gitter channels; many users asked various questions on setting Superset as a Docker container and how to use/run it. In this post, I am trying to explore more about docker image of a Superset, and I am hoping that after reading the post you will acquire a conceptual understanding of setting Superset as a Docker container and benefits of it.

Container Image

abhioncbr

It was the second day of the long weekend; I was watching Money Heist on Netflix (a good one to watch, free recommendation by a human), and in-between, I got the slack notification on one channel, "Is something wrong with our application?" By the time I will start my MacBook to check, another slack message "application is not running, pod status says Evicted." Luckily, the application was in a pre-prod environment, but we want pod up & running. It looks like an effortless task; restart the pod, right? We did, pod evicted again in some time. The application code was simple and shouldn't be consuming many resources of the K8s cluster. Frankly, before this, we haven't encountered such an issue, and we weren't sure about the solution, and there start a saga of pod eviction resolution. Eviction is a complex topic, many factors, objects and policies involved; Let's get started with basics and slowly building the related corresponding concepts. In this first post, I am targeting to cover the pod phase, status,

abhioncbr

We together covered a handful of concepts in the last three posts about knowing, conceptualizing, and understanding pod eviction. As I said, in my first post that it's a complicated topic, and I would like to suggest that if you are reading this post first, please read all the below-listed posts before reading this one.

• Please don't evict my pod; QoS class
• Please don't evict my pod; eviction policy
• Please don't evict my pod; priority & disruption budget
• The current one, Please don't evict my pod; tips & tricks to avoid eviction.

Although I highly recommend to go through the posts as mentioned earlier but still, for the time-sake or as a refresher, we are going to revisit the concepts quickly; please feel free to skip the section if you already went over the posts or have a fai

abhioncbr

Again, like last time, I am starting this post by acknowledging & thanking the appreciation for my previous posts on pod-eviction. This post is the third one on pod eviction.

• Please don’t evict my pod; QoS class.
• Please don’t evict my pod; eviction policy.
• The current one, Please don’t evict my pod; priority & disruption budget.

In this post, we are going to cover the pod priority class, pod disruption budget, DaemonSet and the relationship of these constructs with pod eviction. Okay, enough of talking, let’s start with pod priority class.

PriorityClass and Preemption

PriorityClass is a stable Kubernetes object from version 1.14, and it is a part of the scheduling group used for defining a mapping between priority class name, and the integer value of the

abhioncbr

I will start this post by acknowledging the appreciation for my last post; This post is in continuation to my previous post, here is the list of post.

• Please don't evict my pod; QoS class.
• The current one, Please don't evict my pod; eviction policy

Let's first quickly revisit the understanding from the last post; pod QoS class determines which pod will remove first from a node in-case of eviction by Kubelet. There are three types of QoS classes, i.e. Best Effort, Burstable & Guaranteed and among them Best Effort pods will evict first, following Burstable pods second and at last the Guaranteed one.

In this post, we are going to cover node resources, what causes eviction, what are soft and hard threshold signals. Let's start with node resources.

Node resources

abhioncbr

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
namespace: istio-system
name: demo-istiocontrolplane
spec:
profile: demo
components:
    egressGateways:
    - name: istio-egressgateway

abhioncbr

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
    - operator-generated-manifest.yaml
    - istio-generated-manifest.yaml
images:
    - name: docker.io/istio/operator
      newName: private-repo/istio/operator
      newTag: 1.6.5

abhioncbr

# istioctl istio-operator dump manifests 
istioctl operator dump [--hub(optional)] > operator-generated-manifest.yaml

# generate the manifest before installing Istio
istioctl manifest generate > istio-generated-manifest.yaml

# apply generated manifests
kubectl apply -f operator-generated-manifest.yaml
kubectl apply -f istio-generated-manifest.yaml

abhioncbr

# istioctl istio-operator dump manifests 
istioctl operator dump [--hub(optional)] > operator-generated-manifest.yaml

# generate the manifest before installing Istio
istioctl manifest generate > istio-generated-manifest.yaml

# apply generated manifests
kubectl apply -f operator-generated-manifest.yaml
kubectl apply -f istio-generated-manifest.yaml