+
+
+ ++
hbb@hbb:~$ docker network ls |
host模式即与主机共享网络空间，不使用私有的容器网络空间；none模式即容器内没有eth0网口，因此无法与容器外通信；
bridgenetwork namespace
docker inspect network bridge命令可查看docker列出的当前docker默认bridge网桥docker0下的容器网络信息：
如图所示，为vxlan原理：
flannel CNI插件会为每个node分配一个子网IP段，上面的pod会从该网段范围取一个IP；
+默认，flannel跨节点通信是通过vxlan实现，即通过隧道技术L2 Oery UDP；
calico是一个运行在纯三层的组件，基于BGP协议和Linux自身的路由转发机制，容器通信也不依赖iptables NAT或Tunnel 等技术，因此相对于flannel会少一些封包与拆包的过程，效率更高：
其跨主机的通信模型如下所示：
当容器创建时，calico为容器生成veth pair，一端作为容器网卡加入到容器的网络命名空间，并设置IP和掩码，一端直接暴露在宿主机上，并通过设置路由规则，将容器IP暴露到宿主机的通信路由上。于此同时，calico为每个主机分配了一段子网作为容器可分配的IP范围，这样就可以根据子网的CIDR为每个主机生成比较固定的路由规则。
+当容器需要跨主机通信时，主要经过下面的简单步骤：
+func (pb *prober) runProbe(p *v1.Probe, pod *v1.Pod, status v1.PodStatus, container v1.Container, containerID kubecontainer.ContainerID) (probe.Result, string, error) { |
[200-400)即判断成功：func DoHTTPProbe(url *url.URL, headers http.Header, client HTTPGetInterface) (probe.Result, string, error) { |
Dail操作判断端口是否可连接：func DoTCPProbe(addr string, timeout time.Duration) (probe.Result, string, error) { |
LivenessProbe的initialDelaySeconds和failureThreshold值，但如果超过这个时间范围还没启动，服务会进入重启，并进入循环卡死的过程；StartupProbe就是用于解决这种场景下的问题，在StartupProbe成功之前，是不是为执行LivenessProbe和ReadinessProbe的；影响pod的流量开关；
+负责判断pod是否就绪，只有就绪状态后，才会将pod IP放到service的endpoints上，并开始接收流量；
+kubelet会通过SetContainerReadiness将container的condition设置为true：
func (m *manager) SetContainerReadiness(podUID types.UID, containerID kubecontainer.ContainerID, ready bool) { |
k8s v1.12之前，pod是否处于ready是由kubelet根据容器状态来判断的，如果pod中容器全部处于ready，则pod处于ready状态；
+k8s v1.12之后，提供了一个readinessGates的功能来满足用于对于pod ready状态的控制需求，此时判断pod是否ready有两个前提条件：
ContainersReady为True；pod.spec.readinessGates中定义一个或多个conditionType，需要这些conditionType都为True，pod才能为ready；apiVersion: v1 |
func (pb *prober) runProbe(p *v1.Probe, pod *v1.Pod, status v1.PodStatus, container v1.Container, containerID kubecontainer.ContainerID) (probe.Result, string, error) { |
[200-400)即判断成功：func DoHTTPProbe(url *url.URL, headers http.Header, client HTTPGetInterface) (probe.Result, string, error) { |
Dail操作判断端口是否可连接：func DoTCPProbe(addr string, timeout time.Duration) (probe.Result, string, error) { |
LivenessProbe的initialDelaySeconds和failureThreshold值，但如果超过这个时间范围还没启动，服务会进入重启，并进入循环卡死的过程；StartupProbe就是用于解决这种场景下的问题，在StartupProbe成功之前，是不是为执行LivenessProbe和ReadinessProbe的；影响pod的流量开关；
负责判断pod是否就绪，只有就绪状态后，才会将pod IP放到service的endpoints上，并开始接收流量；
kubelet会通过SetContainerReadiness将container的condition设置为true：
func (m *manager) SetContainerReadiness(podUID types.UID, containerID kubecontainer.ContainerID, ready bool) { |
k8s v1.12之前，pod是否处于ready是由kubelet根据容器状态来判断的，如果pod中容器全部处于ready，则pod处于ready状态；
k8s v1.12之后，提供了一个readinessGates的功能来满足用于对于pod ready状态的控制需求，此时判断pod是否ready有两个前提条件：
ContainersReady为True；pod.spec.readinessGates中定义一个或多个conditionType，需要这些conditionType都为True，pod才能为ready；apiVersion: v1 |
RESTClient, ClientSet, DynamicClient, DiscoveryClientmap[string]interface{}结构来存储k8s apiserver的返回资源结构，通过反射机制，在运行时进行数据绑定；kubectl api-versions和kubectl api-resources返回的资源内容相关；Deltas有两个属性：Type, Object，分别表示事件类型（增删改），资源类型；几个重要概念
IndexFunc: 索引函数，用于计算一个资源对象的索引值列表，可以根据需要自定义，如通过label, annotation来生成索引列表；Index：存储数据，如要查找某个ns下的pod，就要让pod按ns空间进行索引，对应的Index类型即为map[ns]pods；Indexers：存储索引器，key为索引器名称，value为索引器实现函数（IndexFunc），如map[ns]XXXIndexFunc即存储索引的存储器
Indices：存储缓存器，key为索引器名称，value为缓存的数据（Index），如map[ns]map[ns]sets.pod即存储缓存数据的存储器
index := cache.NewIndexer( |
SharedInformer为多个Controller提供缓存资源对象的informer共享，避免重复缓存；SharedInformer一般是使用SharedInformerFactory来管理控制器需要的资源对象的informer，使用map结构来存储资源对象的informer；SharedInformer，并扩展了添加和获取Indexers的能力；SharedInformerFactory为所有已知GVR提供共享的informer；Start方法，用于启动所有Reflector的Informer；WaitForCacheSync函数会不断调用factory持有的informer的HasSynced方案直接全部返回true，表示所有informer关注的资源对象已经全部缓存到了本地；InformerFor方法，是用于返回SharedInformerFactory中指定资源类型所对应的informer，如果不存在则会先创建；PodInforer, ServiceInformer等；sharedInformerFactory := informers.NewSharedInformerFactory(clientSet, 0) |
随机超时：避免同时发起选举请求
任期Term：用于标记选举任期，可用于让故障回复后的leader变成follower，任期小的选举请求会被拒绝；
角色：leader, follower, candidate
leader选择出来后，leader会定时向follower发起心跳，如心跳超时，则最先timeout的节点会发起选举请求，此时该节点会从follower转变成cadidate；
hbb@hbb:~$ docker network ls |
host模式即与主机共享网络空间，不使用私有的容器网络空间；none模式即容器内没有eth0网口，因此无法与容器外通信；bridgenetwork namespacedocker inspect network bridge命令可查看docker列出的当前docker默认bridge网桥docker0下的容器网络信息：如图所示，为vxlan原理：
flannel CNI插件会为每个node分配一个子网IP段，上面的pod会从该网段范围取一个IP；
默认，flannel跨节点通信是通过vxlan实现，即通过隧道技术L2 Oery UDP；
calico是一个运行在纯三层的组件，基于BGP协议和Linux自身的路由转发机制，容器通信也不依赖iptables NAT或Tunnel 等技术，因此相对于flannel会少一些封包与拆包的过程，效率更高：
其跨主机的通信模型如下所示：
当容器创建时，calico为容器生成veth pair，一端作为容器网卡加入到容器的网络命名空间，并设置IP和掩码，一端直接暴露在宿主机上，并通过设置路由规则，将容器IP暴露到宿主机的通信路由上。于此同时，calico为每个主机分配了一段子网作为容器可分配的IP范围，这样就可以根据子网的CIDR为每个主机生成比较固定的路由规则。
当容器需要跨主机通信时，主要经过下面的简单步骤：
sendmsg阶段：sendqueue中；recvmsg阶段：recvqueue中，协程挂起(gopack)；sendqueue有协程，则说明缓冲队列已满，则从缓冲队列中取值，并将sendqueue中取一个协程，将其值拷贝到缓冲循环数组中；GOMAXPROCESS控制数量，线程数一般不配置，但也有一个底层的函数可设置（SetMaxThreads），M默认上限是10000；白色，灰色，黑色灰色（对象从白色表中移到灰色表）灰色标记表开始，遍历该表中的对象，将从这些对象开始的可达到对象（走一步），标记为灰色，同时灰色表中已经遍历过的对象，标记为黑色（对象从灰色表中移到黑色表）灰色表，直到灰色表中无任何对象上述过程，仍然需要STW，否则会出现并发导致的引用关系错乱，导致资源被错误的GC删除
三色标记被破坏的情况有两种：
谷歌提出了两个三色不变色：
只要三色不变色满足上述条件之一，即可解决三色标记必须使用STW问题
灰色灰色表的过程，不需要STW，直到灰色表为空结束黑色对象可能引用白色对象，为解决这个问题，需要在上一步灰色表为空时，执行一些STW，并将栈上所有对象都标记为白色，并对这些对象重新执行一遍扫描；缺点：在结束时，还需要额外扫描一次栈上的对象引用链，这会引入10-100ms；
灰色或白色，则会被标记为灰色；灰色对象到白色对象的路径不会断；缺点：被删除对象，当前这一轮GC不会被删掉（因为会被转换成黑色），但会在下轮GC中删掉；
黑色（期间不需要STW）黑色灰色灰色]]>满足变形的弱三色不变色，混合了插入，删除写屏障的优点
kubefed）的基础上发展而来，吸取了其经验和教训，kubefed项目目前已经被放弃；kubefed v2接入vs时需要定义的CRD，因此接入kubefed是需要对原始k8s资源进行改造，对用户不友好：apiVersion: types.kubefed.io/v1beta1 |
Submariner这种开源方案ServiceExport和ServiceImportkarmada apiserver, karmada controller manager, karmada scheduler；karmada apiserver是在k8s apiserver的基础上开发的，所以功能与k8s apiserver类似；karmada scheduler是集群调度器，即完成在资源下发阶段，为资源选择合适集群的目标；karmada controller manager如下图所示，集成了4个controller：Cluster Controller 将k8s集群连接到karmada，为每个集群都创建了一个Cluster资源对象，来管理集群的生命周期；Policy Controller 监视PropagationPolicy对象，当该CRD创建时，controller会选择与resourceSelector匹配的一组资源，为每个单独的联邦资源对象创建ResourceBinding对象；Binding Controller 监视ResourceBinding对象，为每个带有单个资源manifest的集群创建一个Work对象；Executioin Controller 监视Work对象，当资源创建时，controller会把资源下发到成员集群中；
Resource Template -> Propagation Policy -> Resource Binding -> Override Policy；Resource Template阶段：是定义资源模板，其可直接套用原生k8s的配置，无需进行改造；Propagation Policy阶段：为通过PropagationPolicy API来定义多集群的调度要求，CRD定义源码在这；Resource Binding阶段：此时应用会为每个联邦应用创建一个ResourceBinding资源，用于关联其PropagationPolicy资源，该CRD定义源码在这Override Policy阶段：为每个ResourceBinding资源执行集群级别的差异化配置改写，其CRD定义源码在这
karmada-descheduler and karmada-scheduler-estimatorkarmada-deschedulerkarmada-scheduler-estimatoratms-00.vm访问目标集群，所以需要在karmada机器的coredns上配置如下IP映射：# kubectl edit cm -n kube-system coredns -o yaml |
安装cli：
curl -s https://raw.githubusercontent.com/karmada-io/karmada/master/hack/install-cli.sh | sudo INSTALL_CLI_VERSION=1.8.1 bash |
初始化karmada
sudo kubectl karmada init --kubeconfig ~/.kube/config |
Karmada有两个context: karmada-apiserver和karmada-host，可通过kubectl config view查看所有集群：
karmada-apiserver
kubectl config use-context karmada-apiserver --kubeconfig ~/.kube/karmada-apiserver.configkubeconfig；karmada-host
kubectl config use-context karmada-host --kubeconfig ~/.kube/karmada-apiserver.confighostcluster的安装；# 先更改当前member集群的名 |
kubectl --kubeconfig /etc/karmada/karmada-apiserver.config get clusters |
kubefed）的基础上发展而来，吸取了其经验和教训，kubefed项目目前已经被放弃；kubefed v2接入vs时需要定义的CRD，因此接入kubefed是需要对原始k8s资源进行改造，对用户不友好：apiVersion: types.kubefed.io/v1beta1 |
Submariner这种开源方案ServiceExport和ServiceImportkarmada apiserver, karmada controller manager, karmada scheduler；karmada apiserver是在k8s apiserver的基础上开发的，所以功能与k8s apiserver类似；karmada scheduler是集群调度器，即完成在资源下发阶段，为资源选择合适集群的目标；karmada controller manager如下图所示，集成了4个controller：Cluster Controller 将k8s集群连接到karmada，为每个集群都创建了一个Cluster资源对象，来管理集群的生命周期；Policy Controller 监视PropagationPolicy对象，当该CRD创建时，controller会选择与resourceSelector匹配的一组资源，为每个单独的联邦资源对象创建ResourceBinding对象；Binding Controller 监视ResourceBinding对象，为每个带有单个资源manifest的集群创建一个Work对象；Executioin Controller 监视Work对象，当资源创建时，controller会把资源下发到成员集群中；
Resource Template -> Propagation Policy -> Resource Binding -> Override Policy；Resource Template阶段：是定义资源模板，其可直接套用原生k8s的配置，无需进行改造；Propagation Policy阶段：为通过PropagationPolicy API来定义多集群的调度要求，CRD定义源码在这；Resource Binding阶段：此时应用会为每个联邦应用创建一个ResourceBinding资源，用于关联其PropagationPolicy资源，该CRD定义源码在这Override Policy阶段：为每个ResourceBinding资源执行集群级别的差异化配置改写，其CRD定义源码在这
karmada-descheduler and karmada-scheduler-estimatorkarmada-deschedulerkarmada-scheduler-estimatoratms-00.vm访问目标集群，所以需要在karmada机器的coredns上配置如下IP映射：# kubectl edit cm -n kube-system coredns -o yaml |
安装cli：
curl -s https://raw.githubusercontent.com/karmada-io/karmada/master/hack/install-cli.sh | sudo INSTALL_CLI_VERSION=1.8.1 bash |
初始化karmada
sudo kubectl karmada init --kubeconfig ~/.kube/config |
Karmada有两个context: karmada-apiserver和karmada-host，可通过kubectl config view查看所有集群：
karmada-apiserver
kubectl config use-context karmada-apiserver --kubeconfig ~/.kube/karmada-apiserver.configkubeconfig；karmada-host
kubectl config use-context karmada-host --kubeconfig ~/.kube/karmada-apiserver.confighostcluster的安装；# 先更改当前member集群的名 |
kubectl --kubeconfig /etc/karmada/karmada-apiserver.config get clusters |
RESTClient, ClientSet, DynamicClient, DiscoveryClientmap[string]interface{}结构来存储k8s apiserver的返回资源结构，通过反射机制，在运行时进行数据绑定；kubectl api-versions和kubectl api-resources返回的资源内容相关；+ ++
hbb@hbb:~$ docker network ls |
host模式即与主机共享网络空间，不使用私有的容器网络空间；none模式即容器内没有eth0网口，因此无法与容器外通信；bridgenetwork namespacedocker inspect network bridge命令可查看docker列出的当前docker默认bridge网桥docker0下的容器网络信息：sendmsg阶段：sendqueue中；recvmsg阶段：recvqueue中，协程挂起(gopack)；sendqueue有协程，则说明缓冲队列已满，则从缓冲队列中取值，并将sendqueue中取一个协程，将其值拷贝到缓冲循环数组中；GOMAXPROCESS控制数量，线程数一般不配置，但也有一个底层的函数可设置（SetMaxThreads），M默认上限是10000；白色，灰色，黑色灰色（对象从白色表中移到灰色表）灰色标记表开始，遍历该表中的对象，将从这些对象开始的可达到对象（走一步），标记为灰色，同时灰色表中已经遍历过的对象，标记为黑色（对象从灰色表中移到黑色表）灰色表，直到灰色表中无任何对象++ + + + + +上述过程，仍然需要STW，否则会出现并发导致的引用关系错乱，导致资源被错误的GC删除
+