Trying to use DaemonSet with K8s 1.1.2. I get the following error:
$ kubectl create -f node-monitor-ds.yaml
Error from server: error when creating "node-monitor-ds.yaml": DaemonSet in version extensions/v1beta1 cannot be handled as a DaemonSet: json: cannot unmarshal object into Go value of type string
Testing a K8s pod mounting a CephFS export subdirectory:
Define the test Pod:
This pod executes the “pause” container so I have time to log in and verify the mount is correct. In the “cephfs” volume definition you can see the attribute path: “/Media” which specifies that as the CephFS subdirectory to mount into the container.
I was telling a friend about my RPi CEPH cluster. We got to the point where I was saying how proud I was that I had many different types of physical media in my cluster.
USB Flash Drives
SATA 3.5″ 7200RPM (12v + 5v)
SATA 2.5″ (5v)
SATA 3.5″ SSD
When I got to the SSD drives he said “You are wasting your SSD by mixing them in with all that slow storage”. In his view they would be better utilized as a cahing layer. So I went in search of a way to do that.
I have been using CephFS with my K8s cluster since the beginning, but until now the shared filesystem has been mounted in a “standard location” on each node as part of the cluster startup procedure and then used “hostPath” volume type to map a subdirectory into the container.
Today I found source code suggesting that K8s added “cephfs” as a supported volume type. See: k8s cephfs volume code and example.
When I tried it I had only partial success. I was able to mount the entire cephfs filesystem into a container (which is awesome) but found that the k8s version I was using (GitVersion:”v1.1.2-dirty”) does not support that mounting a subdirectory of the larger CephFS export:
root@node0 in ~/master
$ kubectl create -f cephfs.yaml
error validating "cephfs.yaml": error validating data: found invalid field path for v1.CephFSVolumeSource; if you choose to ignore these errors, turn validation off with --validate=false
Although the example code (even in master) does not show “path” being used, I think it is supported because I can see it in this code commit. In the newBuilderInternal() method there is code for adding a path name to the mount.
so /dev/ttyAMA0 is the serial device on the Pi side.
[root@server:/]# dmesg | grep -i PL2303
usbcore: registered new interface driver pl2303
usbserial: USB Serial support registered for pl2303
pl2303 3-3:1.0: pl2303 converter detected
usb 3-3: pl2303 converter now attached to ttyUSB0
[root@server:/]# lsusb | grep -i serial
Bus 003 Device 002: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
so /dev/ttyUSB0 is the serial device on the Server side.
Next, make sure getty is spawning on the server side and *not* on the Pi side.
On the Pi, edit /etc/inittab and comment out the entry for ttyAMA0.
Tell init we changed something:
root@pilo:/# kill -HUP 1
Verify: Make sure getty is not running on ttyAMA0
root@pilo:/# ps -ef | grep ttyAMA0
On the Server, edit /etc/sysconfig/init and add the new tty to the list of active consoles:
[bdoyle@server:/]# vi /etc/sysconfig/init
> ACTIVE_CONSOLES=”/dev/tty[1-6] /dev/ttyUSB0″
Tell init we changed something:
[root@server:/]# kill -HUP 1
Verify: Make sure getty is running on ttyUSB0
[root@server:/]# ps -ef | grep ttyUSB0
root 24603 1 0 13:33 ttyUSB0 00:00:00 /sbin/mingetty /dev/ttyUSB0
Test that connection by running “gnu screen” on the Pi to attach to the console on the server. If all goes well, you should be able to log in and get a shell:
On the Pi:
$ sudo apt-get install screen
root@pilo:/# screen /dev/ttyAMA0 9600
CentOS release 6.6 (Final)
Kernel 3.10.73 on an x86_64
server login: xxxxx
Last login: Wed Jun 17 13:41:03 on ttyUSB0
If the serial connection is not working you may need to adjust the tty settings.
Ok, now thats working, but we also want to be able to access the console while the system is booting.