How to get OpenEBS Mayastor clustered storage to work on microk8s? - microk8s

I have tried all sorts of things to get OpenEBS Mayastor clustered storage to work on microk8s without much success. So rather than give up completely I thought I would detail one of my failed attempts and see if anyone could figure out what I am doing wrong. Thanks in advance for any help you can give me :-)
Failed Attempt
Here is the results of following the steps posted on at https://microk8s.io/docs/addon-mayastor.
VM Setup:
3 VM running Ubuntu 22.04 with 16GB ram on a vSphere hypervisor. I have used these same VM to create a 3 node microk8s cluster with good success in the past.
Microk8s removal:
removed microk8s on all 3 nodes.
microk8s stop
sudo snap remove microk8s --purge
sudo reboot
Microk8s fresh install:
https://microk8s.io/docs/setting-snap-channel
snap info microk8s
latest/stable: v1.26.0 2022-12-17 (4390) 176MB classic
On all 3 nodes:
sudo snap install microk8s --classic --channel=1.26/stable
sudo usermod -a -G microk8s $USER
sudo chown -f -R $USER ~/.kube
newgrp microk8s
sudo reboot
verify everything is ok
microk8s status
microk8s inspect
**Do what inspect tells you to do:**
WARNING: IPtables FORWARD policy is DROP. Consider enabling traffic forwarding with: sudo iptables -P FORWARD ACCEPT
The change can be made persistent with: sudo apt-get install iptables-persistent
sudo iptables -S
sudo iptables-legacy -S
sudo iptables -P FORWARD ACCEPT
sudo apt-get install iptables-persistent
sudo systemctl is-enabled netfilter-persistent.service
sudo reboot
microk8s inspect
still get the IPtable FORWARD warning on 2 of the 3 nodes.
hopefully it is not that important.
ping all the ip addresses in cluster from every node.
Followed the directions at https://microk8s.io/docs/addon-mayastor
step 1:
sudo sysctl vm.nr_hugepages=1024
echo 'vm.nr_hugepages=1024' | sudo tee -a /etc/sysctl.conf
sudo nvim /etc/sysctl.conf
step 2:
sudo apt install linux-modules-extra-$(uname -r)
sudo modprobe nvme_tcp
echo 'nvme-tcp' | sudo tee -a /etc/modules-load.d/microk8s-mayastor.conf
sudo nvim /etc/modules-load.d/microk8s-mayastor.conf
step 3:
microk8s enable dns
microk8s enable helm3
thought we might need rbac so I enabled that also.
microk8s enable rbac
Created 3 node cluster.
from main node.
sudo microk8s add-node
go to 2nd node.
microk8s join 10.1.0.116:25000/0c902af525c13fbfb5e7c37cff29b29a/acf13be17a96
from main node.
sudo microk8s add-node
go to 3rd node.
microk8s join 10.1.0.116:25000/36134181872079c649bed48d969a006d/acf13be17a96
microk8s status
enable the mayastor add-on:
from main node.
sudo microk8s enable core/mayastor --default-pool-size 20G
go to 2nd node.
sudo microk8s enable core/mayastor --default-pool-size 20G
Addon core/mayastor is already enabled
go to 3rd node.
sudo microk8s enable core/mayastor --default-pool-size 20G
Addon core/mayastor is already enabled
Wait for the mayastor control plane and data plane pods to come up:
sudo microk8s.kubectl get pod -n mayastor
NAME READY STATUS RESTARTS AGE
mayastor-csi-962jf 0/2 ContainerCreating 0 2m6s
mayastor-csi-l4zxx 0/2 ContainerCreating 0 2m5s
mayastor-8pcc4 0/1 Init:0/3 0 2m6s
msp-operator-74ff9cf5d5-jvxqb 0/1 Init:0/2 0 2m5s
mayastor-lt8qq 0/1 Init:0/3 0 2m5s
etcd-operator-mayastor-65f9967f5-mpkrw 0/1 ContainerCreating 0 2m5s
mayastor-csi-6wb7x 0/2 ContainerCreating 0 2m5s
core-agents-55d76bb877-8nffd 0/1 Init:0/1 0 2m5s
csi-controller-54ccfcfbcc-m94b7 0/3 Init:0/1 0 2m5s
mayastor-9q4gl 0/1 Init:0/3 0 2m5s
rest-77d69fb479-qsvng 0/1 Init:0/2 0 2m5s
# Still waiting
sudo microk8s.kubectl get pod -n mayastor
NAME READY STATUS RESTARTS AGE
mayastor-8pcc4 0/1 Init:0/3 0 32m
msp-operator-74ff9cf5d5-jvxqb 0/1 Init:0/2 0 32m
mayastor-lt8qq 0/1 Init:0/3 0 32m
core-agents-55d76bb877-8nffd 0/1 Init:0/1 0 32m
csi-controller-54ccfcfbcc-m94b7 0/3 Init:0/1 0 32m
mayastor-9q4gl 0/1 Init:0/3 0 32m
rest-77d69fb479-qsvng 0/1 Init:0/2 0 32m
mayastor-csi-962jf 2/2 Running 0 32m
mayastor-csi-l4zxx 2/2 Running 0 32m
etcd-operator-mayastor-65f9967f5-mpkrw 1/1 Running 1 32m
mayastor-csi-6wb7x 2/2 Running 0 32m
etcd-6tjf7zb9dh 0/1 Init:0/1 0 30m
Went to the trouble-shooting section at https://microk8s.io/docs/addon-mayastor
microk8s.kubectl logs -n mayastor daemonset/mayastor
output was:
Found 3 pods, using pod/mayastor-8pcc4
Defaulted container "mayastor" out of: mayastor, registration-probe (init), etcd-probe (init), initialize-pool (init)
Error from server (BadRequest): container "mayastor" in pod "mayastor-8pcc4" is waiting to start: PodInitializing

