K8s网络概述:

前两种情况是在一个主机(Node)中通信,也就是docker里面涉及到的原理,这里不详细探讨。

情况1:一个pod的两个容器之间通信:

情况2:一个Node中的两个pod之间通信:

情况3:不同node之间的pod进行通信:

这种方式实现的方式有:

  1. 有的基于overlay网络实现;
  2. 有的基于vxlan实现;
  3. 有的基于openvswitch实现;
  4. 有的基于BGP实现。

说到容器就不能不提 CNI,CNI 作为容器网络的统一标准,让各个容器管理平台(k8s,mesos等)都可以通过相同的接口调用各式各样的网络插件(flannel,calico,weave 等)来为容器配置网络。容器管理系统与网络插件之间的关系图如下所示。

网络插件的解决方案:

  1. flannel—基于overlay 不支持网络策略;
  2. calico—基于BGP 支持网络策略;
  3. canal 支持网络策略。

各种网络解决方案的对比:

不管哪种解决方案,每个pod都有独立IP,可以直接通信,只是性能及配置的难易及是否支持网络策略有区别。

一、Calico网络通信原理:

实验环境:

其中,calico是以容器的方式存在。

步骤1: 搭建etcd集群
Calico的信息存储于etcd,首先需要搭建etcd集群。具体步骤请参考:
https://blog.csdn.net/tushanpeipei/article/details/118409836?spm=1001.2014.3001.5501

[root@vms204 ~]# etcdctl member list
193cd579a601f16a: name=etcd-204 peerURLs=http://192.168.0.204:2380 clientURLs=http://192.168.0.204:2379,http://localhost:2379 isLeader=false
591f7e324267e48a: name=etcd-205 peerURLs=http://192.168.0.205:2380 clientURLs=http://192.168.0.205:2379,http://localhost:2379 isLeader=true

步骤2: 安装docker,使用etcd来存储数据

分别设置etcd的地址,存储自己的数据,修改文件/usr/lib/systemd/system/docker.service
,在ExecStart=后加入etcd的内容即可。

[root@vms204 etcd]# vim /usr/lib/systemd/system/docker.service
--cluster-store=etcd://192.168.0.204:2379
[root@vms205 etcd]# vim /usr/lib/systemd/system/docker.service
--cluster-store=etcd://192.168.0.205:2379

在两个设备上restart docker:

systemctl restart etcd
systemctl daemon-reload ; systemctl restart docker

步骤3: 在两台设备上生成Calico的配置文件:

mkdir /etc/calico

进入目录下,创建并编辑calicoctl.cfg文件

[root@vms204 calico]# cat calicoctl.cfg
apiVersion: v1
kind: calicoApiConfig
metadata:
spec:datastoreType: "etcdv2"etcdEndpoints: "http://192.168.0.204:2379"[root@vms205 calico]# cat calicoctl.cfg
apiVersion: v1
kind: calicoApiConfig
metadata:
spec:datastoreType: "etcdv2"etcdEndpoints: "http://192.168.0.205:2379"

这里加载calico使用到的相关镜像,地址为:
https://download.csdn.net/download/tushanpeipei/20156748?spm=1001.2014.3001.5501
https://download.csdn.net/download/tushanpeipei/20156723
下载后导入到2台设备中。然后在两台设备上给calicoctl添加权限:

chmod +x calicoctl
mv calicoctl /bin/

在两台设备上加载镜像

