借助 Calico,管窥 Kubernetes 网络策略
Kubernetes 提出了一系列 CXI 的标准容器接口,其中的 CNI 以插件方式支持多种网络。 新 增的 networkpolicy API 对象,提供了对网络策略的支持,本文以 Calico 为例,实际操作一个网络策略的创建和测试。
环境准备
- 一个 Kubernetes 集群
- Kubelet 和 API Server 都开启了
--allow_privileged=true
- Kubelet 指定使用 CNI :
--network-plugin=cni
- 为了避免某些不可描述的网络设施的影响,建议下载几个镜像
- quay.io/calico/node:v1.0.2
- calico/cni:v1.5.6
- calico/kube-policy-controller:v0.5.2
- calico/ctl:v1.0.2
运行 Calico
- 下载
http://docs.projectcalico.org/v2.0/getting-started/kubernetes/installation/hosted/calico.yaml
- 如果用私库镜像,需要修改其中的几个镜像地址
- 修改
data/etcd_endpoints
的数据为可访问的 etcd 的地址。
kubectl create -f calico.yaml
这里在 kube-system 中创建了一个 DaemonSet 和一个 Deployment,分别用于提供 CNI 支持和网络策略支持。
$ kubectl get deployment,daemonset,svc --all-namespaces [9:55:14] NAMESPACE NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE kube-system deploy/calico-policy-controller 1 1 1 1 10h NAMESPACE NAME DESIRED CURRENT READY NODE-SELECTOR AGE kube-system ds/calico-node 2 2 2 <none> 10h NAMESPACE NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE default svc/kubernetes 172.200.0.1 <none> 443/TCP 19h default svc/nginx 172.200.183.204 <none> 80/TCP 9h
网络策略
为测试效果,我们首先创建一个 Namespace
kubectl create ns policy
然后是 Nginx 部署和服务:
--- kind: ReplicationController apiVersion: v1 metadata: name: nginx labels: name: nginx spec: replicas: 1 selector: name: nginx template: metadata: labels: name: nginx app: nginx spec: containers: - name: nginx image: nginx ports: - containerPort: 80 protocol: TCP --- kind: Service apiVersion: v1 metadata: name: nginx labels: name: nginx spec: ports: - protocol: TCP port: 80 targetPort: 80 selector: name: nginx
然后我们用 alpine 镜像测试一下对这一服务进行访问:
kubectl run alpine --rm -it --image=alpine sh
运行成功后,在 Alpine 的 Shell 中输入:
wget -O - -T 5 http://nginx
会出现 Nginx 的缺省页面的代码。
接下来我们给 Default Namespace 加一个缺省拒绝访问的注解:
$ kubectl annotate ns default "net.beta.kubernetes.io/network-policy={\"ingress\": {\"isolation\": \"DefaultDeny\"}}"
重复测试过程,会发现超时错误。
我们来创建一条策略:
kind: NetworkPolicy apiVersion: extensions/v1beta1 metadata: name: access-nginx spec: podSelector: matchLabels: run: nginx ingress: - from: - podSelector: matchLabels: access: "true"
很容易理解,对于符合 “run=nginx” 的 Pod,只有 “access=true” 的 Pod 能够访问
给 Alpine 带上标签重新运行:
kubectl run alp --image=alpine --labels="access=true" --rm -ti sh
重新 wget,会发现访问能力已经恢复。
本文主要线索来自官方示例:https://kubernetes.io/docs/getting-started-guides/network-policy/walkthrough/
安装方法来自 Calico 官网。
这只是一个很入门的介绍,后续会有更多进一步的尝试。
本文转自中文社区-借助 Calico,管窥 Kubernetes 网络策略

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Kubelet无法访问rancher-metadata问题分析
引言 Rancher能够支持Kubernetes,可以快速几乎无障碍的拉起一套K8s环境,这对刚入门K8s的小 白来 说简直是一大利器。当然由于系统特性五花八门,系统内置软件也相互影响,所以有时候伙伴们会碰到比较难缠的问题。本文就分析一下关于kubelet无法访问rancher-metadata问题。 问题现象 使用Rancher部署K8s后,发现一切服务状态均正常,这时候打开K8s dashboard却无法访问,细心得查看会发现,dashboard服务并没有部署起来,这时下意识的行为是查看kubelet的日志,此时会发现一个异常: 你会发现kubelet容器内部一直无法访问rancher-metadata,查看rancher-k8s-package源码,kubelet服务启动之前需要通过访问rancher-metadata做一些初始化动作,由于访问不了,便一直处于sleep状态,也就是出现了上面提到的那些异常日志的现象: 同样,在github上也能看到类似的issue:https://github.com/rancher/rancher/issues/7160 排查分析 进入kube...
- 下一篇
Kubernetes 集群资源的那些事
大多数时候,我们在跟 K8S 玩耍的时候,主要目的就是:“把 XXX 打个镜像,在集群上跑起来 ——— 诶快看,真的跑起来了嘿!”。 Kubernetes 和 Docker 的缺省配置,就能够帮我们省却很多麻烦。不过大家都很清楚,资源问 题是无法回避的,我们在传统 IT 环境下遇到的各种资源相关问题,在容器集群环境下一样要得到解决,多租户动态分配环境下,这些问题会更加复杂。 本文仅是一个索引,不准备也没能力做过多的深入,只是将一些需要注意的内容罗列出来做一些大致介绍。 有些内容称作资源可能并不是很恰当,暂时存在资源这个筐里吧。 磁盘 Volume 一般我们会用存储卷的方式来给 Pod 提供存储资源。 起初的存储卷,在用量的控制方面,只能借存储的实际提供者的能力来进行。例如可以限制 GlusterFS 中 Volume 的大小。 接下来出现了 Persistent Volume (PV) 和 Persistent Volume Claim (PVC) 这一组对象,完成了 “生产——消费” 关系,这就可以通过 Provision -> Claim 的方式,来对存储资源进行控制。 而最...
相关文章
文章评论
共有0条评论来说两句吧...