Related

Cannot deploy basic OpenWhisk action onto Kubernetes running with Minikube

I am trying to setup a simple POC of Apache OpenWhisk serverless framework running on Kubernetes. I am using MacOS with Minikube. Here are the specs:
Kubernetes: v1.20.2
Minikube: v1.17.0
Docker: 20.10.0-rc1, 4.26GB allocated
Here are the setup steps for Minikube:
$ minikube start --cpus 2 --memory 4096 --kubernetes-version=v1.20.2
$ minikube ssh -- sudo ip link set docker0 promisc on
$ kubectl create namespace openwhisk
$ kubectl label nodes --all openwhisk-role=invoker
Install OpenWhisk using Helm:
$ helm install owdev ./helm/openwhisk -n openwhisk --create-namespace -f mycluster.yaml
Configure Whisk CLI:
$ wsk property set --apihost 192.168.49.2:31001
$ wsk property set --auth 23bc46b1-71f6-4ed5-8c54-816aa4f8c502:123zO3xZCLrMN6v2BKK1dXYFpXlPkccOFqm12CdAsMgRU4VrNZ9lyGVCGuMDGIwP
The 192.168.49.2 IP address of Minikube was confirmed by typing:
$ minikube ip
Here is my mycluster.yaml file:
whisk:
ingress:
type: NodePort
apiHostName: 192.168.49.2
apiHostPort: 31001
nginx:
httpsNodePort: 31001
I checked the health of my OpenWhisk setup:
$ kubectl get pods -n openwhisk
NAME READY STATUS RESTARTS AGE
owdev-alarmprovider-5b86cb64ff-q86nj 1/1 Running 0 137m
owdev-apigateway-bccbbcd67-7q2r8 1/1 Running 0 137m
owdev-controller-0 1/1 Running 13 137m
owdev-couchdb-584676b956-7pxtc 1/1 Running 0 137m
owdev-gen-certs-7227t 0/1 Completed 0 137m
owdev-init-couchdb-g6vhb 0/1 Completed 0 137m
owdev-install-packages-sg2f4 1/1 Running 0 137m
owdev-invoker-0 1/1 Running 1 137m
owdev-kafka-0 1/1 Running 0 137m
owdev-kafkaprovider-5574d4bf5f-vvdb9 1/1 Running 0 137m
owdev-nginx-86749d59cb-mxxrt 1/1 Running 0 137m
owdev-redis-d65649c5b-vd8d4 1/1 Running 0 137m
owdev-wskadmin 1/1 Running 0 137m
owdev-zookeeper-0 1/1 Running 0 137m
wskowdev-invoker-00-13-prewarm-nodejs10 1/1 Running 0 116m
wskowdev-invoker-00-14-prewarm-nodejs10 1/1 Running 0 116m
wskowdev-invoker-00-15-whisksystem-invokerhealthtestaction0 1/1 Running 0 112m
Finally, I created a simple hello world action following these instructions taken directly from the OpenWhisk documentation. When I try to test the action, I get a network timeout:
$ wsk action create helloJS hello.js
error: Unable to create action 'helloJS': Put "https://192.168.49.2:31001/api/v1/namespaces/_/actions/helloJS?overwrite=false": dial tcp 192.168.49.2:31001: i/o timeout
I tried turning on debug mode with the -d switch, but could not make much of what feedback I am seeing.
My feeling is that there is either a bug at work here, or perhaps Minikube on Mac was never intended to be fully supported on OpenWhisk.
Can anyone suggest what I might try to get this setup and action working?
We stopped maintaining OpenWhisk for Minikube a while ago. With the availability of a full-fledged Kubernetes cluster built-in to Docker Desktop on MacOS and Windows and kind (https://kind.sigs.k8s.io) being available on all of our platforms supporting Minikube was more work than it was worth.
Wait until the pod (starting with the name owdev-install-packages-) packages completes.
This may take some time, after that it should work.

Istio: how do I setup HTTPS traffic between services on Minikube?

I'm currently learning Istio and ran into a problem while trying to setup set up HTTPS traffic between containers on a local Minikube test cluster.
There are some related tasks in the Istio docs. Particularly the https-overlay task. I managed to execute the first subtask (without sidecar on the querying container), but the second one fails with the following error when issuing a request to the nginx deployment from the sleep pod:
$ kubectl exec $(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name}) -c sleep -- curl https://my-nginx -k
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
curl: (35) error:1401E410:SSL routines:CONNECT_CR_FINISHED:sslv3 alert handshake failure
command terminated with exit code 35
I assume my setup is at fault but I can't really tell what's wrong (or how to debug). Can someone have a look and suggest a fix?
Setup steps are given below under Setup. Environment specs are shown below.
Environment
OS
macOS 10.13.6
kubectl version
$ kubectl version
Client Version: version.Info{Major:"1", Minor:"12", GitVersion:"v1.12.3", GitCommit:"435f92c719f279a3a67808c80521ea17d5715c66", GitTreeState:"clean", BuildDate:"2018-11-27T01:15:02Z", GoVersion:"go1.11.2", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.0", GitCommit:"fc32d2f3698e36b93322a3465f63a14e9f0eaead", GitTreeState:"clean", BuildDate:"2018-03-26T16:44:10Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}
minikube version:
$ minikube version
minikube version: v0.31.0
Setup
$ISTIO_HOME should point to the location of the Istio installation.
1. Run Minikube + Istio Startup Script
Warning: This will stop and delete a running minikube instance.
#! /bin/bash
minikube stop;
minikube delete;
minikube start \
--memory=8192 \
--cpus=4 \
--kubernetes-version=v1.10.0\
--vm-driver=virtualbox;
kubectl apply -f $ISTIO_HOME/install/kubernetes/helm/istio/templates/crds.yaml
kubectl apply -f $ISTIO_HOME/install/kubernetes/istio-demo.yaml
# Set docker registry to minikube registry
eval $(minikube docker-env);
2. Run HTTPS Test Setup Script
Wait until the Istio pods are either running or completed and then
#! /bin/bash
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /tmp/nginx.key -out /tmp/nginx.crt -subj "/CN=my-nginx/O=my-nginx"
kubectl create secret tls nginxsecret --key /tmp/nginx.key --cert /tmp/nginx.crt
kubectl create configmap nginxconfigmap --from-file=$ISTIO_HOME/samples/https/default.conf
kubectl apply -f <(istioctl kube-inject -f $ISTIO_HOME/samples/https/nginx-app.yaml)
kubectl apply -f <(istioctl kube-inject -f $ISTIO_HOME/samples/sleep/sleep.yaml)
3. Issue Request To Nginx From Sleep Pod
Wait for both pods to start running and then run
kubectl exec $(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name}) -c sleep -- curl https://my-nginx -k
According to the subtask description, we should see the nginx landing page, but instead the error shown above (exit code 35, handshake failure) is returned.
It seems that you are hitting this bug https://github.com/istio/istio/issues/7844 which is still open