[root@vms204 ~]# docker load -i calico-node-v2.tar
df64d3292fd6: Loading layer [==================================================>]  4.672MB/4.672MB
d6f0e85be2d0: Loading layer [==================================================>]  8.676MB/8.676MB
c9818c503193: Loading layer [==================================================>]  250.9kB/250.9kB
1f748fca5871: Loading layer [==================================================>]  4.666MB/4.666MB
714c5990d9e8: Loading layer [==================================================>]  263.9MB/263.9MB
Loaded image: quay.io/calico/node:v2.6.12
[root@vms205 ~]# docker load -i calico-node-v2.tar
df64d3292fd6: Loading layer [==================================================>]  4.672MB/4.672MB
d6f0e85be2d0: Loading layer [==================================================>]  8.676MB/8.676MB
c9818c503193: Loading layer [==================================================>]  250.9kB/250.9kB
1f748fca5871: Loading layer [==================================================>]  4.666MB/4.666MB
714c5990d9e8: Loading layer [==================================================>]  263.9MB/263.9MB
Loaded image: quay.io/calico/node:v2.6.12

步骤4: 建立Calico pod:

calicoctl node run --node-image=quay.io/calico/node:v2.6.12 -c /etc/calico/calicoctl.cfg

查看容器建立情况:

[root@vms204 calico]# docker ps
CONTAINER ID   IMAGE                         COMMAND         CREATED          STATUS          PORTS     NAMES
9c73a77f26eb   quay.io/calico/node:v2.6.12   "start_runit"   49 seconds ago   Up 48 seconds             calico-node
[root@vms205 calico]# docker ps -a
CONTAINER ID   IMAGE                         COMMAND         CREATED              STATUS              PORTS     NAMES
ea8f82ab22bb   quay.io/calico/node:v2.6.12   "start_runit"   About a minute ago   Up About a minute             calico-node

查看对方主机的信息:

[root@vms204 calico]# calicoctl node status
Calico process is running.IPv4 BGP status
+---------------+-------------------+-------+----------+-------------+
| PEER ADDRESS  |     PEER TYPE     | STATE |  SINCE   |    INFO     |
+---------------+-------------------+-------+----------+-------------+
| 192.168.0.205 | node-to-node mesh | up    | 08:03:17 | Established |
+---------------+-------------------+-------+----------+-------------+IPv6 BGP status
No IPv6 peers found.

步骤5: 在任意主机上创建网络(可以同步给远端)

docker network create --driver calico --ipam-driver calico-ipam calnet1

–driver calico 指定使用 calico 的 libnetwork CNM driver。
–ipam-driver calico-ipam 指定使用 calico 的 IPAM driver 管理 IP。
calico 为 global 网络,etcd 会将 calnet1 同步到所有主机。

查看网络建立情况:可以看到创建了一个名为calnet1的网络。

[root@vms204 calico]# docker network list
NETWORK ID     NAME      DRIVER    SCOPE
c21c6b680d2e   bridge    bridge    local
a820a4b2f07d   calnet1   calico    global
bffc445a376b   host      host      local
4f378dcf68c2   none      null      local

步骤6: 在两个设备上创建容器,使用calnet1网络,检查是否能够通信

[root@204 calico]# docker run --name c204 --net calnet1 -itd busybox
[root@205 calico]# docker run --name c205 --net calnet1 -itd busybox

进入容器,查看其网卡信息:

[root@vms204 calico]# docker exec -it c204 sh
/ # ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00inet 127.0.0.1/8 scope host lovalid_lft forever preferred_lft forever
4: cali0@if5: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueuelink/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ffinet 192.168.173.0/32 scope global cali0valid_lft forever preferred_lft forever[root@vms205 calico]# docker exec -it c205 sh
/ # ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00inet 127.0.0.1/8 scope host lovalid_lft forever preferred_lft forever
4: cali0@if5: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueuelink/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ffinet 192.168.242.64/32 scope global cali0valid_lft forever preferred_lft forever

可以看到两个容器上有一个ali0@if5的网卡。然后查看宿主机的网卡信息:

