Ghi chú YAML | 06:18

Cập nhật

06:18 - 09/05/2026

Lượt xem

2,819

Lần sửa

Dung lượng

0 Dòng / 26373B

Cấu hình YAML

Chế độ đọc

Note chuẩn bị thi K8s.
purpose: mục đích
explore: khám phá
carry out: tiến hành
impacted: ảnh hưởng
reach the ETCD: truy cập vào ETCD
realized : nhận ra
aware: nhận thức
either: hoặc

Deployment - dùng build app vì không cần cố định/ Statefulset dùng build database vì cần cố định, PVC cố định.
Muốn biết pod đó đang chạy rì. kubectl describe pod -n <namespace> <name-pod> | grep -i -A By (ControlledBy:)
#ETCD:
etcd: lưu database của k8s (config, file..v.v.). Nhận thông tin từ Kube Controller, gửi nhận qua API
Kube Controller: 
- health check node
- 5s/ check 
- 40s không nhận phản hồi --> Not Ready
- Sau 5 phút, control sẽ đuổi pod khỏi node đó

Port 2379 = cổng để các thành phần control plane (API server, scheduler, controller...) nói chuyện với etcd
Port 2380 = cổng để các node etcd nói chuyện với nhau

Kube Scheduler:
- Filter Nodes: loại bỏ những node không đáp ứng điều kiện của Pod.
- Rank Nodes: Ưu tiên resource để cho pod vào node đó
Resource/ Taints/ Tolerations..v..v...

##Kubelet:
Là endpoint nhận việc từ trên.
Đăng ký node / Tạo pod / Monitor node&pod
Nếu câu hỏi có các từ khóa:

“node”
“pod không chạy”
“runtime”
“volume mount”
“probe”
“container lifecycle”
--> Nghĩ ngay tới kubelet vì kubelet là thằng thao tác trực tiếp Pod trong node.

Labels:
Tên nhãn của pod

Selector:
Bộ lọc filter giúp kết nối pod

kubectl expose giúp tạo 1 service gắn vào 1 pod/ deploymet/ replica đã có, gắn qua Labels selector
vd: kubectl expose deployment nginx-name --port=80 --target-port=8080 --type=ClusterIP
Trong đó service là port 80/ container port 8080

kubectl get pod/ all --selector env=prod
ex: lệnh này giúp filter pod có label env là prod

kubectl get pod --selector env=prod,bu=finance,tier=frontend
ex: filter nhiều labels cùng lúc

kubectl taint nodes node01 spray=mortein:NoSchedule
ex: tạo taints cho node
muốn cho pod chạy vào node01 hãy thêm giấy phép:

tolerations:
  - key: "spray"
    value: "mortein"
    operator: "Exists"
    effect: "NoSchedule"

Taints:             node-role.kubernetes.io/control-plane:NoSchedule
ex: Như này là không cho pod chạy vào node này

kubectl label nodes node01 color=blue
ex: gắn label cho node, sau đó muốn pod chỉ chạy trong node01 thì sửa yaml (sửa trong nodeAffinity) trong deployment/ statefulset.

Lưu ý khi copy nodeAffinity vào file yaml. Tạo deployment ra file yaml, sau đó thêm Affinity ở spec thứ 2/ thằng hàng containers.
Nếu đề bài có value thì operator: In, nếu không có value chỉ có key thì operator: Exists

Taint/Toleration = kiểm soát “được phép vào hay không”
Affinity = chọn “muốn chạy ở đâu”
nodeAffinity = Pod muốn chạy trên node nào
matchExpressions = điều kiện của node

ex: 
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: node-role.kubernetes.io/control-plane
                operator: Exists
            #   values:
            #   - ssd  
      containers:
      - image: nginx
        name: nginx
        resources: {}

Trang này để quick command: https://kubernetes.io/docs/reference/kubectl/quick-reference/#kubectl-autocomplete
 
Replicaset/ Demonset/ Deployment khi tạo cấu trúc sẽ là:
- Nếu node có labels --> selector phải match, không thì không tạo được pod
- Nếu node có taint thì phải match tolerations.
match labels --> match taint
 
