Articles, notes and random thoughts on Software Development and Technology
There was a vulnerability found today in some older Kubernetes versions. There are already patched versions available. If you have 1.11.3 installed from rke, you can update to 1.11.5 by editing your cluster.yml, replacing the kubernetes image:
kubernetes: rancher/hyperkube:v1.11.3-rancher1with
kubernetes: rancher/hyperkube:v1.11.5-rancher1And then run ‘rke up’ again.
This is from this Github ticket.
Rancher’s RKE is a Kubernetes cluster installer – see more here.
Pre-reqs:
Notes using Ubuntu 16.04 server.
Remove prior Docker installs:
sudo apt-get remove docker docker-engine docker.ioCreate docker group and add user to docker group:
sudo groupadd docker
usermod -aG docker <user_name>
Install per Docker CE install steps here, or use the Rancher provider install script here.
Supported Docker versions for RKE (as of Dec 2018) are: 1.11.x 1.12.x 1.13.x 17.03.x
Configure Docker daemon to listen for incoming requests on 2376, as per steps here.
Using ‘rke config’ with the default/minimal cluster.yml here, and then install/setup with ‘rke up’
If you didn’t change the name of the cluster.yml file, after the install is complete, you’ll have a kube_config_cluster.yml file in the same dir which you can use with kubectl to interact with you cluster, or add it into your existing ~/.kube/config file
I have a test Kubernetes cluster running with a CentOS7 master nodes, and 4 CentOS7 worker nodes, under VMware ESXi. The ip addresses of each of the VMs is from DHCP, and as I hadn’t booted these VMs for a while, when I recently started them up they all got new IP addresses, so the cluster would not start up, and all the .kube/config files were now referring to incorrect IP addresses. Note to self – this is a good reason why you should use DNS names for the nodes in your cluster instead of ip addresses, especially IP addresses that can change.
Anyway, to restore my cluster back to a working state, I reinitialized the master node, and the joined the workers to the new master.
First on the master:
sudo kubeadm reset
sudo kubeadm init --pod-network-cidr=10.244.0.0/16
#take a copy of the kubeadm join command to run on the workers
#copy kube config for local kubectl
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
#apply networking overlay
kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/v0.8.0/Documentation/kube-flannel.yml
kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/v0.8.0/Documentation/kube-flannel-rbac.yml
#for each of the worker nodes, scp the config file to each node for local kubectl use
scp /etc/kubernetes/admin.conf kev@192.168.1.86:~/.kube/config
On each of the worker nodes:
sudo kubeadm reset
#then run the kubeadm join command shown from the master when you ran kubeadm init
You can read books, watch YouTubes and listen to as many podcast as you like, but the best way to learn anything new in software development is to try it out for yourself. Why? Because you’ll learn far more from the hands-on experimentation with a new tech/library/api when you try to use it that can ever be transferred as knowledge and experience from a single book/video/article/podcast. What you can learn from a single 1 hour podcast can give you a high level overview of a topic, but you can never learn as much as you will from trying it our yourself.
Part of the learning experience is working out how to solve the problems you run into. The ‘huh, it never said that in the manual’ experience. Once you’ve worked through the unexpected issues along the way, you’ll have built a much deeper understanding of what it actually takes to use a new technology. It’s where the rubber meets the road that counts.