Lộ trình học Consul

Tuần 1 - Nhập môn và kiến trúc lõi

Ngày 1 - Vì sao cần Consul, mô hình vấn đề

Đọc: Introduction to Consul, Introduction to Service Discovery, Introduction to Service Mesh.

Nội dung cần nắm: trước khi có service discovery, hệ thống dựa vào địa chỉ tĩnh (config file, DNS tĩnh, load balancer cấu hình tay) - vấn đề là môi trường cloud-native có instance sinh/chết liên tục (autoscaling, container rescheduling), địa chỉ tĩnh không theo kịp. Service discovery giải quyết bài toán "ai đang chạy, ở đâu, còn sống không" theo thời gian thực. Service mesh giải quyết một tầng vấn đề khác: một khi đã biết địa chỉ, làm sao đảm bảo kênh truyền an toàn (mTLS), có thể quan sát (observability), và chịu lỗi (retry, timeout, circuit breaking) mà không phải nhúng logic đó vào từng ứng dụng bằng ngôn ngữ khác nhau.

Lab: vẽ sơ đồ kiến trúc một hệ 20 microservices không có service mesh, liệt kê cụ thể: chỗ nào hardcode IP, chỗ nào TLS bị bỏ qua vì "khó implement ở mọi service", chỗ nào retry logic viết lặp lại ở mỗi service bằng ngôn ngữ khác nhau và không đồng nhất.

Checkpoint: phân biệt rạch ròi giữa service discovery và service mesh - đâu là superset của đâu, và vì sao một hệ thống có thể cần discovery mà không cần full mesh (ví dụ hệ nhỏ, trust nội bộ cao).

Ngày 2 - Lý thuyết nền: CAP, Raft, SWIM

Đọc: paper Raft gốc của Diego Ongaro (In Search of an Understandable Consensus Algorithm), ít nhất phần leader election và log replication. Đọc paper SWIM (Scalable Weakly-consistent Infection-style Process Group Membership Protocol), phần cơ chế probe và suspicion.

Nội dung cần nắm về Raft: cluster có N server, mỗi server ở một trong ba trạng thái follower/candidate/leader. Thời gian chia thành các term có số tăng dần. Leader election dùng randomized timeout để tránh split vote liên tục. Log replication: leader nhận write, append vào log cục bộ, gửi AppendEntries tới follower, chỉ commit (áp dụng vào state machine) khi đã có majority replicate. Đây là lý do tại sao viết vào Consul luôn cần ít nhất (N/2)+1 server phản hồi - không phải để "an toàn cho có" mà là điều kiện toán học bắt buộc để đảm bảo không có hai leader cùng tồn tại trong cùng một term.

Nội dung cần nắm về SWIM: đây không phải cơ chế heartbeat tập trung (một node theo dõi tất cả), mà là gossip phân tán - mỗi node định kỳ chọn ngẫu nhiên một node khác để probe (ping trực tiếp, nếu không phản hồi thì nhờ vài node khác probe gián tiếp - indirect probe). Nếu vẫn không phản hồi, node đó được đánh dấu "suspect" và tin này lan truyền theo kiểu infection (mỗi node nhận tin lại piggyback tin đó vào message tiếp theo của chính nó) chứ không phải một nguồn trung tâm phát tán. Cơ chế suspicion (thay vì dead ngay lập tức) tồn tại để giảm false positive do network jitter tạm thời.

Lab: không code, chỉ tự vẽ tay hai sơ đồ trên giấy - một là leader election 5 node với timeline term, một là quá trình một node bị suspect lan truyền qua 3 hop gossip.

Checkpoint: giải thích được vì sao Raft cần majority (không phải toàn bộ) để commit, và vì sao SWIM dùng indirect probe thay vì chỉ trust một lần ping trực tiếp thất bại.

Ngày 3 - Kiến trúc tổng thể: server, client agent, dataplane

Đọc: mục Architecture trong tài liệu chính thức, reference architecture cho VM và cho Kubernetes.

Nội dung cần nắm: Consul có hai tầng gossip pool - LAN pool (trong một datacenter, gồm cả server và client) và WAN pool (chỉ server, dùng để liên lạc giữa các datacenter). Model cũ (VM): mỗi node chạy một client agent, agent này tham gia LAN gossip, forward RPC lên server, và (khi bật Connect) tự quản lý sidecar proxy cục bộ. Model mới cho Kubernetes/ECS (từ khoảng bản 1.14 trở đi): không còn client agent chạy trong mỗi pod, thay vào đó một tiến trình nhẹ gọi là consul-dataplane chạy cùng pod, nói chuyện trực tiếp với Consul server qua gRPC/xDS để lấy config Envoy, không tham gia gossip pool. Đây là khác biệt kiến trúc quan trọng cần phân biệt rõ vì rất nhiều tài liệu cũ trên mạng vẫn mô tả theo model client agent.