Kubernetes service unreachable from master node on EC2

I created a k8s cluster on AWS, using kubeadm, with 1 master and 1 worker following the guide available here.
Then, I started 1 ElasticSearch container:
kubectl run elastic --image=elasticsearch:2 --replicas=1
And it was deployed successfully on worker. Then, I try to expose it as a service on cluster:
kubectl expose deploy/elastic --port 9200
And it was exposed successfully:
NAMESPACE NAME READY STATUS RESTARTS AGE
default elastic-664569cb68-flrrz 1/1 Running 0 16m
kube-system etcd-ip-172-31-140-179.ec2.internal 1/1 Running 0 16m
kube-system kube-apiserver-ip-172-31-140-179.ec2.internal 1/1 Running 0 16m
kube-system kube-controller-manager-ip-172-31-140-179.ec2.internal 1/1 Running 0 16m
kube-system kube-dns-86f4d74b45-mc24s 3/3 Running 0 17m
kube-system kube-flannel-ds-fjkkc 1/1 Running 0 16m
kube-system kube-flannel-ds-zw4pq 1/1 Running 0 17m
kube-system kube-proxy-4c8lh 1/1 Running 0 17m
kube-system kube-proxy-zkfwn 1/1 Running 0 16m
kube-system kube-scheduler-ip-172-31-140-179.ec2.internal 1/1 Running 0 16m
NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
default elastic ClusterIP 10.96.141.188 <none> 9200/TCP 16m
default kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 17m
kube-system kube-dns ClusterIP 10.96.0.10 <none> 53/UDP,53/TCP 17m
NAMESPACE NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
kube-system kube-flannel-ds 2 2 2 2 2 beta.kubernetes.io/arch=amd64 17m
kube-system kube-proxy 2 2 2 2 2 <none> 17m
NAMESPACE NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
default elastic 1 1 1 1 16m
kube-system kube-dns 1 1 1 1 17m
NAMESPACE NAME DESIRED CURRENT READY AGE
default elastic-664569cb68 1 1 1 16m
kube-system kube-dns-86f4d74b45 1 1 1 17m
But, when I try to execute a curl to http://10.96.141.188:9200 (from the master node) I'm getting a timeout, and everything indicates that the generated cluster IP is not reachable from the master node. It's working only on worker node.
I tried everything I could found:
Add a bunch of rules to iptables
iptables -P FORWARD ACCEPT
iptables -I FORWARD 1 -i cni0 -j ACCEPT -m comment --comment "flannel subnet"
iptables -I FORWARD 1 -o cni0 -j ACCEPT -m comment --comment "flannel subnet"
iptables -t nat -A POSTROUTING -s 10.244.0.0/16 ! -d 10.244.0.0/16 -j MASQUERADE
Disable firewalld
Enable all ports on ec2 security policy (from everywhere)
Use different docker versions (1.13.1, 17.03, 17.06, 17.12)
Different k8s versions (1.9.0 ~1.9.6)
Differents CNI (flannel and weave)
Add some parameters to kubeadm init command (--node-name with FQDN and --apiserver-advertise-address with public master IP)
But none of this worked. It appears that is a specific issue on AWS, since the tutorial guide works fine on Linux Academy Cloud Server.
Is there anything else I could try?
Obs:
Currently, I'm using docker 1.13 and k8s 1.9.6 (with flannel 0.9.1) on Centos7.
I finally found the problem. According to this page, Flannel needs to open ports UDP 8285 and 8472 on both Master and Worker node. It's interesting that this is not mentioned at official kubeadm documentation.
kubectl run elastic --image=elasticsearch:2 --replicas=1
As best I can tell, you did not inform kubernetes that the elasticsearch:2 image listens on any port(s), which it will not infer by itself. You would have experienced the same problem if you had just run that image under docker without similarly specifying the --publish or --publish-all options.
Thus, when the ClusterIP attempts to forward traffic from port 9200 to the Pods matching its selector, those packets fall into /dev/null because the container is not listening for them.
Add a bunch of rules to iptables
Definitely don't do that; if you observed, there are already a ton of iptables rules that are managed by kube-proxy: in fact, its primary job in life is to own the iptables rules on the Node upon which it is running. Your rules only serve to confuse both kube-proxy as well as any person who follows along behind you, trying to work out where those random rules came from. If you haven't already made them permanent, then either undo them or just reboot the machine to flush those tables. Leaving your ad-hoc rules in place will 100% not make your troubleshooting process any easier.