[root@vms204 calico]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00inet 127.0.0.1/8 scope host lovalid_lft forever preferred_lft foreverinet6 ::1/128 scope hostvalid_lft forever preferred_lft forever
2: ens32: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000link/ether 00:0c:29:64:4b:0e brd ff:ff:ff:ff:ff:ffinet 192.168.0.204/24 brd 192.168.0.255 scope global ens32valid_lft forever preferred_lft foreverinet6 fe80::20c:29ff:fe64:4b0e/64 scope linkvalid_lft forever preferred_lft forever
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWNlink/ether 02:42:a5:fb:5f:db brd ff:ff:ff:ff:ff:ffinet 172.17.0.1/16 brd 172.17.255.255 scope global docker0valid_lft forever preferred_lft forever
5: calibe0de8fc176@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UPlink/ether 92:e4:82:9a:33:b6 brd ff:ff:ff:ff:ff:ff link-netnsid 0inet6 fe80::90e4:82ff:fe9a:33b6/64 scope linkvalid_lft forever preferred_lft forever[root@vms205 calico]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00inet 127.0.0.1/8 scope host lovalid_lft forever preferred_lft foreverinet6 ::1/128 scope hostvalid_lft forever preferred_lft forever
2: ens32: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000link/ether 00:0c:29:1b:ea:ca brd ff:ff:ff:ff:ff:ffinet 192.168.0.205/24 brd 192.168.0.255 scope global ens32valid_lft forever preferred_lft foreverinet6 fe80::20c:29ff:fe1b:eaca/64 scope linkvalid_lft forever preferred_lft forever
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWNlink/ether 02:42:40:b1:a7:b1 brd ff:ff:ff:ff:ff:ffinet 172.17.0.1/16 brd 172.17.255.255 scope global docker0valid_lft forever preferred_lft forever
5: cali39e20803688@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UPlink/ether ae:5e:a1:f5:f9:c8 brd ff:ff:ff:ff:ff:ff link-netnsid 0inet6 fe80::ac5e:a1ff:fef5:f9c8/64 scope linkvalid_lft forever preferred_lft forever

可以看到,宿主机上也有一个calico生成的网卡,对比容器内和宿主机的calico网卡,我们可以发现,他们是配对的(if4配对if5,veth pair,可以理解为直连)。

检查两个pod是否能够通信:

[root@vms204 calico]# docker exec -it c204 sh
/ # ping 192.168.242.64
PING 192.168.242.64 (192.168.242.64): 56 data bytes
64 bytes from 192.168.242.64: seq=0 ttl=62 time=0.328 ms
64 bytes from 192.168.242.64: seq=1 ttl=62 time=0.241 ms
64 bytes from 192.168.242.64: seq=2 ttl=62 time=0.216 ms

步骤7: 分析流量转发流程
在vms204的容器中,pingvms205时,首先查看路由表:

/ # route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         169.254.1.1     0.0.0.0         UG    0      0        0 cali0
169.254.1.1     0.0.0.0         255.255.255.255 UH    0      0        0 cali0

可以看到,默认有一条默认路由,出接口为calico创建的接口。因此流量从接口出来,到达此宿主机与之配对的接口,然后再宿主机上查看路由表:

[root@vms204 calico]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.0.1     0.0.0.0         UG    0      0        0 ens32
169.254.0.0     0.0.0.0         255.255.0.0     U     1002   0        0 ens32
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 ens32
192.168.173.0   0.0.0.0         255.255.255.255 UH    0      0        0 calibe0de8fc176
192.168.173.0   0.0.0.0         255.255.255.192 U     0      0        0 *
192.168.242.64  192.168.0.205   255.255.255.192 UG    0      0        0 ens32

可以看到其上有一条去玩对端pod 192.168.242.64地址的路由,出接口为ens32,下一跳为192.168.0.205(VMS205的ens32的地址);由于两个节点是2层通信,不需要在外部再封装IP报头。将目的MAC设置为了VMS205的ens32的MAC地址,然后发送给VMS205。VMS205收到报文后可以看到目地址是192.168.242.64,查看路由表:

[root@vms205 calico]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.0.1     0.0.0.0         UG    0      0        0 ens32
169.254.0.0     0.0.0.0         255.255.0.0     U     1002   0        0 ens32
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 ens32
192.168.173.0   192.168.0.204   255.255.255.192 UG    0      0        0 ens32
192.168.242.64  0.0.0.0         255.255.255.255 UH    0      0        0 cali39e20803688
192.168.242.64  0.0.0.0         255.255.255.192 U     0      0        0 *

可以看到,有一条192.168.242.64的路由,出接口为calico接口,流量因此通过宿主机的calico接口发送到了其容器c205中,完成了单向的通信,echo reply报文回程类似。

返回到K8s中:


按照图示部署好了K8s集群,一个Master,两个worker nodes。在master设备上,可以看到如下的pods:

[root@vms201 ~]# kubectl get pods -n kube-system -o wide
NAME                                       READY   STATUS    RESTARTS   AGE    IP              NODE             NOMINATED NODE   READINESS GATES
calico-kube-controllers-78d6f96c7b-h6p86   1/1     Running   16         4d5h   10.244.58.229   vms202.rhce.cc   <none>           <none>
calico-node-hstwf                          1/1     Running   18         8d     192.168.0.201   vms201.rhce.cc   <none>           <none>
calico-node-ldfhc                          1/1     Running   24         8d     192.168.0.203   vms203.rhce.cc   <none>           <none>
calico-node-sdvzv                          1/1     Running   24         8d     192.168.0.202   vms202.rhce.cc   <none>           <none>
coredns-545d6fc579-596hb                   1/1     Running   18         8d     10.244.20.230   vms201.rhce.cc   <none>           <none>
coredns-545d6fc579-7mb9v                   1/1     Running   18         8d     10.244.20.229   vms201.rhce.cc   <none>           <none>
etcd-vms201.rhce.cc                        1/1     Running   21         8d     192.168.0.201   vms201.rhce.cc   <none>           <none>
kube-apiserver-vms201.rhce.cc              1/1     Running   14         4d2h   192.168.0.201   vms201.rhce.cc   <none>           <none>
kube-controller-manager-vms201.rhce.cc     1/1     Running   20         8d     192.168.0.201   vms201.rhce.cc   <none>           <none>
kube-proxy-28x9h                           1/1     Running   18         8d     192.168.0.201   vms201.rhce.cc   <none>           <none>
kube-proxy-7qzdd                           1/1     Running   22         8d     192.168.0.202   vms202.rhce.cc   <none>           <none>
kube-proxy-m9c2c                           1/1     Running   25         8d     192.168.0.203   vms203.rhce.cc   <none>           <none>
kube-scheduler-vms201.rhce.cc              1/1     Running   20         8d     192.168.0.201   vms201.rhce.cc   <none>           <none>
metrics-server-bcfb98c76-nqc2t             1/1     Running   14         4d5h   10.244.58.237   vms202.rhce.cc   <none>           <none>

可以看到在每个设备上,都存在一个calico pod,和前面实验中的一样。不过在K8S环境中直接使用calico.yaml来配置calico,保证了K8s中每个Node之间都能够回显通信。

网络策略:

Network Policy是kubernetes中的一种资源类型,它从属于某个namespace。其内容从逻辑上看包含两个关键部分,一是pod选择器,基于标签选择相同namespace下的pod,将其中定义的规则作用于选中的pod。另一个就是规则了,就是网络流量进出pod的规则,其采用的是白名单模式,符合规则的通过,不符合规则的拒绝。

实验概述:
在集群中创建两个pod,分别关联两个SVC,正常情况下,集群外的主机是能够直接访问两个服务的,

步骤1: 使用docker拉取测试使用的镜像

docker pull yauritux/busybox-curl

步骤2: 创建两个pod和SVC