Internals: lý do Consul tách bạch hai loại consistency - Raft (strong, dùng cho catalog write, KV, ACL - cần đúng và nhất quán) và gossip (eventually consistent, dùng cho membership và failure detection - cần nhanh, chấp nhận trễ vài giây để đổi lấy khả năng mở rộng và không cần một điểm trung tâm). Toàn bộ hành vi "lạ" gặp trong production (ví dụ DNS trả về node đã down vài giây trước khi cập nhật) đều bắt nguồn từ trade-off này.

Lab: vẽ bảng so sánh model client agent (VM) và model dataplane (K8s), liệt kê rõ: ai tham gia gossip, ai giữ local cache, ai chịu trách nhiệm cấu hình Envoy.

Checkpoint: nếu có người hỏi "Consul agent trên Kubernetes có tham gia LAN gossip pool không", trả lời chính xác kèm lý do.

Ngày 4 - Cluster đầu tiên, quan sát Raft trực tiếp

Lab: dựng cluster 3 server bằng Docker Compose hoặc Vagrant, dùng bootstrap_expect: 3. Chạy consul operator raft list-peers để xác định leader hiện tại. Kill process của leader, quan sát log của các server còn lại - tìm chính xác dòng log báo bắt đầu election, dòng log báo node mới trở thành leader, đo thời gian từ lúc kill đến lúc có leader mới ổn định.

Internals: quan sát trong log giá trị term tăng lên sau mỗi lần election. Tìm hiểu election timeout mặc định và random jitter được thêm vào để tránh nhiều node cùng trở thành candidate đồng thời (nếu không random, các node có thể liên tục timeout cùng lúc, gây vòng lặp election thất bại vô hạn - đây chính là vấn đề mà thuật toán Raft cố tình thiết kế randomization để tránh).

Checkpoint: chỉ ra chính xác trong log dòng nào đánh dấu chuyển trạng thái follower sang candidate, và candidate sang leader.

Ngày 5 - Gossip pool và failure detection

Lab: thêm 2 client agent vào cluster ngày 4. Bật log level debug hoặc dùng consul monitor để quan sát gossip traffic. Kill một client agent (không phải server/leader) bằng cách giết process đột ngột (không graceful leave). Đo chính xác thời gian từ lúc kill đến lúc consul members hiển thị trạng thái failed cho node đó.

Internals: so sánh thời gian failure detection qua gossip (thường vài giây) với thời gian nếu phải đợi một cơ chế strong-consistent qua Raft (sẽ chậm hơn nhiều vì phải đảm bảo majority đồng thuận). Đây là lý do thiết kế: failure detection cần nhanh và có thể chấp nhận sai sót tạm thời (false suspect rồi tự sửa), trong khi ghi dữ liệu catalog/ACL cần đúng tuyệt đối dù chậm hơn.

Checkpoint: giải thích cụ thể sự khác biệt giữa trạng thái node "left" (graceful, chủ động rời cluster) và "failed" (bị phát hiện qua gossip do không phản hồi) - hai trạng thái này ảnh hưởng khác nhau đến việc dọn dẹp trong catalog.

Tuần 2 - Triển khai và Service Discovery

Ngày 6 - Cấu hình agent production-grade

Đọc: tài liệu agent configuration, tìm hiểu toàn bộ tham số quan trọng: data_dir, bind_addr, advertise_addr, retry_join, log rotation, ui_config.

Lab: viết file cấu hình .hcl hoàn chỉnh dùng lại được cho các lab sau. Thử nghiệm consul reload, xác định chính xác tham số nào áp dụng được khi reload và tham số nào bắt buộc phải restart toàn bộ agent (thường liên quan đến network binding và encryption key).

Checkpoint: có một file cấu hình mẫu, và một bảng phân loại "reload được"/"phải restart" cho các tham số chính.

Ngày 7 - Triển khai trên VM bằng systemd

Đọc: Deploy Consul on VMs tutorial.

Lab: viết systemd unit file đúng chuẩn (Restart=on-failure, User riêng không chạy root, giới hạn tài nguyên), deploy cluster 3 node như dịch vụ hệ thống thật, không chạy tay trong terminal. Test systemctl restart trên từng node, xác nhận agent tự động rejoin cluster nhờ retry_join mà không cần can thiệp thủ công.