DaemonSet dùng để mỗi node sẽ tạo 1 pod trên đó với điều kiện node đó không có labels hoặc taint. Nếu có phải tuân thủ theo node thì mới tạo được. Ứng dụng tạo pod: Network/ Log/ Monitoring..v..v..
 
Static Pod là tạo pod thủ công dựa trên file manifest, không thông qua API, tạo trực tiếp trên node, tạo trực tiếp bởi kubelet
 
Note: Vì kubelet là thằng trực tiếp tạo manifest yaml, nên muốn xoá cần check path gốc file đó đang được ở đâu.
1. Dùng kubectl get pod -o wide (check đang nằm ở node nào)
2. Tiếp dùng kubectl get node -o wide (check IP internal node đó)
3. Tiến hành ssh vào.
Check source gốc file manifest: /var/lib/kubelet/config.yaml (staticPodPath) --> tìm ra source gốc file manifest --> xoá. Quay lại controlpanel delete lại pod.
 
 
Namespace-scoped:
Pod
Deployment
Service
ConfigMap
Secret
 
Cluster-scoped (cấp toàn cluster)
Node 
Namespace 
PersistentVolume (PV) Storage cấp cluster
PriorityClass Định nghĩa priority dùng chung
ClusterRole / ClusterRoleBinding RBAC cấp cluster
CustomResourceDefinition (CRD) Định nghĩa resource mới
 
Preemption Policy: 
Pod priority cao đuổi Pod priority thấp ra khỏi node để lấy tài nguyên. Trừ khi preempt namespace-scoped: Nerver. 
Pod độ ưu tiên cao hơn sẽ phải chờ.
Set ở ns-scoped:
  priorityClassName: high-priority
  preemptionPolicy: Never
 
Thêm Priority trong 1 pod.
kubectl get pod {name_pod} -o yaml > {name_pod}.yaml
delete pod cũ
sửa file yaml, thêm Priority, nếu có value thì ẩn đi, rồi create lại.
 
Định nghĩa về Custom Scheduler:
Custom scheduler dùng chung binary kube-scheduler
Command gần giống nhau, khác ở --config và schedulerName (thằng này sau khai báo trong pod và sau spec, cùng hàng container).
Mỗi custom scheduler chạy như một Pod riêng
Pod chọn scheduler qua spec.schedulerName
Các scheduler không tranh nhau Pod
Có thể chạy nhiều instance và dùng leader election để HA
 
--> Scheduler xử lý nhiều Pod là chuyện bình thường — vấn đề chỉ xảy ra khi có nhiều scheduler cùng lúc.
 
Kubernetes Scheduler workflow:
 
Queue: Pod vào hàng đợi, sắp xếp theo priority.
Filter: Loại node không phù hợp (thiếu tài nguyên, sai label, taint…).
Score: Chấm điểm các node còn lại (tài nguyên, affinity, image…).
Select: Chọn node có điểm cao nhất.
Bind: Gán pod vào node (DefaultBinder).
 
→ Kết quả: Pod được chạy trên node phù hợp nhất.

spec.containers[*].image
spec.initContainers[*].image
spec.activeDeadlineSeconds
spec.tolerations

Resource:
Request: Cần nói bao nhiêu 
Mục đích để scheduler (thởi điểm tạo pod scheduler sẽ lấy nhiều tài nguyên nhất có thể) có thể gọi ở mức nào cho phép: Tránh OMM kill nếu vượt memory limit
Limits: Giới hạn bao nhiêu
Mục đích để resource tối đa được dùng
--> Dùng cả 2 thì pod sẽ được scheduler sắp xếp chính xác hơn.

RBAC (Authorization) chỉ kiểm tra bạn có quyền thực hiện action (tạo/sửa/xoá) hay không, không quan tâm nội dung YAML.
Sau đó, Admission Controller (Policy) là bước kiểm tra cuối, sẽ validate (từ chối) hoặc mutate (chỉnh sửa) resource để đảm bảo cấu hình đúng rule trước khi được tạo.

