网站可以换主机吗,小程序推广公司,网站制作ppt模板,网络营销论文怎么写Photo #xff1a;Kubernetes文 | Edison Zhou本文已加入《.NET Core on K8S 学习与实践系列文章索引目录》#xff0c;点击查看阅读更多容器化相关文章#xff0c;希望对你有所帮助#xff01;Kubernetes网络模型我们都知道Kubernetes作为容器编排引擎#xff0c;它有一个… Photo Kubernetes文 | Edison Zhou本文已加入《.NET Core on K8S 学习与实践系列文章索引目录》点击查看容器化相关文章希望对你有所帮助Kubernetes网络模型 我们都知道Kubernetes作为容器编排引擎它有一个强大又复杂的网络模型也牵引出了Pod网络、Service网络、ClusterIP、NodePort、Ingress等多个概念。这里我们采用杨波老师架构师杨波模仿TCP/IP协议栈总结的一个K8S网络模型图来看看K8S的四个抽象层次从而了解一下K8S的网络。本小节的文字主要引用自杨波老师关于K8S网络模型的文章及CloudMan的《每天5分钟玩转Kubernetes》一书。 K8S网络层次模型图 From 波波老师 根据上图模型中展示的四个层次从0到3除了第0层每一层都是构建于前一层之上。 1第0层节点主机互通互联 主要保证K8S节点(物理或虚拟机)之间能够正常IP寻址和互通的网络这个一般由底层(公有云或数据中心)网络基础设施支持这里我们无需过多关心。 2第1层Pod虚拟机互联 在一个Pod中可以运行一个或多个容器且Pod中所有容器使用同一个网络namespace即相同的IP和端口空间可以直接用localhost通信而且还可以共享存储本质是通过将Volume挂载到Pod中的每个容器。 Pod网络模型图 From 波波老师 3第2层服务发现和负载均衡 在K8S集群中Pod的IP并不是固定的可能会频繁地销毁和创建实例为了解决此问题Service提供了访问Pod的抽象层。即无论后端Pod如何变化Service都作为稳定的前端对外提供服务。此外Service还提供了高可用和负载均衡的功能它负责将请求转发给正确的Pod。 Service网络模型图 From 波波老师 4第3层外部流量接入 K8s的Service网络只是一个集群内部网络集群外部是无法直接访问的。为此想要将应用暴露出去让公网能够访问K8S提供了两种方式 ① NodePort使Service通过Cluster节点的静态端口对外提供服务外部可以通过 NodeIP:NodePort 来访问Service。 Node Port方式示意图 From 波波老师 ② LoadBalancer使Service利用Cloud Provider提供的Load Balancer对外提供服务Cloud Provider负责将Load Balancer的流量导向Service。目前支持的Cloud Provider包括AWS、Azure、阿里云、腾讯云等。 Load Balancer方式示意图 From 波波老师More关于K8S网络的更多基本原理与讲解强力推荐阅读波波老师的以下文章Kubernetes网络三部曲-Pod网络From 杨波老师Kubernetes网络三部曲-Service网络From 杨波老师Kubernetes网络三部曲-外部接入网络From 杨波老师传说中的CNI规范 为了保证网络方案的标准化、扩展性和灵活性K8S采用了CNIContainer Networking Interface规范。CNI是一个Pod网络集成标准简化了K8S和不同Pod网络实现技术的集成。CNI最大的优点就是支持多种容器runtime而不仅仅是Docker。目前已经有多种支持K8S的网络方案包括 Flannel、Calico、Canal等它们都实现了CNI规范因此无论我们选择哪种具体方案它们的网络模型都是一致的。 CNI模型图More关于CNI的更多基本原理与讲解推荐阅读陈Sir的文章《K8S网络详解CNI与CNI网络模型》Network Policy关于Network Policy Network Policy是K8S的一种资源它使K8S可以通过Label选择Pod并指定其他Pod或外界如何与这些Pod通信。换句话说当Pod被定义了Network Policy时只有Policy允许的流量才能访问Pod默认情况下任何来源的流量都可以访问Pod是没有限制的即帮助K8S实现更为精细的流量控制实现租户隔离机制。 But并不是所有K8S网络方案都支持Network Policy比如Flannel就不支持而Calico是支持的。 下面我们就来实践一下Network Policy只要三步部署Canal 想要部署Canal需要切换网络方案这里我们使用最简单粗暴的方式重建当前K8S集群kubeadm reset # 在每个节点上执行一次然后重新对Master节点进行初始化kubeadm init \
--apiserver-advertise-address192.168.2.100 \
--image-repository registry.aliyuncs.com/google_containers \
--kubernetes-version v1.13.3 \
--service-cidr10.1.0.0/16 \
--pod-network-cidr10.244.0.0/16在两个Node节点上执行以下命令重新加入集群注意这里的token请填写你的Master节点初始化后的输出结果kubeadm join 192.168.2.100:6443 --token ekqxk2.iiu5wx5bbnbdtxsw \
--discovery-token-ca-cert-hash \
sha256:c50bb83d04f64f4a714b745f04682b27768c1298f331e697419451f3550f2d05最后通过以下命令部署Canal参考自K8S官方文档kubectl apply -f https://docs.projectcalico.org/v3.8/manifests/canal.yaml此时再次令验证的集群结果如下 1集群节点状态 2Pod状态 部署测试应用 这里通过一个httpd应用来演示Network Policy该应用的yaml定义如下apiVersion: apps/v1
kind: Deployment
metadata:name: httpd
spec:replicas: 3selector:matchLabels:name: networkpolicy-demotemplate:metadata:labels:name: networkpolicy-demospec:containers:- name: httpdimage: httpd:latestports:- containerPort: 80imagePullPolicy: IfNotPresent---kind: Service
apiVersion: v1
metadata:name: httpd-svc
spec:type: NodePortports:- protocol: TCPnodePort: 31000port: 8080targetPort: 80selector:name: networkpolicy-demo通过kubectl将其部署到K8S集群kubectl apply -f httpd-demo.yaml这时候三个httpd Pod已经成功Running 由于定义的是NodePort方式暴露服务这里我们在集群外部访问Service看看 由于当前并没有创建任何Network Policy这里我们可以通过创建一个Pod应用我们熟悉的busybox来验证一下是否可以在K8S集群内部随意访问该httpd应用kubectl run busybox --rm -it --imagebusybox /bin/sh从上图可以知道它可以正常访问到Service也可以正常ping到Pod节点。部署Network Policy有效性 现在我们创建一个Network Policy其配置文件yaml如下apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:name: access-httpd
spec:podSelector:matchLabels:name: networkpolicy-demoingress:- from:- podSelector:matchLabels:access: trueports:- protocol: TCPport: 80该Network Policy定义了如下规则 1应用于所有 label 为 name : networkpolicy-demo 的Pod这里即刚刚创建的三个httpd pod。 2ingress中定义了只有 label 为 access : true 的Pod才能访问应用。 3即使通过Policy也只能访问80端口 通过kubectl将其应用到K8S集群中kubectl apply -f networkpolicy.yaml下面再次在busybox pod中验证Network Policy的有效性 从上图中可以看到已经无法再成功访问Service也无法再ping通三个Pod节点。 这个时候集群外也无法再通过NodePort访问到Service 如果想要让测试Podbusybox能访问到应用了Network Policy的httpd应用我们可以对busybox pod加一个label(accesstrue)就可以kubectl run busybox --rm -it --imagebusybox \
--labelsaccesstrue /bin/sh运行后的验证结果如下可以访问到Service但Ping却被禁止 但是此时集群节点k8s-master与两个node与集群仍然无法访问到应用了Network Policy的httpd应用如果想要让它们也访问到则需要修改Network Policy做一个类似于开防火墙白名单的操作注意下面的ipBlock配置apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:name: access-httpd
spec:podSelector:matchLabels:name: networkpolicy-demoingress:- from:- podSelector:matchLabels:access: true- ipBlock:cidr: 192.168.2.0/24ports:- protocol: TCPport: 80再次应用到K8S集群后再来通过集群外部的访问者浏览器试试 可以看到已经可以正常访问啦小结 本文简单介绍了Kubernetes的4层网络模型、CNI 容器网络接口规范 和 Network Policy并通过改造K8S集群的网络配置从Flannel到Canal来验证Network Policy的有效性。对于Kubernetes的网络模型的原理与介绍强烈推荐阅读杨波老师的《Kubernetes网络三部曲》它的传送门位于下方的参考资料列表中。 最后码字不易也希望各位看官看完觉得还行就在本文右下方顺手点个“在看”就是对我最大的鼓励参考资料1CloudMan《每天5分钟玩转Kubernetes》 2李振良《一天入门Kubernets教程》 3马哥马永亮《Kubernetes快速入门》 4Liang《K8S CNI网络最强对比》 5杨波《K8S网络三部曲》 6陈Sir《K8S网络详解CNI与CNI网络模型》往期精彩回顾.NET Core on K8S学习与实践系列文章索引目录熊逸《唐诗必修50讲》学习笔记系列文章索引目录【重磅】2019 .NET China Conf 资料下载2019 .NET Conf China - 路一直都在社区会更好阿里云MVP第十期全球发布—让天下没有难做的技术基于Jenkins的开发测试全流程持续集成实践基于Jenkins Pipeline的ASP.NET Core持续集成实践恰童鞋骚年风华也许不再正茂但却仍想挥斥方遒。本公众号会长期关注和分享.NET CoreMicroserviceCloud NativeDevOps等技术内容文章还会与你分享个人生活成长的点滴及各类好书的读书笔记希望能对你有所帮助一起成长长按订阅更多精彩▼点个【在看】和更多人一起分享