Checkpoint: cluster chịu được việc restart từng node lần lượt (rolling) mà không mất quorum tại bất kỳ thời điểm nào - tự tính toán: với 3 node, được phép mất tối đa bao nhiêu node cùng lúc mà vẫn còn quorum.

Ngày 8 - Triển khai trên Kubernetes

Đọc: Deploy Consul on Kubernetes tutorial, cấu trúc Helm chart chính thức.

Lab: deploy bằng Helm chart (server StatefulSet, dataplane injection). So sánh trực tiếp với cluster VM ở ngày 7 - log khác gì, cách node join khác gì.

Internals: tìm hiểu cụ thể luồng khi một pod mới được tạo - mutating webhook của consul-k8s tiêm sidecar container (consul-dataplane) vào pod, container này khởi động, kết nối tới Consul server qua gRPC để lấy bootstrap config, sau đó thiết lập kết nối xDS liên tục để nhận cập nhật cluster/listener/route/endpoint theo thời gian thực.

Checkpoint: mô tả được đầy đủ luồng từ lúc kubectl apply một pod có annotation inject đến lúc sidecar sẵn sàng nhận traffic, không bỏ sót bước nào.

Ngày 9 - Đăng ký dịch vụ (service registration)

Đọc: services documentation, service discovery tutorial.

Lab: đăng ký 3 service bằng file định nghĩa trong thư mục config. Đăng ký một service khác trực tiếp qua HTTP API (không qua file). So sánh: với file cần reload agent mới nhận, với API thì có hiệu lực ngay.

Internals: cơ chế anti-entropy - agent giữ một local state (từ file cấu hình cộng với các thay đổi qua API), và định kỳ so sánh với state trên server catalog, tự động đồng bộ chênh lệch (đăng ký thêm cái thiếu, xóa cái không còn hợp lệ). Đây là lý do một service "biến mất" khỏi catalog không nhất thiết do bị xóa chủ động mà có thể do anti-entropy phát hiện agent không còn khai báo nó nữa (ví dụ do sửa file cấu hình).

Checkpoint: giải thích chính xác anti-entropy hoạt động theo chiều nào - agent đẩy state lên server, hay server kéo state từ agent, và điều gì xảy ra nếu agent bị mất kết nối với server một thời gian rồi kết nối lại.

Ngày 10 - Health checks, DNS, prepared query

Đọc: health check tutorial, tài liệu endpoint /query.

Lab: thêm health check dạng HTTP, TCP, và TTL cho các service ở ngày 9. Cố tình làm một instance fail check, đo thời gian chính xác từ lúc fail đến lúc nó biến mất khỏi kết quả dig @127.0.0.1 -p 8600 tên-service.service.consul. Viết một prepared query có cấu hình failover sang datacenter khác (nếu chưa có multi-DC, ít nhất viết đúng cú pháp và hiểu logic).

Internals: phân biệt rõ ba loại check: script/TTL check yêu cầu ứng dụng hoặc agent chủ động báo cáo (push-based, phù hợp khi kiểm tra logic nghiệp vụ phức tạp), HTTP/TCP check do agent chủ động polling (pull-based, đơn giản và phổ biến nhất). TTL check đặc biệt vì nếu ứng dụng không báo cáo trong khoảng thời gian quy định, health tự động chuyển critical - điều này khiến TTL check nhạy với việc ứng dụng bị treo mà không crash hẳn.

Checkpoint: cho một tình huống cụ thể (ví dụ kiểm tra một worker xử lý queue không có endpoint HTTP), chọn đúng loại check và giải thích lý do.

Tuần 3-4 - Service Mesh (Connect), phần trọng tâm nhất

Ngày 11 - Khái niệm service mesh và zero trust

Đọc: service mesh concept page, understand service mesh guide, zero trust security page.

Nội dung cần nắm: zero trust trong ngữ cảnh Consul không phải là một chính sách firewall theo địa chỉ mạng, mà là mô hình dựa trên định danh (identity-based) - mỗi service có một identity cryptographic (chứng chỉ do CA nội bộ cấp), và mọi kết nối được xác thực dựa trên identity đó bất kể traffic đi qua mạng nào, kể cả trong cùng subnet. Điều này khác về bản chất so với mô hình "trust theo network zone" truyền thống.

Checkpoint: giải thích tại sao mô hình zero trust theo identity mạnh hơn firewall theo IP trong môi trường có IP được cấp phát động (container, autoscaling).