Bật/ tắt Admission Controllers trong kube-apiserver

**Khi thêm plugin trong kube-apiserver, set url trong config file (set đường dẫn thư mục yaml), sau đó phải set volume và mountVolume. (Tuỳ vào plugin mà cấu hình phù hợp)

kubectl get configmaps -A
 
  - hostPath:
      path: /etc/kubernetes/imgvalidation/
      type: DirectoryOrCreate
    name: imgvalidation
 
kubectl apply → API Server → (Authentication → Authorization) → Admission Controllers → etcd
Workflow: Request → Mutating (sửa request) → Validating (xác thực lại) → etcd
 
kubectl get pod {pod} -o yaml sẽ lấy trực tiếp etcd.
 
MutatingWebhookConfiguration cho phép webhook chỉnh sửa resource (như Pod) trước khi được tạo trong Kubernetes.
Webhook có thể thêm hoặc ghi đè field, không có rule mặc định ưu tiên cấu hình từ Pod.
Chỉ bị từ chối nếu webhook trả lỗi hoặc object sau khi mutate không hợp lệ/policy fail.
 
**Cách tạo: 
Bạn deploy một service (Deployment + Service) expose API HTTPS.
Trong MutatingWebhookConfiguration, bạn khai báo endpoint tới service đó.
Khi có request tạo/sửa resource, Kubernetes sẽ gọi HTTP(S) vào service này để lấy quyết định (mutate/allow/reject).
 
kubectl top pods/ node -A để check tài nguyên
 
Kubectl edit deployment frontend
Nếu thay đổi:
Recreate → KHÔNG có rollingUpdate (dưới strategy:) - tạo lại toàn bộ pod
RollingUpdate → CÓ rollingUpdate  (dưới strategy:) - tạo lại 1 pod
 
kubectl rollout history deployment frontend (check version update)
kubectl rollout undo deployment --to-revision=1 (roll back lai version 1)
 
Kube command:
command = chương trình chính bạn muốn chạy
args = tham số truyền vào chương trình đó
 
kubectl create configmap  webapp-config-map --from-literal=APP_COLOR=darkblue --from-literal=APP_OTHER=disregard
 
khi kubectl get pod -o yaml > pod.yaml để sửa file, hãy thêm ở - sau spec.containers:

kubectl create secret generic (tạo secret) tương tự configmap

**Cần load Env dùng envFrom - secretRef, còn load configmap dùng: envFrom - configMapRef

Multi-container Pod dùng khi cần chia sẻ tài nguyên, network nhanh, thường dùng lưu log, monitor, proxy..v..v.. 
Khi tạo mutil-container pod thì thêm lệnh command: ["sleep","1000"] vào container thứ 2
kubectl exec -it app -- /bin/sh để truy cập vào container trong pod
Container side-car (initContainers) là container phụ, chuyên để hỗ trợ container chính (app). Trong file yaml khi tạo thì dùng initContainers, bằng containers.
Thằng này thường chạy xong app hoặc command khi create pod, chạy xong sẽ dừng.
Nếu không có file manifest, hãy dùng kubectl get pod red -o yaml > red.yaml, sửa file yaml thêm initContainers (ngay trên status, ngang containers)

Skooner - công cụ monitor
Ingress = lớp định tuyến web (HTTP/HTTPS) vào Kubernetes cluster

kubectl scale deployment nginx-deployment --replicas=3
kubectl autoscale deployment nginx-deployment --max=3 --cpu=80%

Ưu điểm của HPA là scale theo resource hoặc metric nếu có
metrics-server là máy chủ đo lường toàn bộ resource hệ thống, HPA chỉ là quyết định scale.

kubectl events hpa nginx-deployment | check event hpa, thay cho check log

VPA CRDs = định nghĩa resource tùy chỉnh giúp Kubernetes hiểu và chạy được cơ chế autoscaling theo chiều dọc (tăng/giảm CPU, RAM) cho Pod.