Worker nodes not available

I have setup and installed IBM Cloud private CE with two ubuntu images in Virtual Box. I can ssh into both images and from there ssh into the others. The ICp dashboard shows only one active node I was expecting two.
I explicitly ran the command (from a root user on master node):
docker run -e LICENSE=accept --net=host \
-v "$(pwd)":/installer/cluster \
ibmcom/cfc-installer install -l \
192.168.27.101
The result of this command seemed to be a successful addition of the worker node:
PLAY RECAP *********************************************************************
192.168.27.101 : ok=45 changed=11 unreachable=0 failed=0
But still the worker node isn't showing in the dashboard.
What should I be checking to ensure the worker node will work for the master node?
If you're using Vagrant to configure IBM Cloud Private, I'd highly recommend trying https://github.com/IBM/deploy-ibm-cloud-private
The project will use a Vagrantfile to configure a master/proxy and then provision 2 workers within the image using LXD. You'll get better density and performance on your laptop with this configuration over running two full Virtual Box images (1 for master/proxy, 1 for the worker).
You can check on your worker node with following steps:
check cluster nodes status
kubectl get nodes to check status of the newly added worker node
if it's NotReady, check kubelet log if there is error message about why kubelet is not running properly:
ICp 2.1
systemctl status kubelet
ICp 1.2
docker ps -a|grep kubelet to get kubelet_containerid,
docker logs kubelet_containerid
Run this to get the kubectl working
ln -sf /opt/kubernetes/hyperkube /usr/local/bin/kubectl
run the below command to identified failed pods if any in the setup on the master node.
Run this to get the pods details running in the environment
kubectl -n kube-system get pods -o wide
for restarting any failed pods of icp
txt="0/";ns="kube-system";type="pods"; kubectl -n $ns get $type | grep "$txt" | awk '{ print $1 }' | xargs kubectl -n $ns delete $type
now run the kubectl cluster-info
kubectl get nodes
Then ckeck the cluster info command of kubectl
Check kubectl version is giving you https://localhost:8080 or https://masternodeip:8001
kubectl cluster-info
Do you get the output
if no..
then
login to https://masternodeip:8443 using admin login
and then copy the configure clientcli settings by clicking on admin on the panel
paste it in ur master node.
and run the
kubectl cluster-info