Ngày 12 - Sidecar proxy và Connect CA

Đọc: Envoy proxy configuration documentation.

Lab: bật Connect trên cluster, đăng ký một service với sidecar. Chạy consul connect envoy -bootstrap để xem chính xác file bootstrap config Envoy được sinh ra. Dùng openssl x509 đọc chứng chỉ được cấp cho service, tìm trường SAN (Subject Alternative Name) chứa định danh dạng tương tự SPIFFE ID.

Internals: Connect CA là một CA nội bộ (mặc định dùng Vault hoặc CA built-in), cấp chứng chỉ ngắn hạn cho từng service, tự động xoay vòng (rotate) mà không cần can thiệp thủ công. Mỗi chứng chỉ gắn với một service identity cụ thể trong một namespace/partition cụ thể (ở bản Enterprise).

Checkpoint: tự tay đọc được một chứng chỉ thật và chỉ ra chính xác trường nào mã hóa định danh của service.

Ngày 13 - Intentions, deny by default

Đọc: traffic management use case.

Lab: thiết lập hai service (gọi là A và B), mặc định traffic bị deny, gọi thử và quan sát lỗi kết nối (connection reset hoặc refused, tùy tầng chặn). Viết intention cho phép A gọi B, xác nhận thành công.

Internals: intention không phải một tầng lọc packet theo địa chỉ, mà được Envoy enforce ngay trong quá trình bắt tay mTLS - chứng chỉ phía gọi phải khớp với identity được intention cho phép, nếu không handshake bị từ chối trước khi bất kỳ dữ liệu ứng dụng nào được truyền. Ở tầng L7 còn có thể enforce chi tiết hơn qua RBAC filter dựa trên path/method.

Checkpoint: giải thích chính xác việc deny một intention chặn traffic ở giai đoạn nào của kết nối TCP/TLS, không phải sau khi kết nối đã thiết lập xong.

Ngày 14 - Bắt gói tin, chứng minh mTLS tự động

Lab: dùng tcpdump hoặc Wireshark bắt traffic giữa hai sidecar của A và B đã thiết lập ở ngày 13. Chỉ ra rõ ràng: traffic giữa ứng dụng và sidecar cục bộ (qua localhost) là plaintext, còn traffic giữa hai sidecar qua mạng là TLS đầy đủ, dù code ứng dụng không hề biết gì về TLS.

Checkpoint: có bằng chứng cụ thể (log tcpdump hoặc ảnh chụp Wireshark) cho thấy TLS handshake xảy ra giữa hai sidecar, lưu lại làm tài liệu tham khảo cá nhân.

Ngày 15 - Giao thức xDS: control plane cấu hình Envoy

Nội dung cần nắm: Consul server đóng vai trò control plane, phát cấu hình xuống mỗi Envoy sidecar (đóng vai trò data plane) thông qua giao thức xDS gồm bốn thành phần chính - CDS (Cluster Discovery Service, định nghĩa các nhóm upstream), LDS (Listener Discovery Service, định nghĩa các cổng lắng nghe), RDS (Route Discovery Service, định nghĩa quy tắc route), EDS (Endpoint Discovery Service, danh sách địa chỉ IP của từng instance). Đây là cơ chế tách biệt hoàn toàn control plane (nơi quyết định "nên route thế nào") khỏi data plane (nơi thực thi route đó cho từng gói tin).

Lab: truy cập Envoy admin interface trên cổng 19000 của một sidecar, xem config_dump, đối chiếu từng phần với intention và service definition đã khai báo, xác nhận chúng khớp nhau.

Checkpoint: khi service mesh có hành vi route sai, xác định được bước debug đầu tiên là kiểm tra config_dump của Envoy chứ không phải đoán mò ở tầng ứng dụng.

Ngày 16 - Traffic management tầng L7: routing và splitting

Đọc: tài liệu ServiceRouter, ServiceSplitter, ServiceResolver.

Lab: triển khai hai phiên bản của cùng một service (v1 và v2), dùng ServiceSplitter chia traffic theo tỉ lệ 90/10. Gọi liên tục nhiều lần, đếm tỉ lệ request rơi vào từng phiên bản, xác nhận gần đúng tỉ lệ cấu hình.

Checkpoint: phân biệt rõ ServiceSplitter (chia theo tỉ lệ phần trăm, không quan tâm nội dung request) với ServiceRouter (định tuyến theo điều kiện cụ thể như header, path).

Ngày 17 - Retry, timeout, resilience