[root@vms201 calico]# cat pod1.yaml
apiVersion: v1
kind: Pod
metadata:creationTimestamp: nulllabels:test: pod1name: pod1
spec:terminationGracePeriodSeconds: 0containers:- image: nginximagePullPolicy: IfNotPresentname: pod1resources: {}dnsPolicy: ClusterFirstrestartPolicy: Always
status: {}
[root@vms201 calico]# kubectl apply -f pod1.yaml
pod/pod1 created
[root@vms201 calico]# sed 's/pod1/pod2/' pod1.yaml | kubectl apply -f -
pod/pod2 created
[root@vms201 calico]# kubectl get pods
NAME   READY   STATUS    RESTARTS   AGE
pod1   1/1     Running   0          30s
pod2   1/1     Running   0          8s

修改nginx的主页,pod1为111,pod2为222:

[root@vms201 calico]# kubectl exec pod1 -- sh -c "echo 111 > /usr/share/nginx/html/index.html"
[root@vms201 calico]# kubectl exec pod2 -- sh -c "echo 222 > /usr/share/nginx/html/index.html"

创建SVC,绑定到pods上:

[root@vms201 ~]# kubectl expose --name=svc1 pod pod1 --port=80 --type=LoadBalancer
service/svc1 exposed
[root@vms201 ~]# kubectl expose --name=svc2 pod pod2 --port=80 --type=LoadBalancer
service/svc2 exposed[root@vms201 ~]#  kubectl get svc
NAME   TYPE           CLUSTER-IP       EXTERNAL-IP     PORT(S)        AGE
svc1   LoadBalancer   10.107.162.113   192.168.0.240   80:31536/TCP   43s
svc2   LoadBalancer   10.98.23.70      192.168.0.241   80:30992/TCP   29s

创建测试使用的pod:可以看到,目前测试使用的pod能够正常访问两个nginx的pods。

kubectl run testpod --image=docker.io/yauritux/busybox-curl:latest -it --rm --image-pull-policy=IfNotPresent -- sh
/home # curl svc1
111
/home # curl svc2
222

在K8s官网找到网络策略的yaml文件模板进行应用:
https://kubernetes.io/docs/concepts/services-networking/network-policies/

[root@vms201 calico]# cat networkPolicy.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:name: test-network-policynamespace: default
spec:podSelector:matchLabels:role: dbpolicyTypes:- Ingress- Egressingress:- from:- ipBlock:cidr: 172.17.0.0/16except:- 172.17.1.0/24- namespaceSelector:matchLabels:project: myproject- podSelector:matchLabels:role: frontendports:- protocol: TCPport: 6379egress:- to:- ipBlock:cidr: 10.0.0.0/24ports:- protocol: TCPport: 5978

其中的podSelector表示作用于namespace中的哪个pod,使用标签的方式进行匹配。如果不写的话,表示作用于namespace中的所有pods。

  podSelector:matchLabels:role: db

policyType有两种,分别表示匹配入方向或者出方向的流量,只有在这里激活了对应的type,后续设置的策略才会生效。

  policyTypes:- Ingress- Egress

策略:

如下是ingress策略:

 ingress:- from:- ipBlock:cidr: 172.17.0.0/16except:- 172.17.1.0/24- namespaceSelector:matchLabels:project: myproject- podSelector:matchLabels:role: frontendports:- protocol: TCPport: 6379

有三种方式,分别是:

  1. ipBlock:匹配到的IP地址可以访问,except匹配到的无法访问 ;
  2. podSelector:指定匹配到label的pod能够访问;
  3. namespaceSelector:指定命名空间内任何pod能够访问。

其中podSelector默认作用于当前命名空间,如果想要作用于其他命名空间,可以这书写策略:取消掉列表。

    - namespaceSelector:matchLabels:project: myprojectpodSelector:matchLabels:role: frontend

egress策略同理。

测试1: 通过ingress策略的podSelector限制testpod无法访问pod1

修改策略文件:

[root@vms201 calico]# cat policy1.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:name: test-network-policy1namespace: network
spec:podSelector:matchLabels:test: pod1policyTypes:- Ingressingress:- from:- podSelector:matchLabels:role: xxxports:- protocol: TCPport: 80