kubectl get crds = xem danh sách tất cả “resource custom” đã được cài thêm vào Kubernetes cluster. (Extension cài ngoài như: VPA, ArgoCD, Prometheus…)

kubectl get vpa để check target CPU

kubectl drain --ignore-daemonsets xoá toàn bộ pod ra khỏi 1 node bao gồm daemonsets
(Lưu ý không dùng lệnh này cho Pod standalone/ staticpod vì xoá là mất sạch luôn, nên dùng deployment, statefulset)

kubectl cordon node01 (SchedulingDisabled- không nhận pod mới)

kubectl uncordon node01 (Bật lại scheduling, có thể nhận pod mới)

### UPGRADE
Chỉ update 1 version 1 lần, không nhảy bậc được
Update từng node 1, vd như controlplane đầu tiên:

Update controlplane từ v1.34 -> v1.35:
Đổi version /etc/apt/sources.list.d/kubernetes.list
Lấy key 1.35:
curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.35/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg

apt-cache madison kubeadm (để hiện ra version đã tải về)

*update kubeadm:
sudo apt-mark unhold kubeadm && \
sudo apt-get update && sudo apt-get install -y kubeadm='1.35.0-1.1' && \
sudo apt-mark hold kubeadm

kubeadm upgrade apply v1.35.0-1.1

*update kubelet:
sudo apt-mark unhold kubelet kubectl && \
sudo apt-get update && sudo apt-get install -y kubelet='1.35.0-1.1' kubectl='1.35.0-1.1' && \
sudo apt-mark hold kubelet kubectl

Update sang node khác, phải ssh vào node đó r cấu hình tương tự, vd: ssh node01

#Backup 
etcdctl --endpoints https://127.0.0.1:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key snapshot save /tmp/snapshot-pre-boot.db

#Restore
Step 1: Stop the kube-apiserver
move kube-apiserver.yaml ra tmp
mkdir dir backup, ex: /var/lib/etcd-bkup
(vứt tạm ra đây sau đó mount vào etcd)

etcdutl snapshot restore /opt/snapshot-pre-boot.db --data-dir /var/lib/etcd-bkup

Sửa file: 
/etc/kubernetes/manifests/etcd.yaml
Chỉnh path etcd-certs ở data-dir trên.

Restart kube-controller-manager & kube-scheduler & kubelet 
Cứ di chuyển ra ngoài xong lại di chuyển vào là xong trong /etc/kubernetes/manifests/

systemctl restart kubelet

Check: kubectl get deployments,services -A

openssl x509 -in /etc/kubernetes/pki/apiserver.crt -text | grep api (để check CN)
127.0.0.1:2379 là tới pod của etcd
 tls: failed to verify certificate: x509: cert --> cert sai

#CSR:
Key seach: Encode CSR
convert sang base64, thay vào code mã hóa request trong CertificateSigningRequest --> apply --> kubectl get csr --> kubectl certificate approve akshay

kubectl get csr agent-smith -o yaml để check chi tiết cert
kubectl certificate deny agent-smith để deny cert request tới
kubectl delete csr agent-smith để xóa cert

kubectl config set-context dev-context --cluster=test-cluster-1 --user=dev-user
  #Tạo context cho user mới
my-kube-config file as the default kubeconfig file --> export KUBECONFIG=/root/my-kube-config

kubectl auth can-i list pod --as dev-user: Check dev-user có quyền list pod không

# Tạo role + rolebinding
Role: Được phép làm gì/ Rolebinding: Được phép làm ở đâu, resource hay user nào.

Tạo role:
kubectl create role developer --verb=create --verb=list --verb=delete --resource=pods --namespace=default --dry-run=client -o yaml > role-developer.yaml
(--resource-name=anotherpod --verb=get) thêm 2 field này để check detail 1 pod.

Gắn role:
kubectl create rolebinding --namespace=default dev-user-binding --role=developer --user=dev-user --dry-run=client -o yaml > role-binding-dev-user.yaml

Kiểm tra các tài nguyên không thuộc namespace: 
kubectl api-resources --namespaced=false