Lab: cấu hình retry và timeout qua ServiceResolver hoặc router config. Cố tình làm service B trả lỗi ngẫu nhiên (ví dụ 50% request lỗi 503) bằng cách chèn logic giả lập vào code test, xác nhận cơ chế retry ở tầng proxy tự động xử lý mà không cần sửa code ứng dụng gọi.

Đọc thêm: khái niệm outlier detection trong Envoy - cơ chế circuit breaker tự động loại bỏ tạm thời một instance liên tục trả lỗi khỏi danh sách được route tới, tránh gửi traffic vào một instance đang gặp sự cố.

Checkpoint: chứng minh được toàn bộ lớp resilience (retry, timeout, circuit breaking) hoạt động độc lập với code ứng dụng, chỉ bằng cấu hình ở tầng proxy.

Ngày 18 - Ingress Gateway

Đọc: ingress gateway documentation.

Lab: thiết lập ingress gateway để expose một service ra ngoài phạm vi cluster nội bộ.

Checkpoint: giải thích sơ bộ sự khác biệt giữa ingress gateway và một load balancer thông thường đặt trước mesh - ingress gateway là một phần của mesh, có sidecar riêng, tuân theo intention và có thể route theo cấu hình L7 giống các service khác trong mesh.

Ngày 19 - Lab tổng hợp service mesh

Lab: tự thiết kế một hệ gồm bốn service (A gọi B, B gọi C, D độc lập không liên quan), tự tay thiết lập đầy đủ từ đầu không nhìn tài liệu: intentions cho từng cặp, traffic splitting cho một cặp, retry cấu hình cho một cặp khác. Ghi lại chính xác chỗ nào phải dừng lại tra cứu - đó là dấu hiệu kiến thức chưa vững ở phần đó.

Checkpoint: hoàn thành toàn bộ lab mà không cần xem lại tài liệu quá 2 lần.

Ngày 20 - Củng cố

Dành trọn ngày để hoàn thiện các phần dang dở của tuần 3-4, đọc lại phần Internals nào cảm thấy còn mơ hồ, đặc biệt xDS (ngày 15) và cơ chế mTLS handshake (ngày 14) - đây là hai phần nền tảng cho toàn bộ phần còn lại của syllabus.

Tuần 5 - Bảo mật hạ tầng và ACL

Ngày 21 - Security model tổng thể

Đọc: security model documentation, encryption documentation.

Lab: liệt kê đầy đủ mọi kênh giao tiếp trong một cluster Consul hoàn chỉnh và loại bảo vệ cần thiết cho từng kênh - RPC giữa các server (TLS), gossip giữa mọi agent (symmetric encryption key riêng biệt, không phải TLS), HTTP API (TLS + ACL token), xDS giữa server và sidecar/dataplane (TLS qua chứng chỉ Connect CA).

Checkpoint: vẽ được sơ đồ đầy đủ tất cả các kênh và loại encryption tương ứng, không bỏ sót kênh nào.

Ngày 22 - TLS cho RPC và HTTP

Đọc: encryption tutorial, CA root certificate documentation.

Lab: bật TLS cho RPC (verify_incoming, verify_outgoing) trên cluster đã dựng từ tuần 1. Thử cho một agent join bằng chứng chỉ không hợp lệ, xác nhận nó bị từ chối.

Checkpoint: giải thích built-in CA hoạt động ra sao, và vì sao mọi chứng chỉ trong cluster phải cùng chung một CA gốc (nếu không, verify_incoming/verify_outgoing sẽ từ chối kết nối).

Ngày 23 - Gossip encryption

Đọc: gossip encryption documentation.

Lab: tạo key bằng consul keygen, bật gossip encryption trên toàn cluster. Thử cho một agent join bằng key sai, quan sát lỗi cụ thể. Thực hành xoay key (consul keyring) trong khi cluster đang chạy, không gây gián đoạn - quy trình đúng là thêm key mới song song key cũ, chuyển toàn bộ cluster dùng key mới làm primary, rồi mới xóa key cũ.

Checkpoint: giải thích chính xác tại sao phải giữ song song key cũ và mới trong lúc rotate thay vì đổi trực tiếp - nếu đổi trực tiếp, các agent chưa kịp nhận key mới sẽ mất kết nối gossip với các agent đã đổi.

Ngày 24 - ACL: bootstrap và khái niệm cốt lõi

Đọc: ACL core concepts, manage permissions tutorial.

