Ingress-nginx on ARMv7 Raspberry Pi 3 Model B

https://github.com/kubernetes/ingress-nginx

Note after Installation Guide:

1. User Metallb as load balancer on bare metal for K8S on Raspberry 3.0B
2. In the mandatory.yaml file, change container image into:quay.io/kubernetes-ingress-controller/nginx-ingress-controller-arm:0.30.0 (thanks alexellis on github)
3. In the cloud-generic.yaml remove line:externalTrafficPolicy: Local. Kubernetes default externalTrafficPolicy is: Cluster. (It matters if Weave Net is used for networking)
4. kubectl create -f mandatory.yaml -f cloud-generic.yaml (one liner, so nginx-ingress-controller would not complain non-existence of service:ingress-nginx, which gets an IP address assigned from Metallb.
5. check logs inside nginx-ingress-controller for readiness or other errors if any.

I tried Helm 3 without luck. It seems there is repo issue.

Open source load testing tool

https://k6.io/blog/comparing-best-open-source-load-testing-tools

Performance testing is a type of testing for determining the speed of a computer, network or device. It checks the performance of the components of a system by passing different parameters in different load scenarios.

Load testing is the process that simulates actual user load on any application or website. It checks how the application behaves during normal and high loads. This type of testing is applied when a development project nears to its completion.

Stress testing is a type of testing that determines the stability and robustness of the system. It is a non-functional testing technique. This testing technique uses auto-generated simulation model that checks all the hypothetical scenarios.

Conclusion:

• Performance testing is a testing method used to determine the speed of a computer, network or devices.
• Load testing simulates real-world load on any application or website.
• Stress testing determines the stability and robustness of the system
• Performance testing helps to check the performance of website servers, databases, networks.
• Load testing is used for the Client/Server, Web-based applications.
• Stress testing is done unexpected test traffic of your website.

https://www.guru99.com/performance-vs-load-vs-stress-testing.html

NFS share on OS X Sierra Version 10.12.6 (16G2128) MacBook Pro (15-inch, 2017)

https://support.apple.com/en-us/HT202243

Create NFS share on OS X for NFS client connection

• mkdir <path to NFS share>
• chown -R nobody:nobody <path to NFS share>
• sudo nano /etc/exports, and add line:

<absolute path to NFS share> -maproot=nobody --alldirs ##allow client to mount at any point within NFS file system

• sudo chmod 640 /etc/exports
• nfsd status (if not running: nfsd enable && nfsd start)
• showmount -e

Mount NFS share from OSX command line:

• mkdir /mnt
• sudo mount -o hard,nolock <NFS share path> /mnt
• mount | grep nfs
• ls /mnt

Kubernetes Metrics Server on Raspberry Pi 3 Model B (ARM v7)

Metrics Server exposes core Kubernetes metrics via metrics API. Without Metrics Server,Horizontal Pod Autoscale (HPA) and kubectl top command will not work.

Github did not provide deployment yaml file for Raspberry Pi cluster, so I have to change original deploy/kubernetes/metrics-server-deployment.yaml

1. replace amd64 with arm (under containers and nodeSelectors section)

2. modify args into: (two extra lines)

        args:

          - --cert-dir=/tmp

          - --secure-port=4443

          - --kubelet-insecure-tls ###get ride error: http: TLS handshake error

          - --kubelet-preferred-address-types=InternalIP ### unable to fully scrape metrics from source kubelet

3. deploy Metrics Server and all the rest manifest yaml files in the same directory , and wait for a while to get rid off error:unable to fetch node metrics for node

Homebrew and Homebrew-Cask

Homebrew: The missing package manager for macOS
https://brew.sh/

Homebrew-Cask extends Homebrew and brings its elegance, simplicity, and speed to macOS applications and large binaries alike.
https://caskroom.github.io/

Early 2015 MacBook and late 2015 iMac 27'' 5K, target display mode alternative solution

Late 2015 iMac 27 5K doesn't support target display mode anymore, so early 2015 Macbook could not use it as display with target display mode.Plus This model MacBook doesn't come with thunderbolt port, one USB-c type only.

Obvious workaround will be old fashion remote desktop then. Apple's remote screen works, but it could not scale and the screen response depends network condition if it is via WiFi.

Then I got a Apple Thunderbolt 3 to Thunderbolt 2 adapter from BestBuy, however MacBook won't recognize it at all. Called Apple support couple times, and eventually they told me the usb type C port on this early 2015 MacBook is not really Thunderbolt 3, it is just USB 3.1 Gen one,  and 5Gbps is its maximum bandwidth, so the adapter won't work for it, and I could not use it for thunderbolt 2.0 conversion at all. (This is from Ajay Divakaran post on http://www.ajaydivakaran.com/imac-retina-and-target-display-mode/)

This leaves me to another try with USB 3.0 IP networking. after a good amount of google searching, I found one USB 3.0 cable with build-in switch: JUC500 from J5 Create. It is used for file transfer between two computer with USB 3.0 via smart Data Link protocol. (I did think about USB 3.0 cross over, but none of them available could be used for data transfer) I found the driver for IP over USB on OSX via HoRNDIS, which was build to share internet connection via USB cable for OS X, since Apple never provides its own driver for it. This driver was written some years ago, so it is for USB 2.0, and it is halfplex for some reason, so iPerf shows around 240Mbps throughput. I could not blame them at any rate. They was build to do they was meant to do, but not my case here. :-(

Eventually I went for ancient old cross over Ethernet cable with 1Gbps bandwidth, and of course I need a USB C to ethernet adapter for MacBook as well from eBay. This good old fashion connection was recognized by iMac ethernet port and Macbook USB type c port right away. With their own private subnet, 1Gbps connection via VNC connection (scaleable) could be an acceptable alternative for the missing target display mode finally.

VNC headless mode on Raspberry Pi low remote desktop resolution

Connecting to Raspberry Pi without keyboard and monitor connected via VNC viewer, but default display resolution is 640x480, which is too small and could not be scaled up.

After google for a while, link below provide the solution to change VNC screen solution:

https://www.realvnc.com/en/connect/docs/raspberry-pi.html

The term is headless and  To change the resolution, run the command sudo raspi-config, navigate to Advanced Options > Resolution, and choose an option. HDMI mode: Force

Thanks realvnc, and I learned something new.