作用于network命名空间中的node1,仅运行标签为role: xxx访问,作用的协议是TCP的80号端口。

[root@vms201 calico]# kubectl apply -f policy1.yaml
networkpolicy.networking.k8s.io/test-network-policy1 created
[root@vms201 calico]# kubectl get networkpolicies
NAME                   POD-SELECTOR   AGE
test-network-policy1   test=pod1      37s

应用策略后使用testpod进行验证:

[root@vms201 calico]# kubectl exec -it testpod -- sh
/home # curl svc1
/home # curl svc2
222

可以看到,目前testpod无法访问testpod。

测试完成后删除掉当前策略即可。

测试2: 通过egress策略的ipBlock限制testpod仅能访问通pod1,不能够访问pod2。

策略的yaml文件如下:

[root@vms201 calico]# cat policy2.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:name: test-network-policy2
spec:podSelector:matchLabels:run: testpodpolicyTypes:- Egressegress:- to:- namespaceSelector:matchLabels:name: kube-systemports:- protocol: UDPport: 53- to:- ipBlock:cidr: 192.168.0.240/32ports:- protocol: TCPport: 80

作用于testpod上,192.168.0.240为pod1的IP地址。在其中加上namespaceSelector和允许protocol: UDP的原因是让其可以去访问kube-system空间内的DNS服务器,解析SVC的名称。

应用策略并查看结果:

[root@vms201 calico]# kubectl apply -f policy2.yaml
networkpolicy.networking.k8s.io/test-network-policy2 created
[root@vms201 calico]# kubectl get networkpolicies
NAME                   POD-SELECTOR   AGE
test-network-policy2   run=testpod    14s

进入testpod进行查看:

[root@vms201 calico]# kubectl exec -it testpod -- sh
/home # curl svc1
111
/home # curl svc2

默认策略:

默认拒绝所有入站流量:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:name: default-deny-ingress
spec:podSelector: {}policyTypes:- Ingress

默认允许所有入站流量:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:name: allow-all-ingress
spec:podSelector: {}ingress:- {}policyTypes:- Ingress

默认拒绝所有出站流量:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:name: default-deny-egress
spec:podSelector: {}policyTypes:- Egress

默认允许所有出站流量:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:name: allow-all-egress
spec:podSelector: {}egress:- {}policyTypes:- Egress

默认拒绝所有入口和所有出站流量:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:name: default-deny-all
spec:podSelector: {}policyTypes:- Ingress- Egress

参考资料:
《老段CKA课程》