#Cluster role: Tương tự role:
kubectl create clusterrole storage-admin --verb=get,list,watch --resource=persistentvolumes,storageclasses --dry-run=client -o yaml > roles-2.yaml

kubectl create clusterrolebinding michelle --clusterrole=storage-admin --user=michelle --dry-run=client -o yaml > cluster-roles-2.yaml

Tóm tắt chính: ServiceAccount: tạo tài khoản
Role: Tạo role (list/get/delete/watch..v..v..) và resource cấp phép
RoleBinding: Để gắn Role và ServiceAccount

#ServiceAccount
kubectl create sa dashboard-sa để tạo.
Tách quyền truy cập API khỏi ServiceAccount mặc định: kubectl edit serviceaccount dashboard-sa -n default --> thêm: automountServiceAccountToken: false
Thêm ServiceAccount vào deployment: kube edit deployment -->
spec.template.spec.serviceAccountName

#Secret docker: Dùng để pull những image private từ Docker.
key: pull image private registry
**Mindset:
spec.imagePullSecrets
= Pod → pull image → cần secret

kubectl create secret docker-registry... để tạo secret
pullImageSecret: metadata.spec.spec (ngang container)
  imagePullSecrets:
  - name: regcred

#Secret Context: 
**Mindset: 
securityContext = quyền của container
capabilities = quyền kiểu Linux (low-level)
add = cấp thêm quyền

key: security context
metadata.spec.containers: Trong container
    securityContext:
      capabilities:
        add: ["NET_ADMIN", "SYS_TIME"]
        
#Network
kubectl get netpol: Check policy Network
Ingress = Ai được vào ?  (incoming traffic)
Egress = Đi đâu (outgoing traffic)
NetworkPolicy = luật bảo vệ Pod, tách mạng riêng (giống security group / firewall)
Example egress (internal pod payroll và mysql):
**Mindset:
egress:
  - service A (podSelector + port)
  - service B (podSelector + port)
  - infra (DNS, etc.)

Check thử xem network mạng nội bộ có đúng không:
kubectl exec -it frontend -- curl -m 5 172.17.0.5 (Đứng từ pod 1 curl sang IP pod 2 internal)

Key search: Struggling with Network Policy

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: internal-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      name: internal (labels của pod)
  policyTypes:
    - Egress
  egress:
    - to:
      - podSelector:
          matchLabels:
            name: payroll (labels của service)
      ports:
      - protocol: TCP
        port: 8080
    - to:
      - podSelector:
          matchLabels:
            name: mysql (labels của service)
      ports:
      - protocol: TCP
        port: 3306
    - ports:
      - protocol: UDP
        port: 53
      - protocol: TCP
        port: 53
        
#CR và CRD
CR match CRD dựa vào:
apiVersion (group/version) + kind. Trong đó:
CRD = định nghĩa loại resource
CR = khai báo trạng thái mong muốn
Controller = thực thi để đạt trạng thái đó

#PV và PVC
key search: Volume
Trong container là mountpath/ ngoài container là hostpath, ghi nhớ để mount đúng.

key search: Create PV --> copy file manifest yaml
Reclaim Policy:
Retain → giữ dữ liệu (an toàn, cần xử lý tay). Khi xoá PVC thì dữ liệu vẫn còn ở PV nên không lo mất.
Delete → xóa luôn storage (VD: xóa disk trên cloud).
Recycle (deprecated) → xóa dữ liệu rồi reuse (ít dùng).

key search: Persistent Volumes
Cách mount: Tạo PV và PVC. Tạo PV trước (storage cấp, quyền, path trong Cloud), sau đó tạo PVC tương tự (storage cấp, quyền hạn, path trong Container). Điều kiện mount
**Dung lượng cấp và storageClassName phải giống nhau
**AccessMode nếu set ReadWriteMany thì PV và PVC sẽ tự động match nhau.
**Muốn chỉ định PVC match dính PV thì trong manifest PVC phải khai báo thêm: volumeName

