6. 3. Platform observability
- Node problem detector
- Efficient logging
- Efficient metrics collecting
- Performance test
7. 3.1 Node problem detector
Why need it?
- Had a couple of kernel panic, no reason,
mostly assumed server’s under stress.
- Need to know before it happens.
10. 3.4 Performance test
- Early and frequently
- Cloud networking perf test is a beast
- PerfKitBenchmarker
- In-house “benchmarks” tool kit
11. 4. Deployment
- Blue/green deployment strategy
- Helm common template
- Containers security practice (Todo)
12. 5. Application
- Java workload on containers.
- Go
+ Ram is abundant due to optimized Go service.
+ Memory fragmentation could be a problem.
- NodeJS
+ Web server needs whole lots CPU on initiative
and minimal on run.
+ Skewed cpu resources limit to avoid crash loop.
13. 6. Kubectl tips and tricks
# get all pods sort by name
kubectl get po -o jsonpath='{range.items[*]}{.metadata.name}{"n"}{end}'
# Get all pods, which as restart_count > 0
kubectl get po -o
jsonpath='{range.items[?(@.status.containerStatuses[0].restartCount>0)]}{.status.containerStatuses[0].name}{"
n"}{end}'
# Get all non-running pods
kubectl get po -o jsonpath='{range.items[?(@.status.phase != "Running")]}{.metadata.name}{"n"}{end}'
# Get most used cpu pods
kubectl top pods | tail -n +2 | sort -nr -k 2 | awk '{print $1}' | head -n 1
# Get all nodes, and their IP
kubectl get no -o
jsonpath='{range.items[*]}{.metadata.name}{"t"}{.status.addresses[?(@.type=="InternalIP")].address}{"n"}{end}'
14. 7. Technical alignment
- Devops culture, train your software engineer
k8s mindset and tooling so you could focus
on improving the platform.
15. 15
THANKS!
Any questions?
Looking for teammates to build next generation cloud
native platform, like Hyperconverged infrastructure,
Chaos Engineering.
Chat to us at skype: tuan-viet.huynh or email to
viethuynh@chotot.vn
Editor's Notes
Open discussion
Event này chủ yếu khuyến khích anh em đã từng vọc qua k8s tham gia -> nên mình sẽ ko giới thiệu docker là gì, k8s là gì, cũng như các components của nó
Talk about hand on experiences, maybe how it works as our understanding
Chợ Tốt cũng chật vật tham gia vào câu chuyện dockerization nên đã trải nghiệm qua 1 số gỉai pháp để đến với k8s như bây giờ
Hiện tại có khá nhiều nhóm tham gia improve k8s ở Chợ Tốt, từ các team khác nhau, devops, infra, platform, software engineer
Overview về hệ thống Chợ Tốt đang chạy kube ở mức độ nào
Các kube components quan trọng: + thường xuyên làm việc với nó + dễ sinh ra vấn đề nhất
Platform observability: + cần chủ động nhận biết những gì xảy ra bên trong hệ thống, + không để user hoặc business team nói thì mới biết. + Not monitor + Standard monitor: dead/alive. If dead -> alert + Ví dụ: Number of request per second vào 1 API bị giảm 20% -> alert api owner
Deployment: + Cách deploy application Chợ Tốt đã & sẽ làm
Application: + Kinh nghiệm từ việc chạy app trên k8s/container với các ngôn ngữ lập trình khác nhau
Tips: + Tips sử dụng kubectl để operate
Team aligment: + Devops culture + Software engineer need to know to use k8s + how to deploy, monitor and debug dựa trên các tools devops đưa ra + Devops team can focus to improve platform
Why K8s? + Trước đó cân nhắc giữa DC/OS và k8s -> Try cả 2 + Có cộng đồng anh em của Chợ Tốt ở Châu Âu đang sử dụng k8s -> nhận thấy cơ hội được support + Pick one and bet + Có exp với Nomad nên hiểu hơn về mindset của docker orchestration -> move services to k8s không quá khó + Khó là setup k8s đáp ứng được việc chạy tải production, và làm việc với nhiều components của nó.
lý do dùng Cronjob:
+ có những việc chỉ cần chạy mỗi giờ hoặc mỗi ngày 1 lần
+ mỗi lần chạy cần big resources
+ nếu persistent running on host thì sẽ lãng phí resources
ephemeral caching: varnish, redis cho cả web và backend api
# KUBE-API
Tải về resource không nhiều
Need: availability
If kube-api dead -> can not deploy apps, rộng hơn là ko thể thay đổi những gì đang chạy
Trong thời gian ngắn 1 tiếng không vấn đề gì (tạm thời)
Không chấp nhận down kube-api ở system đã applied CD, deploy liên tục.
Solution: Load balancing with HAproxy
Upgrade: + Api-server is backward compatible, we accidentally apt-upgrade a node to newer version, and whole cluster is still running without error. + For upgrading cluster: next topic, beware of different api versioning
# KUBE-DNS
+ from: Bowei https://github.com/kubernetes/dns + issues: some pod could not resolve DNS to clusterIP -> failed -> chưa tìm ra root cause
+ to: Tim Hockin gcr.io/google_containers/kubedns-amd64:1.9
+ result: work well, increase limit, cache
dns -> single point of failure -> phải test kỹ (how -> open discuss)
# NETWORKING
Using Calico production, based on KET installation.
Những lần cài thử thì dùng Flannel theo document, nên cũng chưa thấy rõ sự khác biệt on production
calico: service node mesh -> rule/policy for routing
Issues: + Pod A on Node-02 could connect to all pod on Node-01 + Pod B on Node-03 could connect to all pod on Node-01 + Pod B on Node-04 could connect to all pod on Node-01 + Where issue come from? Node-04 or Node-01 + check /etc/calico/confd/config/bird.cfg
# ETCD
Cực kỳ quan trọng, nếu etcd down thì cả cluster đi đứt
Etcd suggest là chạy cluster 5 nodes -> được fail 2 nodes. ChoTot đang chạy 3 nodes -> stable
k8s CT prod hiện tại hầu như ko gặp issues gì với etcd + SSL connection + peer key for etcd <-> etcd + client key for other k8s components -> etcd
Etcd database nên được backup cho trường hợp disaster cần recovery
etcd: prometheus connect via ssl to etcd to get metrics
-> write a proxy between prometheus and etcd for ssl
prometheus -> etcd-proxy non-ssl -> etcd SSL
# RESOURCE QUOTAS
Set default limitrange + Request: cpu 50m, mem 128Mi + Limit: cpu 100m, mem 128Mi
Mục đích: tránh trường hợp deploy app lên mà không set resources limit trong helm charts, ảnh hưởng tới pods cùng host
issue: 2 workers unbalanced CPU clock || VM & physical
-> Nomad is good at this case
Platform observability:
Không chỉ dừng lại ở monitor
Thông thường monitor ở mức: dead/alive, high load -> alert
Không thể để user hoặc biz team báo thì mình mới biết
Cần: + request per min giảm đột ngột 20% so với cùng ngày hôm trước -> alert + total request hôm nay giảm > 10% so với hôm trước -> alert + vừa deploy app version mới lên thì có 1 metrics nào đó giảm đột ngột -> rollback release version
- Need: Tailable, local log (không ưu tiên raw log tập trung) , obstructive middleware, stdout ( standard logging )
- Standard solution: ELK ( recommended ) , why not use: enterprise support ( users, alert), current set up with Graylog working well
- Chotot solution: containers -> log file (rotated) <- fluent-bit read (container_id --> mux by service (central config integrate with kube-api (metadata) )) --> ship graylog
- metrics của kube -> prometheus cadvisor
- metrics của services, gồm: + total reqs; + (request/min, latency, status code) per path and per pod; + CPU, mem, network (packets) per pod + Go routine per pod
-> mỗi services expose metrics ra
-> prometheus đi scrape
- vấn đề:
+ prometheus không fit cho việc storage long term metrics
+ metrics của k8s quá nhiều, có những thứ mình chưa cần
+ Cụ thể:
chẳng hạn với một series metrics -> 1 label có thể được tags nhiều value
-> thông tin pod_name thay đổi liên tục mỗi khi deploy/restart svc
-> chủ động group lại theo y/c: node_name, service_name (pod_name without xxx)
- giải quyết:
+ dựng 2 con prometheus
+ con thứ 1 scrape metrics
-> aggregate lại metrics mình cần lấy
-> group theo services, nodes, pods
-> dùng federate chuyển sang một con prometheus thứ 2
-> con prometheus thứ 2 storage metrics dài hạn, ví dụ 1 năm.
-> trên con scraping set data retention ngắn
Template đã có, sửa 1 lần apply tất cả -> chỉ cần sửa file values.yaml
Hạn chế ko chạy container bằng root user, based on alpine -> muốn thay bằng linux from scratching
Network policy (todo)
Java: beware of default heap JVM setting ( jvm only aware of host resources, not container resource ). Long start up ( giống node )
Python: not performing well on containers , still dont know why
Nodejs: preferably not running pm2 -> open discuss
Turn off swap on kube-worker: swap unpredictation, docker sum mem + mem swap -> slow when using swap
