共计 3653 个字符，预计需要花费 10 分钟才能阅读完成。
在 Rainbond 集群中，每个团队对应于底层 Kubernetes 的一个 Namespace，因为之前应用的底层网络无奈进行 Namespace 级别的网络管理，所以在 Rainbond 同一集群下的不同团队间，所以组件能够自在的进行相互拜访，用户无奈对此做出任何限度，这也导致了底层网络的安全隐患始终存在。当初由 cilium 提供网络服务的 Kubernetes 集群能够很好的解决这一问题，用户能够依据本人的需要，制订针对每个团队、每个组件的网络策略，增强底层网络管理，实现网络层的平安把控。
应用 cilium 作为 Kubernetes 网络服务
-
应用从主机装置时，批改 network.plugin 值为 none
- 装置 helm
wget https://goodrain-pkg.oss-cn-shanghai.aliyuncs.com/pkg/helm && chmod +x helm && mv helm /usr/local/bin/- 部署 cilium
helm repo add cilium https://helm.cilium.io/
helm install cilium cilium/cilium --version 1.11.2 --namespace kube-system --set operator.replicas=1
kubectl get pods --all-namespaces -o custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,HOSTNETWORK:.spec.hostNetwork --no-headers=true | grep '<none>' | awk '{print"-n "$1" "$2}' | xargs -L 1 -r kubectl delete pod
- 验证 cilium
下载 cilium 命令行工具
curl -L --remote-name-all https://github.com/cilium/cilium-cli/releases/latest/download/cilium-linux-amd64.tar.gz{,.sha256sum}
sha256sum --check cilium-linux-amd64.tar.gz.sha256sum
sudo tar xzvfC cilium-linux-amd64.tar.gz /usr/local/bin
rm cilium-linux-amd64.tar.gz{,.sha256sum}- 确认状态
$ cilium status --wait
/¯¯\
/¯¯\__/¯¯\ Cilium: OK
\__/¯¯\__/ Operator: OK
/¯¯\__/¯¯\ Hubble: disabled
\__/¯¯\__/ ClusterMesh: disabled
\__/
DaemonSet cilium Desired: 2, Ready: 2/2, Available: 2/2
Deployment cilium-operator Desired: 2, Ready: 2/2, Available: 2/2
Containers: cilium-operator Running: 2
cilium Running: 2
Image versions cilium quay.io/cilium/cilium:v1.9.5: 2
cilium-operator quay.io/cilium/operator-generic:v1.9.5: 2- 测试网络联通性（国内服务器测试时，波及到内部网络的测试可能会失败，不影响失常应用）
$ cilium connectivity test
ℹ️ Monitor aggregation detected, will skip some flow validation steps
✨ [k8s-cluster] Creating namespace for connectivity check...
(...)
---------------------------------------------------------------------------------------------------------------------
📋 Test Report
---------------------------------------------------------------------------------------------------------------------
✅ 69/69 tests successful (0 warnings)
设置团队网络隔离
Cilium 的网络隔离策略遵循白名单机制，在不创立网络策略的状况下，对于网络不作任何限度，在为指定类型的 pod 汇合创立网络策略后，除策略中容许的拜访地址外，其它申请都会被回绝。
-
后期筹备
- 创立两个开发团队和测试团队，英文名称设置为 dev 和 test
- 在开发团队和测试团队下创立 nginx-dev 和 nginx-test 组件，开启对内端口，外部域名别离设置为 nginx-dev 和 nginx-test
- 在开发和测试团队下创立客户端组件
-
不做任何限度
在不做限度的状况下，各个团队之间的所有服务均能够自在通信，不受任何非凡限度
-
限度只容许本团队内组件相互拜访，断绝其它团队拜访
在理论生产中，一个集群外部可能会同时部署开发、测试、生产等多个团队，基于安全性的思考，须要对每个的团队做出网络隔离，禁止其它团队能够对其进行拜访，上面以开发团队为例阐明如何限度不容许其它团队对其拜访。
- Cilium 网络策略文件 (dev-ingress.yaml)
apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
name: "dev-namespace-ingress"
spec:
endpointSelector:
matchLabels:
"k8s:io.kubernetes.pod.namespace": dev
ingress:
- fromEndpoints:
- matchLabels:
"k8s:io.kubernetes.pod.namespace": dev- 创立策略
kubectl create -f dev-ingress.yaml -n dev- 确认策略
$ kubectl get CiliumNetworkPolicy -A
NAMESPACE NAME AGE
dev dev-namespace-ingress 39s- 测试成果
-
设置开发团队下的 nginx-dev 组件只容许测试团队下的组件拜访
在某些状况下，一些组件的平安要求会更为严格，可能只会容许本团队内符合要求的局部组件进行拜访，上面以 nginx-dev 为例阐明如何限度仅容许局部组件进行拜访。
- Cilium 网络策略文件 (nginx-dev-ingress0.yaml)
apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
name: "nginx-dev-ingress"
spec:
endpointSelector:
matchLabels:
name: grc156cb
ingress:
- fromEndpoints:
- matchLabels:
name: - 创立策略
kubectl create -f nginx-dev-ingress0.yaml -n dev- 确认策略
$ kubectl get CiliumNetworkPolicy -A
NAMESPACE NAME AGE
dev nginx-dev-ingress0 85s- 测试成果
-
设置开发团队容许本团队下组件拜访的同时，容许开发团队下的 nginx-dev 组件被测试团队中任意组件拜访
在设置了团队网络隔离的状况下，有时候须要长期凋谢一些组件给其它团队拜访以便进行调试，上面以 nginx-dev 组件为例阐明如何在设置网络隔离的状况下凋谢内部团队的拜访权限。
- Cilium 网络策略文件 (nginx-dev-ingress1.yaml)
apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
name: "nginx-dev-ingress1"
spec:
endpointSelector:
matchLabels:
name: grc156cb
ingress:
- fromEndpoints:
- matchLabels:
"k8s:io.kubernetes.pod.namespace": test- 创立策略
kubectl create -f dev-ingress.yaml -n dev
kubectl create -f nginx-dev-ingress.yaml -n dev- 确认策略
$ kubectl get CiliumNetworkPolicy -A
NAMESPACE NAME AGE
dev dev-namespace-ingress 19s
dev nginx-dev-ingress1 12s- 测试成果
