DEV Community: Dinesh B

Which scheduler scheduled the scheduler in minikube ?

Dinesh B — Wed, 25 Dec 2019 14:37:08 +0000

In oneliner, minikube is a tool that makes it easy to run Kubernetes locally.

In kube-system namespace, we can see result like below,

$ kubectl get pods -n kube-system -o name -l tier=control-plane
pod/etcd-minikube
pod/kube-apiserver-minikube
pod/kube-controller-manager-minikube
pod/kube-scheduler-minikube #scheduler is running, but who scheduled ?

Whenever we create pod(rs/deployments/sts/ds), Scheduler is the one which schedules this pods into any of the available node (in minikube, there is only one).
In minikube, kube-scheduler-minikube is the one who schedules. For long time, I wondered who scheduled the kube-scheduler-minikube pod to this minikube node. I assumed it as magic 🤪

Now, I understood how things are happening, here you go:

There is something called static pods in kubernetes. Without master components (api-server, etcd, scheduler, controller-manager), we can run pods in kubelet directly. Minikube used this to run master components and thus formed the cluster.

Proof:

$ minikube ssh
$ ps aux | grep kubelet
root      3035  3.9  4.6 1377692 91476 ?       Ssl  07:27   0:06 /var/lib/minikube/binaries/v1.15.2/kubelet --authorization-mode=Webhook --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --cgroup-driver=cgroupfs --client-ca-file=/var/lib/minikube/certs/ca.crt --cluster-dns=10.96.0.10 --cluster-domain=cluster.local --config=/var/lib/kubelet/config.yaml --container-runtime=docker --hostname-override=minikube --kubeconfig=/etc/kubernetes/kubelet.conf --node-ip=192.168.99.100 --pod-manifest-path=/etc/kubernetes/manifests

In the above example, kubelet is started with --pod-manifest-path=/etc/kubernetes/manifests

Note: --pod-manifest-path is path to the directory containing static pod files to run.

$ ls -l /etc/kubernetes/manifests
-rw-r----- 1 root root 1532 Jan  1  0001 addon-manager.yaml.tmpl
-rw------- 1 root root 1990 Dec 25 07:27 etcd.yaml
-rw------- 1 root root 2893 Dec 25 07:27 kube-apiserver.yaml
-rw------- 1 root root 2262 Dec 25 07:27 kube-controller-manager.yaml
-rw------- 1 root root  990 Dec 25 07:27 kube-scheduler.yaml

Thus when kubelet started, it started the master components and thus cluster formed.

Resolve vs Reach

Dinesh B — Thu, 12 Dec 2019 16:48:10 +0000

I have seen lot of people confuse between resolving dns vs reach IP. So this small blog.

Inorder to get data from any computer we need to know the address of the computer which is IP address. Let's say we want to get some data from google and its IP is 172.217.31.196 (currently). Its very hard to remember this IP and also they can have multiple machines(IPs) which will give the same data (horizontal scaling). So we cannot remember IPs. So we need a map (key: name, value: IP) stored in a server called DNS whose IP is configured automatically (done by DHCP server) when we connect to internet (8.8.8.8 or 1.1.1.1 or your custom dns server).

So when we do www.google.com in browser

1) Check which dns server to use in `/etc/resolve.conf`
2) Use that dns server to get the `ip address` of www.google.com
3) Use that IP address to connect and transfer data

First two steps is resolve and third step is reach.

Example:

Let's say we have private network and to access machines inside that network, we have to connect to the VPN. There is an application running in that network in machine 172.11.11.11. We can add entry in dns. Key is www.myapplication.com and value is 172.11.11.11. Once that is done, anybody can resolve www.myapplication.com to 172.11.11.11 as we added entry in public dns server. But it is reachable only to people who are connected to the VPN.
Let's say I want to expose/transfer some data to my colleagues. And my ip is 192.168.1.4 which is private and will be accessible only to the people whose is in my network. Instead of asking my colleagues to use this IP, we can put an entry in public DNS server (8.8.8.8 or 1.1.1.1). Key is www.dineshba.com and value is 192.168.1.4. Once that is done, anybody can resolve www.dineshba.com to 192.168.1.4 as we added entry in public dns server. But it is reachable only to people in my network.

How I am using fzf for every 5 min of my programming life

Dinesh B — Wed, 21 Aug 2019 03:52:48 +0000

Installation for new users

$ brew install fzf
$ $(brew --prefix)/opt/fzf/install # useful key bindings and fuzzy completion

Note: Its better to use key bindings and fuzzy completion

Default options that I use

export FZF_DEFAULT_OPTS='--height 40% --reverse --border'

My usages

To Search in command history:

CTRL + R

To Change directory:

cd + (CTRL + T) # type cd and then press CTRL plus T
or
cd ** + TAB

To find and open files in vim(or any editor):

vim $(fzf)
vim + (CTRL + T)
vim ** + TAB
vim $(fzf --preview 'cat {}')

You can even search and open multiple files using tab

To kill a process:

kill + TAB

Note: Think about the normal way. We have to ps aux to list processes and grep the required process then copy the correct column for pid, then call kill. Here just one step.

To ssh into a machine:

ssh ** + TAB

To get the glimse of a file

fzf --preview 'cat {}'

Extensibility

Fzf's usage is limitless. We can use it wherever we want to search and select one(or many) from a list

Case 1:

How will you jump to different directory?
- cd /path/to/your/project/path/to/your/service

Fzf way:

alias goproject="cd $(find path/to/your/project -type d -maxdepth 2 | fzf)"
goproject

You can have multiple alias for multiple projects or directories

Case 2:

How will you switch git branch? (select one branch from many)
    - git branch -a
    - copy the branch name
    - git checkout $new_branch_name
    or
    - git checkout + TAB (auto completion feature)

    Both the above approches are not O(1) :-P. How can we optimize?

Fzf way:

alias gcx="git checkout \$(git branch -a | sed 's/remotes\/origin\///' | grep -v '\*|HEAD' | sort |uniq | fzf --select-1)"
gcx

Note: try in your terminal and feel the difference

Case 3:

How will you tmux workspaces? We are using tmuxp tool to do that.
- tmuxp load workspace_name
or
- tmuxp load ~/.tmuxp/workspace_name.yaml

First involes rembembering all workspace_names (Space Complexity != O(1)) and type correct and fastly (Time Complexity != O(1)). Second involes lot of TABs or searching from commit history (Time Complexity != O(1))

Fzf way:

alias ktx='tmuxp load $(ls ~/.tmuxp/*.yaml | grep ".*/.tmuxp/" -r "" | grep "\.yaml" -r "" | fzf) --yes'

Case 4:

Okay we created tmux workspaces easily using Case 3. How will kill tmux workspaces now?
- tmux kill-session workspace_name

Fzf way:

$ alias tkill="for s in \$(tmux list-sessions | awk '{print \$1}' | rg ':' -r '' | fzf -m); do tmux kill-session -t \$s; done;"
$ tkill

Note: We are giving fzf -m which means we can select multiple and pass to next stage (basically killing multiple sessions)

Other tools which use fzf effectively

kubectx
kubens
lazy-connect
may be your tool

replace grep with rg for better experience

Summary:

Wherever we want search and select one/many from a list, then we can use fzf. So the options to use is limitless. If you are using fzf in a different way, please raise an issue or a PR here so that we can learn that. Thanks.