How to configure access limitation for a Kubernetes Pod

This blog provide a guideline how to restrict pod communication using Network Policies on AWS EKS cluster.

About Network Policy

We will use network policy feature of Kubernetes.

A network policy is a specification of how groups of pods are allowed to communicate with each other and other network endpoints.
By default, the pod’s communication is open within themselves and other endpoints. In a production-level cluster, it is not secure to have an open pod to pod communication.

In order to implement network policies in your cluster, you must use a compatible container network plugin and Calico is one of the compatible technology.

For more information, Network Policies

Calico on your Amazon EKS cluster

Project Calico is a network policy engine for Kubernetes.

  1. Apply the Calico manifest from the aws/amazon-vpc-cni-k8s GitHub project. This manifest creates DaemonSets in the kube-system namespace.
kubectl apply -f https://raw.githubusercontent.com/aws/amazon-vpc-cni-k8s/release-1.5/config/v1.5/calico.yaml
  1. Watch the kube-system DaemonSets and wait for the calico-node DaemonSet to have the DESIRED number of pods in the READY state. When this happens, Calico is working.
kubectl get daemonset calico-node --namespace kube-system

NAME          DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR                 AGE
calico-node   1         1         1       1            1           beta.kubernetes.io/os=linux   27m

To uninstall Calico

kubectl delete -f https://raw.githubusercontent.com/aws/amazon-vpc-cni-k8s/release-1.5/config/v1.5/calico.yaml

For more information from AWS Installing Calico on Amazon EKS

Create Network Policies to restrict access to your pod

Create manifest file

Please check and update correct value for your access source pod in target-sample-pod-network-policy.yaml

Temporarily, let say it’s name is source-sample-pod.

target-sample-pod-network-policy.yaml

# Deny all access to target-sample-pod
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-to-target-sample-pod
  namespace: default # namespace of target-sample-pod
spec:
  podSelector:
    matchLabels:
      # labels of target-sample-pod
      app: target-sample-pod
      release: target-sample-pod
  policyTypes:
    - Ingress

---
# Allow only access from specified Pod
# Web application API Pod
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-source-sample-pod-to-target-sample-pod
  namespace: default # namespace of target-sample-pod
spec:
  podSelector:
    matchLabels:
      # labels of target-sample-pod
      app: target-sample-pod
      release: target-sample-pod
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              # labels of source-sample-pod pod
              # please update with your label values
              app: source-sample-pod
      # Optional - using when restrict access to a specified port
      ports:
        - protocol: TCP
          port: 8080 # port of target-sample-pod

Create network policy

Use kubectl to create a NetworkPolicy from the above api-server-task-policy.yaml file:

kubectl apply -f kubernetes/target-sample-pod-network-policy.yaml

Please note that it may take 10 seconds to be effected.

Verification

You should see the following:

  • We cannot access target-sample-pod pod from another pod
  • source-sample-pod can now access target-sample-pod pod (on TCP port 8080 only).

Verify that we can not access from another pod

kubectl run --generator=run-pod/v1 busybox --rm -ti --image=busybox -- /bin/sh

/ # wget --spider --timeout=1 target-sample-pod:8080
Connecting to target-sample-pod:8080 (172.20.238.20:80)
wget: download timed out
/ #

Verify that we can access from pod with correct label app: source-sample-pod

kubectl run --generator=run-pod/v1 busybox --rm -ti --labels="source-sample-pod" --image=busybox -- /bin/sh

/ # wget --spider --timeout=1 target-sample-pod:8080
Connecting to target-sample-pod:8080 (172.20.238.20:80)
remote file exists

How to delete network policy

kubectl delete -f kubernetes/target-sample-pod-network-policy.yaml

Reference

Ghi nhớ về Types of Parallelism in Distributed Training ML/DL

TensorFlow now supports distributed training. From https://www.kdnuggets.com/2016/03/distributed-tensorflow-arrived.html

Ghi chú lại những phần về xử lý Parallelism Distributed Training trong ML, DL

Mục tiêu của xử lý Parallelism

  • Speedup: Giảm thời gian training bằng cách sử dùng đồng thời nhiều node/GPUs
  • Efficiency: Sử dụng hiệu quả cấu hình cluster, tận dụng tối đa năng suất của hardware GPUs/CPUs/Nodes
  • Scalability: Cho phép tăng giảm cấu hình hệ thống linh hoạt hơn

Types of parallelism

Để đạt được mục tiêu phân tán các training step thì có 2 cách chính: Model parallelismData parallelism. Tùy theo yêu cầu của application mà lựa chọn cách implement phù hợp hoặc có thể kết hợp cả 2

Ví dụ,

  • Model parallelism: trong DL thì các layer khác nhau của model có thể được train song song trên nhiều GPU khác nhau
  • Data parallelism: là việc phân chia nhỏ training sample thành nhiều phần nhỏ và thực hiện từng xử lý đồng thời training giống nhau đối với từng phần trên nhiều GPU khác nhau.

Data parallelism

Trong cách này thì dữ liệu training sẽ được chia được chia làm nhiều subset nhỏ, mỗi subset sẽ được train trên 1 một worker node.
Ở cuối mỗi training batch, sẽ có xử lý để đồng bộ (synchronize) parameter (gradients) giữa các process trên các worker.

Screenshot from: https://www.youtube.com/watch?v=bRMGoPqsn20

Điểm mạnh của cách làm này là có thể tối ưu hóa được tỷ lệ chia dữ liệu đầu vào để tăng tốc. Hơn nữa, thì cách làm này yêu cầu ít communication cost giữa các node hơn.

Nên cách này thường được dùng trong trường hợp muốn speedup các bài toán CNN với dataset lớn.

Model parallelism (còn gọi là Network Parallelism)

Model sẽ được chia ra làm nhiều phần khác nhau (mỗi phần có thể có 1 hoặc nhiều layer) và mỗi phần sẽ được train độc lập trên cùng một tập dữ liệu ở nhiều node khác nhau.
Cách này thường được áp dụng trong trường hợp model lớn phức tạp có quá nhiều node, hoặc node quá lớn mà một work node, GPU không thể xử lý hết.

Theo mình thấy thì việc phân chia tập giữ liệu và train với cùng model trên nhiều worker node sẽ dễ dàng hơn rất nhiều so với cách tách algorithm thành nhiều phần để xử lý song song. Có lẽ thế nên implementation cho approach Data parallelism nhiều hơn ví dụ như Estimator/MirroredStrategy, Horovod

Về distribute cũng thế, data lớn không có nghĩa là phải distributed, quan trọng là model (số node, số parameters trong model) có lớn hay không. Nếu số node lớn đến nỗi nó ko fit vào memory của 1 GPU thì cần distributed còn nếu số node ít mà dataset lớn thì chỉ cần chia batch chạy train trên 1 GPU vẫn được vừa tiết kiệm chi phí, vừa đỡ phải nghĩ code để distributed training

Túm lại, là tùy theo bài toán thực tế và chi phí mà áp dụng parallel hay distribute.

Tham khảo:
https://towardsdatascience.com/distributed-tensorflow-using-horovod-6d572f8790c4

https://d2l.ai/chapter_computational-performance/multiple-gpus.html