Lab: bootstrap hệ thống ACL trên một cluster đang chạy sẵn (mô phỏng tình huống migration thật, không phải cluster mới tinh). Thiết lập biến môi trường CONSUL_HTTP_TOKEN, thử gọi API không có token (bị từ chối) và có token hợp lệ (thành công).

Checkpoint: phân biệt chính xác bốn khái niệm: token (danh tính khi gọi API/CLI), policy (tập hợp rule), rule (quyền cụ thể trên một resource type như service/node/key/session/query), role (tập hợp nhiều policy gán sẵn, gán cho token thay vì gán từng policy lẻ).

Ngày 25 - ACL nâng cao, least-privilege

Đọc: ACL rules documentation, hướng dẫn tạo token qua CLI, API, UI.

Lab: viết một policy theo nguyên tắc least-privilege cho một service cụ thể - chỉ cho phép service đó tự đăng ký chính nó (không đăng ký được service khác), chỉ đọc được đúng một prefix KV thuộc về nó. Tạo một token gắn nhiều policy khác nhau, xác nhận quyền hợp nhất đúng như kỳ vọng (union của các rule). Kiểm tra tham số acl.enable_token_persistence, restart agent, xác nhận token có còn hiệu lực hay bị mất tùy theo cấu hình này.

Checkpoint: có sẵn một bộ policy mẫu least-privilege tái sử dụng được, và giải thích rõ token persistence ảnh hưởng thế nào đến hoạt động của agent sau khi restart.

Tuần 6 - Gateway và Multi-Datacenter

Ngày 26 - Bốn loại gateway, tổng quan phân loại

Đọc: control access to services with gateways documentation.

Nội dung cần nắm và phân loại chính xác: Mesh Gateway dùng cho traffic giữa các datacenter hoặc cluster khác nhau (between mesh, dùng SNI routing để không cần giải mã traffic ngay tại gateway). Ingress Gateway đưa traffic từ ngoài vào trong mesh (into mesh), là một phần của mesh nên tuân theo intention. Terminating Gateway đưa traffic từ trong mesh ra các service không có sidecar, ví dụ database hoặc hệ thống legacy (out of mesh). API Gateway là entrypoint chuẩn hóa, thường dùng thay ingress gateway khi cần các tính năng API-gateway-style đầy đủ hơn (rate limiting, header transformation) theo chuẩn Kubernetes Gateway API.

Checkpoint: cho một tình huống bất kỳ, xác định ngay loại gateway phù hợp và giải thích lý do loại trừ ba loại còn lại.

Ngày 27 - Terminating Gateway

Đọc: terminating gateway documentation, tutorial tương ứng cho Kubernetes.

Lab: thiết lập một service giả lập bên ngoài mesh (ví dụ một VM chạy database không có sidecar), đưa nó vào phạm vi mesh thông qua terminating gateway, xác nhận một service trong mesh có thể gọi tới nó qua intention như một service bình thường.

Checkpoint: giải thích vì sao service phía ngoài này vẫn được bảo vệ bởi intention dù bản thân nó không chạy Envoy - vì terminating gateway đứng ra làm proxy đại diện, chịu trách nhiệm mTLS phía trong mesh thay cho nó.

Ngày 28 - API Gateway

Đọc: API gateway documentation, tutorial Kubernetes hoặc VM.

Lab: thiết lập API gateway làm entrypoint từ bên ngoài internet vào một service trong mesh.

Checkpoint: so sánh cụ thể với ingress gateway đã làm ở ngày 18, chỉ ra chính xác khi nào nên chọn API gateway thay vì ingress gateway (thường liên quan đến nhu cầu chuẩn hóa theo Kubernetes Gateway API hoặc cần tính năng L7 nâng cao hơn).

Ngày 29 - WAN Federation và Cluster Peering, lý thuyết

Đọc: cluster peering documentation, mesh gateways documentation, tài liệu so sánh WAN federation và cluster peering, multi-platform federation documentation.

Nội dung cần nắm: WAN federation dùng một trust domain duy nhất, ACL được replicate xuyên toàn bộ liên kết datacenter, phù hợp khi toàn bộ hạ tầng thuộc một tổ chức quản lý tập trung. Cluster peering dùng nhiều trust domain độc lập, mỗi cluster tự quản lý ACL riêng, phù hợp khi cần liên kết hai tổ chức độc lập (ví dụ sau sáp nhập công ty), hoặc muốn giới hạn blast radius khi một cluster gặp sự cố không ảnh hưởng ACL của cluster kia.

Checkpoint: cho tình huống hai công ty sau sáp nhập cần thông traffic giữa hai hạ tầng Consul độc lập, chọn đúng cluster peering và giải thích vì sao WAN federation không phù hợp trong trường hợp này.