Kubernetes Installation with Vagrant & CoreOS and insecure Docker registry

I have followed the steps at https://coreos.com/kubernetes/docs/latest/kubernetes-on-vagrant.html to launch a multi-node Kubernetes cluster using Vagrant and CoreOS.
But,I could not find a way to set an insecure docker registry for that environment.
To be more specific, when I run
kubectl run api4docker --image=myhost:5000/api4docker:latest --replicas=2 --port=8080
on this set up, it tries to get the image thinking it is a secure registry. But, it is an insecure one.
I appreciate any suggestions.
This is how I solved the issue for now. I will add later if I can automate it on Vagrantfile.
cd ./coreos-kubernetes/multi-node/vagrant
vagrant ssh w1 (and repeat these steps for w2, w3, etc.)
cd /etc/systemd/system/docker.service.d
sudo vi 50-insecure-registry.conf
add below line to this file
[Service]
Environment=DOCKER_OPTS='--insecure-registry="<your-registry-host>/24"'
after adding this file, we need to restart the docker service on this worker.
sudo systemctl stop docker
sudo systemctl daemon-reload
sudo systemctl start docker
sudo systemctl status docker
now, docker pull should work on this worker.
docker pull <your-registry-host>:5000/api4docker
Let's try to deploy our application on Kubernetes cluster one more time.
Logout from the workers and come back to your host.
$ kubectl run api4docker --image=<your-registry-host>:5000/api4docker:latest --replicas=2 --port=8080 —env="SPRING_PROFILES_ACTIVE=production"
when you get the pods, you should see the status running.
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
api4docker-2839975483-9muv5 1/1 Running 0 8s
api4docker-2839975483-lbiny 1/1 Running 0 8s

Resources