十四、K8s calico网络的通信及网络策略相关推荐

  1. 网络与通信:网络协议(概念)

    计算机网络技术是互联网发展的基础.它是计算机技术与通信技术结合的产物,是现在信息技术的一个重要组成部分,而且正朝着数字化.高速化.智能化的方向迅速发展.随着3G.4G技术的兴起,越来越多的企业参与到了 ...

  2. 企业实战-Kubernetes(十四)k8s高可用集群

    k8s高可用集群 1 使用pacemaker搭建k8s的高可用(haproxy的高可用) 安装并配置haproxy 安装并配置pacemaker 2 k8s集群部署 master准备 三个结点关闭交换 ...

  3. 【Vue3 第十四章】父子组件通信

    数字化管理平台 Vue3+Vite+VueRouter+Pinia+Axios+ElementPlus 权限系统-商城 个人博客地址 一.概述 在Vue的框架开发的项目过程中,经常会用到组件来管理不同 ...

  4. 第十四章 讲解如何去除和锁定网络验证暗装

    讲解如何去除和锁定网络验证暗装   暗桩,通常被运用在网络验证过后的功能里或者启动时的验证里,长期使用,也没有一个固定的特性,所以需要我们大家有相应的判断能力,这里我们将以VB的某程序做为一个暗装的讲 ...

  5. Docker网络容器通信

    Docker网络&容器通信 docker网络 原生网络 自定义网络 docker容器通信 ip通信 Docker DNS Server joined容器 link docker跨主机通信 容器 ...

  6. Kubernetes Docker 容器网络终极之战(十四)

    与 Docker 默认的网络模型不同,Kubernetes 形成了一套自己的网络模型,该网络模型更加适应传统的网络模式,应用能够平滑的从非容器环境迁移到 Kubernetes 环境中. 自从 Dock ...

  7. 《深入浅出DPDK》读书笔记(十四):DPDK应用篇(DPDK与网络功能虚拟化:NFV、VNF、IVSHMEM、Virtual BRAS“商业案例”)

    Table of Contents DPDK应用篇 DPDK与网络功能虚拟化 157.网络功能虚拟化 13.1.1起源 158.发展 159.OPNFV与DPDK NFV的部署 160.NFV的部署 ...

  8. 第十四课 k8s源码学习和二次开发原理篇-调度器原理

    第十四课 k8s源码学习和二次开发原理篇-调度器原理 tags: k8s 源码学习 categories: 源码学习 二次开发 文章目录 第十四课 k8s源码学习和二次开发原理篇-调度器原理 第一节 ...

  9. Java基础学习——第十四章 网络编程

    Java基础学习--第十四章 网络编程 一.网络编程概述 计算机网络: 把分布在不同地理区域的计算机与专门的外部设备用通信线路互连成一个规模大.功能强的网络系统,从而使众多的计算机可以方便地互相传递信 ...

  10. 网络协议(十四):WebSocket、WebService、RESTful、IPv6、网络爬虫、HTTP缓存

    网络协议系列文章 网络协议(一):基本概念.计算机之间的连接方式 网络协议(二):MAC地址.IP地址.子网掩码.子网和超网 网络协议(三):路由器原理及数据包传输过程 网络协议(四):网络分类.IS ...

最新文章

  1. 关闭vmware喇叭报警声
  2. 高仿百思不得姐项目开发(粗略笔记,后期规范排版和更新)
  3. MySQL DISTINCT:去重(过滤重复数据)
  4. 字节面试必须拿下的十道算法题,你会几道?
  5. 看得见的开发管理方法—缺陷管理
  6. 房价预测(HackerRank)
  7. 使用page-slot显示SAP Spartacus section里包含的Component和layout设计
  8. YbtOJ#20089-[NOIP2020模拟赛B组Day10]平衡的树【贪心】
  9. 你应当如何学习C++(以及编程)(rev#1)
  10. CF 839 E-最大团
  11. [剑指offer][JAVA][面试题第13题][机器人的运动][DFS][BFS]
  12. 【C语言】写一个函数,并调用该函数求两个整数的最大公约数和最小公倍数
  13. 实时计算Flink 快速入门 —— 步骤二:注册上下游存储
  14. PsExec:一个非常实用的【远程运行】工具
  15. 【http协议2】 深入理解HTTP协议
  16. 获取Nist的美国官方标准时间的解决办法
  17. EF Code First 学习笔记:表映射
  18. 图书信息管理系统报告linux,C语言图书管理系统 带程序报告
  19. CTF常见用法小总结
  20. Ubuntu16.04中好用的软件(持续更新)

热门文章

  1. 数学基础加强2---概率论与贝叶斯先验
  2. 数据科学包16-matplotlib的三个实例
  3. 达观杯文本智能处理(5)
  4. 从零实现深度学习框架——深入浅出交叉熵
  5. Java网络编程进阶:通过JSSE创建安全的数据通信
  6. iOS的GIF动画效果实现
  7. 客观真实的数据为何揭不开真相?
  8. Oracle J.D.Edwards技术与应用
  9. redis hash field过期时间_大佬来告诉你用事半功倍的办法,学习Redis,你觉得它还难吗?...
  10. java 小球运动轨迹_java怎么实现小球的运动轨迹