Ngày 30 - Lab Multi-Datacenter

Lab: dựng hai datacenter, thiết lập WAN federation, gọi một service xuyên datacenter qua mesh gateway, xác nhận traffic hoạt động đúng. Sau đó dựng lại kết nối tương tự nhưng bằng cluster peering thay vì WAN federation, so sánh trực tiếp độ phức tạp thiết lập giữa hai cách.

Checkpoint: có sẵn hai bộ cấu hình mẫu (federation và peering) đã tự tay chạy thành công, dùng làm tài liệu tham khảo về sau.

Tuần 7 - Observability

Ngày 31 - Hai tầng observability: control plane và data plane

Đọc: observability use case, telemetry documentation.

Nội dung cần nắm: nguồn metrics ở tầng control plane là chính Consul server (Raft commit time, apply time, leader election count, RPC latency), phản ánh sức khỏe của cụm quản lý. Nguồn metrics ở tầng data plane là từng Envoy sidecar (request rate, error rate, latency theo từng cặp service), phản ánh sức khỏe của traffic đi qua mesh. Hai tầng này độc lập - control plane có thể khỏe mạnh trong khi data plane đang có vấn đề route sai, và ngược lại.

Checkpoint: vẽ sơ đồ nguồn dữ liệu hai tầng, chỉ rõ metrics nào thuộc tầng nào.

Ngày 32 - Thiết lập metrics và dashboard

Lab: bật Prometheus scrape cho Consul server, dựng dashboard Grafana cơ bản gồm ít nhất: số lần đổi leader theo thời gian, Raft commit latency. Bật Prometheus scrape cho Envoy sidecar, thêm panel request rate và error rate theo từng service.

Checkpoint: dashboard hoạt động, nhìn vào biết ngay nếu leader đang đổi bất thường (dấu hiệu cluster không ổn định) hoặc error rate của một service tăng đột biến.

Ngày 33 - Access log và audit log

Đọc: access logs documentation, audit logging documentation, audit logging tutorial.

Lab: bật access log trên một sidecar, quan sát định dạng log request đi qua. Bật audit logging ở tầng Consul server, thực hiện vài thao tác ACL (tạo token, sửa policy), đọc lại log audit tương ứng để xác nhận ghi nhận đầy đủ ai làm gì và khi nào.

Checkpoint: giải thích rõ giá trị của audit log cho mục đích compliance, và phân biệt nó với access log (audit log ghi hành động quản trị lên Consul, access log ghi traffic đi qua mesh).

Tuần 8 - Vận hành và bảo trì

Ngày 34 - Backup và restore

Đọc: consul snapshot documentation, backup and restore tutorial.

Lab: backup cluster hiện tại bằng consul snapshot save. Restore snapshot đó vào một cluster hoàn toàn mới (không phải restore lại vào chính cluster cũ) để mô phỏng đúng tình huống disaster recovery thật sự.

Nội dung cần nắm: snapshot chứa toàn bộ Raft state, bao gồm cả ACL token và dữ liệu KV nhạy cảm - file backup cần được bảo vệ (mã hóa khi lưu trữ, giới hạn quyền truy cập) tương đương mức độ nhạy cảm của chính dữ liệu production.

Checkpoint: đã tự tay thực hiện thành công ít nhất một lần restore vào cluster mới hoàn toàn, có runbook ghi lại từng bước.

Ngày 35 - Rolling upgrade

Đọc: upgrade Consul documentation.

Lab: thực hành nâng cấp version từ N lên N+1 trên cluster 3 node mà không gây downtime - nâng cấp từng server một, xác nhận quorum vẫn còn nguyên ở mỗi bước trước khi chuyển sang server tiếp theo.

Checkpoint: giải thích thứ tự nâng cấp đúng (thường nâng non-leader trước, leader nâng sau cùng hoặc để nó tự chuyển giao vai trò), và lý do đằng sau thứ tự đó.

Ngày 36 - Thêm và gỡ server an toàn, Autopilot

Lab: thêm một server mới vào cluster đang chạy, xác nhận nó join đúng vai trò voter. Gỡ một server cũ theo đúng quy trình (dùng consul leave trước khi tắt máy, không kill đột ngột).

Đọc: tài liệu về Autopilot - cơ chế tự động dọn dẹp server đã chết (dead server cleanup) và các tùy chọn redundancy zone.

