###### tags: `Meetup`、`Co-writing`
# CNTUG Meetup #21

## Talk 1: k3sup 之極度快速 Set up k3s cluster（番外篇：Kubernetes帶我飛之歷程分享） by Samina Fu

[投影片link](https://speakerdeck.com/sufuf3/k3sup-zhi-ji-du-kuai-su-set-up-k3s-cluster)

### What's K3s?
[Twitter 上的 Kelsey Hightower："I like the way @rancher_labs has taken a fresh look at Kubernetes by removing, not adding, features to focus on running in low-resource computing environments such a retail stores and telco facilities. https://t.co/wAih5qq8Mi" / Twitter](https://twitter.com/kelseyhightower/status/1100565940939436034)

* 號稱 Lightweight Kubernetes
* 設計用於 production workloads
* 在低硬體資源的系統可能可以跑起來
* system requirement
* 512mb
* 75mb ram/node

### K3s 架構
* Server
* cluster status can be saved in SQLite, instead of etcd
* daemon on host
* Agent

特點：

* 多個功能整合為一個 process
* Tunnel proxy
* k3s 不可被刪除的 endpoint，用於 server 跟 agent 間溝通的 tunnel

Q/A: Can SQLite be HA?
=> https://github.com/rancher/k3s/issues/42

### Setup a K3s cluster way

#### Install
Dependency: Docker
安裝：[K3s Lab](https://github.com/sufuf3/k3s-lab)

Notice:
* Don't use K3s v0.9.0 in ARM platform ，裝了會掛掉
* K3s agent installation, you should export token at first

#### Uninstall

### How does k3s be weight-less?

* Removing old and non-essential code
* Dropping alpha APIs（刪掉一百萬行的 code）
* 移除非預設的 admission controllers、in-tree cloud providers 跟 storage drivers，需要的話自己裝（移除超過一百萬行的代碼）

* 減少主記憶體的使用
* 將多個功能包為單一 process

* 使用 containerd 取代 Docker
* Docker內建太多不必要的功能所以不預設使用 Docker

* Removing extra features

* 移除額外依賴軟體

* 減少執行時期需要的binary

* etcd 儲存資料於 /var/lib/etcd 底下
* k3s SQLite 放於 /var/lib/rancher/k3s/server/db 下
* journal -u k3s.service: `--etcd-servers=unix://kine.sock`、`--storage-backend=etcd3`
* 前面收 etcd 後面存 SQLite
* [ibuildthecloud/kine](https://github.com/ibuildthecloud/kine)

### Tunnel Proxy and Service LB

* 2 Load Balancers
* Service Load Balancer
* expose k8s services
* traefik used
* K8s endpoint(Cannot be disabled)
* tcpproxy, provide connectivity for HA scenarios
* Reverse tunnel connection: for master node's api-servers <-> agent nodes' kubelet & containerd

Q: pod on overlay network, what is the difference with flannel?
A:

### k3sup (read 'ketchup')
* Light-weight tool to get k3s up without KUBECONFIG
* Need: ssh access, k3sup binary, kubectl

https://github.com/sufuf3/k3sup-lab

* Prepare k3sup host: 1 node
* k3s cluster: N nodes
* make sure k3sup host can use SSH public-key authentication to n-nodes cluster

### ARM device 使用 k3s 的經驗
* CPU: 4x Arm Cortex-A53 @1.5 Ghz
* Memroy: 4GB
* Architecture: ARMv8 (AArch64)
* 2 VM nodes

要注意的地方：

* Checkout necessary modules are fine in Linux kernel version before compile
* cgroup issue if you use docker

* 不要在 ARM 平台上使用 K3s 0.9.0 版本
* [Can't start k3s 0.9.0 on Raspbian - containerd errors due to 127.0.0.1 · Issue #828 · rancher/k3s](https://github.com/rancher/k3s/issues/828)

### 總結
* Will be ideal for accelerating solution in edge cases

Q: 如果有很多Edges要建立多個Clusters嗎？
A:

## Talk 2: Kafka on Kubernetes

### distributed 要注意的事情

* 要如何去複製Data到每個節點？
* 要怎麼拿資料？

###
* 資料有時序性
* 大量寫入/讀取
* 快速寫入/讀取
* 宣稱 latency 較低

### Concepts
* 用 topics 作為分類保存多個 records 串流
* record = (key, value, timestamp)

### KAFKA DIAGRAM
* 有複數個 worker 在工作
* producer製造訊息給Kafka
* consumer消化訊息，去 Kafka 拿
* 用 Connecter 存取 DB
* Stream processors

### TOPIC PARTITIONS
* 多個有時序性的佇列
* 以 topic 分隔複寫寫入多個 partition
* 資料寫入時會有時間差
* 耐用性
* consumer理論上可自至少一 partition 拿到資料
* 資料拿出來的時候是按照Kafka裡的順序

### DISTRIBUTED DATA STREAMING
* 帶寬可以 scale
* 可承受一定程度的故障
* Data consistency
* Availability
* Partition Tolerance

### CONSUMER GROUP（跳過）

### Deployment
[Helm Kafka](https://github.com/chechiachang/kafka-on-kubernetes)

### HELM CHART VALUES
裝之前要確認參數

* 強烈建議設定 limit
* Notices:
* jvm heap option
* pidAntiAffinity
* 提供 Prometheus exporter，方便即時監控 Kafka 運行狀況
* Zookeeper：保存 topic config

### KUBERNETES CONFIGURATION

### KAFKA CONFIGURATIONS
* zookeeper
* configurationOverrides
* `default.replication.factor` （預設1無冗餘保存資料）

### 監控設定
* Prometheus exporter
*

### 在了解配置後才佈署 Kafka
* 不正確的設定會造成問題

### PODS
`kubectl get po | grep kafka`

### AVAILABILITY / 可用性
ex. replication factor = 3

* 3 partition 各一保存於 kafka-broker
* 1 master（r/w） 2 slaves \(r\)
* sync: master -> slave, more slaves more effort
* in-synced slave: Just keep part of slaves for sychronizing, if new slave want to sync, just connect those in-sync slaves.
* not enough in-sync slaves: master might die.

### ON SLAVE FAILURE
* client 不受影響
* master 補齊足夠的 in-sync slaves
* wait dead slave to back online

### ON Master Failure
* slave 於 in-sync slaves 中選舉出新的 master
* new master sync to slaves （因為in-sync資料跟得很緊）
* 新的 master 服務客戶端
* 會先確保sync的資料是正確的並且完成，死掉的 master 重新上線會變為 slave 節點

### CONFIGS AVAILABILITY / 配置的可用性
* 保存於外部(Zookeeper)的Metadata：
* topic configs
* partition configs
* consumer offsets

### 重點
* helm chart values 的設定設錯就幹掉重來
* 要跑得好必須研究Kafka 的概念與設定
* resource & JVM heap size
* Prometheus is must-have, export JVM heap status

---

[Markdown 語法說明](https://markdown.tw/)