HackMD
tags: Meetup、Co-writing
CNTUG Meetup #21
Talk 1: k3sup 之極度快速 Set up k3s cluster（番外篇：Kubernetes帶我飛之歷程分享） by Samina Fu
What's K3s?
- 號稱 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
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
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
- Service Load Balancer
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 版本
總結
- 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 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