Checkpoint: phân biệt chính xác hệ quả giữa một server bị crash đột ngột (cần can thiệp thủ công để dọn dẹp khỏi Raft peer list) và một server rời cluster đúng quy trình qua consul leave (được dọn dẹp tự động, sạch sẽ).

Ngày 37 - Công cụ troubleshooting

Đọc: consul monitor, consul debug, consul troubleshoot documentation.

Lab: giả lập độ trễ mạng giữa hai server bằng tc netem, dùng consul debug thu thập bundle (gồm metrics, log, pprof), tự phân tích bundle đó. Dùng consul troubleshoot kiểm tra kết nối giữa hai service trong mesh khi nghi ngờ có vấn đề.

Checkpoint: viết một runbook cá nhân hoàn chỉnh cho tình huống "Consul server mất quorum - làm gì đầu tiên", liệt kê từng bước cụ thể theo thứ tự ưu tiên.

Ngày 38 - Chaos test tổng hợp

Lab: giả lập network partition giữa các server bằng iptables, quan sát trực tiếp cơ chế chống split-brain của Raft hoạt động (chỉ một phía có majority mới có thể có leader, phía thiểu số không thể commit write). Giả lập disk I/O chậm (ảnh hưởng fsync mà Raft phụ thuộc), quan sát commit latency tăng lên qua dashboard đã dựng ở ngày 32.

Checkpoint: tự mắt chứng kiến lý thuyết Raft học ở ngày 2 biểu hiện thành hiện tượng cụ thể trong hai bài test này, ghi chép lại làm tài liệu tham khảo.

Tuần 9 - Đào sâu nâng cao, ngoài phạm vi kỳ thi

Ngày 39 - Đọc mã nguồn chọn lọc

Clone repository hashicorp/consul. Đọc package agent/consul/fsm (Finite State Machine, nơi áp dụng Raft log entry vào state). Đọc package agent/consul/state (in-memory store dùng thư viện go-memdb).

Checkpoint: nắm được luồng tổng quát: một write request đến server, được leader append vào Raft log, sau khi majority replicate thành công thì FSM Apply được gọi, cập nhật vào state store - không cần hiểu chi tiết từng dòng code, chỉ cần nắm đúng luồng này.

Ngày 40 - Tuning hiệu năng

Đọc: tài liệu về sizing server, tham số raft_multiplier, yêu cầu disk IOPS.

Lab: benchmark độ trễ fsync trên đĩa của máy lab (dùng công cụ như fio), đối chiếu với khuyến nghị chính thức của HashiCorp.

Checkpoint: giải thích chính xác vì sao Consul server cần chạy trên đĩa SSD tốc độ cao và không nên chia sẻ host với workload I/O nặng khác - vì mỗi lần commit Raft log đều yêu cầu fsync xuống đĩa, nếu đĩa chậm sẽ trực tiếp làm chậm toàn bộ write throughput của cluster.

Ngày 41 - So sánh kiến trúc với các giải pháp khác

Tìm hiểu tổng quan kiến trúc Istio, Linkerd, Cilium ở khía cạnh service mesh, và etcd, Eureka ở khía cạnh service discovery thuần túy.

Checkpoint: chuẩn bị sẵn một câu trả lời có cấu trúc, dựa trên hiểu biết đã tích lũy (không phải học vẹt), cho câu hỏi "vì sao chọn Consul thay vì Istio hoặc etcd" trong một tình huống thiết kế hệ thống cụ thể.

Ngày 42 - Consul-Terraform-Sync và HCP Consul

Đọc: network infrastructure automation documentation, tổng quan Consul-Terraform-Sync, tổng quan HCP Consul (bản quản lý bởi HashiCorp).

Checkpoint: giải thích một use case cụ thể mà Consul-Terraform-Sync giải quyết (ví dụ tự động cập nhật rule firewall khi số lượng instance của một service thay đổi), và nêu được ít nhất hai tiêu chí quyết định khi nào nên dùng bản managed (HCP) thay vì tự vận hành.

Ngày 43 - Tổng kết

Lab: viết lại toàn bộ kiến trúc đã học thành một tài liệu hoàn chỉnh của riêng mình, từ Raft và gossip ở tầng nền tảng, đến service mesh, ACL, gateway, multi-datacenter - trình bày sao cho một người chưa biết gì về Consul có thể đọc và hiểu được cơ chế hoạt động cốt lõi.

Checkpoint cuối cùng: nếu giải thích được cho người khác không có nền tảng mà họ thực sự hiểu, không chỉ nhớ thuật ngữ, thì đã đạt mục tiêu ban đầu.