storageClass: Là cách tạo/ rule liên quan PVC. Vd: Bindmode: WaitForFirstConsumer - PVC phải gắn vào pod thì mới hoạt động, sau khi mount xong pvc status từ Pending --> Bound.
Immediate - tạo ngay PV ngay khi tạo xong PVC. 
Trong đó: PROVISIONER nhuw driver của StorageClass, ví dụ: no-provisioner giúp volume delay cho đến khi được mount vào pod.
RECLAIMPOLICY: Delete: Xoá ngay PV khi xoá PVC, Retain: Xoá PVC thì dữ liệu vẫn còn PVC.
ALLOWVOLUMEEXPANSION: False: Không cho phép resize volume. True: Cho phép.

#Check network của 1 node: 
Check internal IP node (-o wide) --> ip a để check thêm interface/ ipv6 dựa vào ip. Thường sẽ đứng ở control-plan, nếu ở node khác thì ssh vào check.
eth0 → network chính của node
lo → loopback
docker0 → nếu dùng Docker
cni0 → bridge cho container

#CNI: Mạng nội bộ trong k8s.
CNI (Container Network Interface) = bộ quy tắc Kubernetes dùng để “nói chuyện” với hệ thống mạng
Flannel / Calico / Cilium / Weave: = các plugin thực tế implement CNI đó
Đảm bảo Pod giao tiếp được:
Pod ↔ Pod
Pod ↔ Service
Pod ↔ Internet (tuỳ cấu hình)

CNI binary path: /opt/cni/bin/
CNI plugin path: /etc/cni/net.d/ (để xem đang dùng loại mạng nào)

Kubernetes có resource NetworkPolicy
NHƯNG nếu CNI (vd: Flannel) không support → policy KHÔNG có tác dụng. Còn CNI plugin: Calico hoặc Cilium thì hỗ trợ.

Để xoá Flannel CNI của 1 node, phải xoá hết resource như configmap, daemonset, replica, deployment. 
Sau đó xoá path: /etc/cni/net.d/

Check cidr range của cluster node. Cách 1: Check dùng cni plugin gì --> kubectl logs <name-plugins> | grep cidr
Cách 2: Vào path manifest kube-controller-manager | grep cidr
Check cidr range service: kubectl get servicecidrs.networking.k8s.io kubernetes

Corefile sử dụng configmap để pass vào CoreDNS.
Check root domain: kubectl describe cm -n kube-system coredns

#Service và DNSCore
Sai DB_HOST → tìm service MySQL bằng kubectl get svc -A | grep mysql để lấy service-name + namespace.
Sửa DB_HOST thành <service-name>.<namespace>.svc.cluster.local (hoặc service.namespace nếu muốn ngắn).

ClusterIP: gọi qua DNS/IP nội bộ, khác namespace vẫn gọi được nếu dùng FQDN.
NodePort: gọi qua NodeIP:Port, không liên quan namespace (ai cũng truy cập được nếu network cho phép).

Muốn xem service đang match pod nào, check theo selector và labels. Hoặc: kubectl get endpoints <name-service> xem có match với internal ip pod không.

Khi Ingress khi request không match bất kỳ path nào trong Ingress. --> mặc định: default backend service

Luồng tóm tắt: Request --> ALB --> Ingress --> Service --> Pod

Tạo HTTPS thì cần: secret (chứa key và crt) + service + pod or deployment. Khai báo namespace ingress cùng với service + pod.
Sử dụng: Annotations: ssl-redirect nếu muốn chuyển sang https.
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/ssl-redirect: "false"

Ingress: 
Client → Ingress Controller (Nginx/Traefik…) → Ingress resource (rules) → Service → Pod

Gateway API: 
Client → Gateway → HTTPRoute → Service → Pod

example Gateway: Nghĩa là lắng nghe port 80 từ Internet và cho phép Route tới all Namespaces.
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: nginx-gateway
  namespace: nginx-gateway
spec:
  gatewayClassName: nginx
  listeners:
  - name: http
    protocol: HTTP
    port: 80
#    hostname: "www.example.com"
    allowedRoutes:
      namespaces:
        from: All

example HTTPRoute: Nghĩa là nhận traffic từ Gateway, đẩy vào service đã tạo.
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: frontend-route
  namespace: default
spec:
  parentRefs: (Map với Gateway đã tạo trước đó)
  - name: nginx-gateway
    namespace: nginx-gateway
#  hostnames:
#  - "www.example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs: (Map mới service đang chạy port)
    - name: frontend-svc
      port: 80

Ingress = all-in-one (vừa mở cổng vừa route)
Gateway API = tách ra rõ ràng, control tốt hơn

#Helm
Chart: Một "gói" chứa toàn bộ template YAML của một ứng dụng
Release: Một instance đã được deploy từ Chart lên cluster
Values: File cấu hình (values.yaml) để tùy chỉnh Chart theo từng môi trường
Repository: Kho lưu trữ các Chart (giống Docker Hub nhưng cho Helm)

helm repo add <name> <url>
helm repo update
helm search repo <keyword>

# Xem values trước khi cài
helm show values <chart>

# Cài / Upgrade
helm install <name-helm> <chart> -n <namespace> --values values.yaml
helm upgrade <name-helm> <chart> -n <namespace> --set key=value
name-helm = helm list
chart = helm search repo
helm repo list (check repo local)

# Debug lỗi (quan trọng!)
helm install --dry-run --debug     # Test trước khi cài
helm status <release> -n <ns>
helm get manifest <release> -n <ns>

# Rollback
helm rollback <release> <revision> -n <ns>
helm history <release> -n <ns>

# Gỡ cài
helm uninstall <release> -n <ns>
helm repo remove hashicorp

#Kustomize 
Gom toàn bộ resource vào 1 file kustomize.
cd vào thư mục đó, dùng command: kustomize create để tạo ra kustomization.yaml --> copy resources: cần gộp
ex: 
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - db/db-config.yaml
  - db/db-depl.yaml
  
Kustomize – 2 cách tạo resources:
cd vào thư mục đó, dùng command: kustomize create để tạo ra kustomization.yaml 
1. Root khai báo trực tiếp YAML
resources:
  - deployment.yaml
  - service.yaml
- Đơn giản.
- Hợp project nhỏ.
2. Root gọi folder con có kustomization riêng
# root
resources:
  - app/
  - db/
# app/kustomization.yaml
resources:
  - deployment.yaml
  - service.yaml

- Modular, dễ scale.
- Hợp project lớn/nhiều service.
Muốn update resource bằng Kustomize, có thể cấu hình ở kustomization.yaml tại root directory hoặc sub directory.

# Update image trong scope kustomization hiện tại
images:
  - name: nginx
    newName: nginx
    newTag: "1.4.0"
resources: load resource gốc
patches: ghi đè / bổ sung field mà không sửa file gốc
Field trùng → patch override
Field không có trong patch → giữ nguyên từ resource gốc
resources:
  - ../../base
  - redis-depl.yaml

patches:
  - path: api-patch.yaml

Xóa container bằng $patch: delete

spec:
  template:
    spec:
      containers:
        - name: memcached
          $patch: delete

Check label/selector:

Xem file YAML gốc
Xem kustomization.yaml
Xem các file patch nếu có override label/selector

# Dùng replace để thay field bằng JSON6902 patch
patches:
  - target:
      kind: Deployment
      name: api-deployment
    patch: |-
      - op: replace
        path: /spec/template/spec/containers/0/image
        value: caddy
op: replace → thay giá trị field
path → đường dẫn field cần sửa
value → giá trị mới

#So sánh resources vs patches vs components.
resources = load resource YAML gốc vào Kustomize
→ dùng để thêm Deployment, Service, ConfigMap...
resources:
  - deployment.yaml
  - service.yaml
patches = sửa resource đã tồn tại trong resources
→ override/update field mà không sửa file gốc
patches:
  - path: deployment-patch.yaml
components = gom các cấu hình dùng chung để tái sử dụng nhiều nơi
→ thường dùng cho logging, monitoring, sidecar, common label...
components:
  - ../../components/logging

Flow:

Load resources
Apply components
Apply patches

Xác thực