为什么需要ebpf

其背后的思想是:“与其把数据包复制到用户空间执行用户态程序过滤，不如把过滤程序灌进内核去”

简单来讲，BPF是一套完整的计算机体系结构 。和x86，ARM这些类似，BPF包含自己的指令集和运行时逻辑，同理，就像在x86平台编程，最终要落实到x86汇编指令一样，BPF字节码也可以看成是汇编指令的序列。

与节点网络相比，容器网络会带来一些额外开销

 上图表明容器网络也需要执行节点到节点网络的所有处理流程，并且这些流程都发生在容器的网络命名空间中（深蓝色部分）。

 eBPF 主机路由允许绕过主机命名空间中所有的 iptables 和上层网络栈，以及穿过 Veth 对时的一些上下文切换，以节省资源开销。网络数据包到达网络接口设备时就被尽早捕获，并直接传送到 Kubernetes Pod 的网络命名空间中。在流量出口侧，数据包同样穿过 Veth 对，被 eBPF 捕获后，直接被传送到外部网络接口上。eBPF 直接查询路由表，因此这种优化完全透明，并与系统上运行的所有提供路由分配的服务兼容。

如何快速删除yaml中定义的资源

快速删除yaml 中定义的资源
kubectl apply -f calico.yaml
-- 删除的方法
kubectl delete -f calico.yaml

如何排查错误 N 板斧

查看pod详情

kubectl describe pods -n istio-system 

查看日志

kubectl logs -f kubernetes-dashboard-67484c44f6-j5494 -n kubernetes-dashboard

查看系统日志

journalctl  -u kube-apiserver  或 systemctl  status kube-apiserver

如果信息查看不全可以用  

journalctl -n 40 -u kube-apiserver | vim -

-e 从结尾开始看

journalctl -e -u kube-controller-manager | vim -

进入pod

kubectl exec -it pod名称 -n namespace名称

对于网络问题查看pod 是否 READY

istio

希腊语，意扬帆起航  , 发音「意丝帝欧」，重音在 "意" 上。作用 ：连接、安全、控制和观测服务

nfs,glusterfs,cephfs等存储的优缺点：

NFS：仅提供文件存储，部署简单，挂载卷具有单点故障，高可靠性差；批量访问具有IO瓶颈；

GlusterFS：集群部署，具有很好的可扩展性。适合大文件，小文件性能相对较差；支持多种文件接口协议。生产环境中应用比NFS广泛。

Ceph：C语言系编写，所以性能较高，没有单点故障依赖；适合小文件  支持多种文件接口协议；生产环境中比NFS应用广泛。

Ceph是一个更灵活的产品，更容易集成到非 Linux 环境中。对于许多公司来说，这足以让它们在 Ceph 而不是 GlusterFS 上构建存储产品。对于仅运行 Linux 的环境，此功能不够有说服力，所以来谈谈另一个非常重要的事情：速度。

所以更多的公司正在考虑Ceph技术而不是GlusterFS，而且GlusterFS仍然与Red Hat密切相关。例如，SUSE还没有GlusterFS的商业实施，而Ceph已经被开源社区广泛采用，市场上有各种不同的产品。在某种意义上来说，Ceph确实已经胜过GlusterFS。也有网友反映说Ceph安装运行时候需要人工干预比GlusterFS要多，具体的还需要使用人考虑适用的场景。

kube-proxy 拦截的是进出 Kubernetes 节点的流量，而 sidecar proxy 拦截的是进出（ingress 和egress）该 Pod 的流量

远程NFS 目录如何挂载到pod中？参考文章1

1. 获取pod name

[root@k8s01 istio-1.7.3]# kubectl get pods -n nfs-test
NAME                            READY   STATUS    RESTARTS   AGE
test-volumes-6d785d5747-cg8dk   1/1     Running   0          13d

2. 获取 Pod 的唯一标识 uid

kubectl get pod  test-volumes-6d785d5747-cg8dk -o jsonpath={.metadata.uid} -n nfs-test

a7a25e0a-a760-403e-acd0-ce8516c839e1

3. 查找pod 所在的node 节点

root@k8s01 istio-1.7.3]# kubectl get pods -n nfs-test -o wide
NAME                            READY   STATUS    RESTARTS   AGE   IP            NODE    NOMINATED NODE   READINESS GATES
test-volumes-6d785d5747-cg8dk   1/1     Running   0          13d   10.244.1.61   k8s02   <none>           <none>

4. 根据pod uid  取对应node 节点上 查看挂载点

Pod 对应的 Volume 目录完整路径为

 查看挂载信息

[root@k8s02 back]#  findmnt /var/lib/kubelet/pods/a7a25e0a-a760-403e-acd0-ce8516c839e1/volumes/kubernetes.io~nfs/nfs-pv

总结如下

1. 根据我们的 Volume 类型来决定需要做什么操作了，比如如果用的 Ceph RBD，那么 kubelet 就需要先调用对应驱动将 Ceph 提供的 RBD Attach 到 Pod 所在的宿主机上面，这个阶段在 Kubernetes 中被称为  附着( Attach) 阶段。

2. Attach 阶段完成后，为了能够使用这个块设备，kubelet 还要进行第二个操作，即：格式化这个块设备，然后将它挂载到宿主机指定的挂载点上。这个挂载点，也就是上面我们提到的 Volume 的宿主机的目录。将块设备格式化并mount到 Volume 宿主机目录的操作，在 Kubernetes 中被称为 Mount 阶段。

3.  经过了上面的两个阶段过后，我们就得到了一个持久化的宿主机上面的 Volume 目录了，接下来 kubelet 只需要把这个 Volume 目录挂载到容器中对应的目录即可，这样就可以为 Pod 里的容器挂载这个持久化的 Volume 了，这一步其实也就相当于执行了如下所示的命令：

docker run -v /var/lib/kubelet/pods/<Pod的ID>/volumes/kubernetes.io~<Volume类型>/<Volume名字>:/<容器内的目标目录> 我的镜像 ...

简短点说 先把远程存储 附着 attach（脱离 detatch），  加载 mount(  卸载 unmount ) 到 本地宿主机目录，然后用 docker -v 把 本地宿主机目录 映射到容器内部

举个例子：一个pod 想使用一块物理硬盘，先把物理硬盘 attach 也就是安装，然后把物理硬盘格式化 mount到宿主机某个目录，最后把宿主机目录 映射到容器内部

etcd

是一个高可用强一致性的键值仓库在很多分布式系统架构中得到了广泛的应用，其最经典的使用场景就是服务发现。

作为一个受到 ZooKeeper启发而催生的项目，它除了拥有与之类似的功能外，更专注于以下四点。

• 简单：易于部署，易使用。基于 HTTP+JSON 的 API 让你用 curl 就可以轻松使用。
• 安全：可选 SSL 客户认证机制。
• 快速：每个实例每秒支持一千次写操作。
• 可信：使用一致性 Raft 算法充分实现了分布式。

etcd 的场景默认处理的数据都是系统中的控制数据。所以etcd在系统中的角色不是其他NoSQL产品的替代品，更不能作为应用的主要数据存储。etcd中应该尽量只存储系统中服务的配置信息，对于应用数据只推荐把数据量很小，但是更新和访问频次都很高的数据存储在etcd中。

因为etcd是go语言编写的，安装只需要下载对应的二进制文件，并放到合适的路径就行。etcd在生产环境中一般推荐集群方式部署。测试时可以单节点运行 【安装配置参考文章12】

备份etcd的数据

$ etcdctl backup --data-dir /var/lib/etcd  --backup-dir /home/etcd_backup

支持的选项包括:

--data-dir  etcd的数据目录
--backup-dir 备份到指定路径

通过list、add、remove命令列出、添加、删除etcd实例到etcd集群中。

查看集群中存在的节点

$ etcdctl member list
8e9e05c52164694d: name=dev-master-01 peerURLs=http://localhost:2380 clientURLs=http://localhost:2379 isLeader=true

删除集群中存在的节点

$ etcdctl member remove 8e9e05c52164694d
Removed member 8e9e05c52164694d from cluster

向集群中新加节点

$ etcdctl member add etcd3 http://192.168.1.100:2380
Added member named etcd3 with ID 8e9e05c52164694d to cluster

参考文章列表

1. Kubernetes 存储原理解析  Kubernetes 存储原理解析

2. 如何部署一个生产级别的 Kubernetes 应用  如何部署一个生产级别的 Kubernetes 应用

3. 使用 Istio 实现非侵入流量治理 - 51CTO.COM  使用 Istio 实现非侵入流量治理

4. Istio 流量管理之故障注入 - 51CTO.COM   Istio 流量管理之故障注入 - 51CTO.COM

5. 太强了，Istio竟然有这么多功能！ - 51CTO.COM  太强了，Istio竟然有这么多功能！

6. Istio+K8s，微服务的双剑合璧！ - 51CTO.COM  Istio+K8s，微服务的双剑合璧！

7. 序言 · Istio Handbook - Istio 服务网格进阶实战 by ServiceMesher(服务网格社区)     Istio Handbook——Istio 服务网格进阶实战

8. 序言 · Kubernetes Handbook - Kubernetes 中文指南/云原生应用架构实践手册 · Jimmy Song  Kubernetes Handbook——Kubernetes 中文指南/云原生应用架构实践手册

9. 不能获取到镜像，ImagePullBackoff或者Pending - 三度 - 博客园    不能获取到镜像，ImagePullBackoff或者Pending

10. 看图轻松了解etcd - SegmentFault 思否

11. [译]走进Kubernetes集群的大脑：Etcd - k8s-kb - 博客园 (cnblogs.com)

12. Etcd 使用入门 - 简书 (jianshu.com)

13 一文带你彻底厘清 Kubernetes 中的证书工作机制-赵化冰的博客 | Zhaohuabing Blog

14 数字证书原理-赵化冰的博客 | Zhaohuabing Blog

15 Kubernetes 之 二进制安装(二) 证书详解_三冬气凛冽，独立千崖雪。的技术博客_51CTO博客

16 Kubernetes 文档 | Kubernetes  k8s中文网站

17 https://segmentfault.com/a/1190000016565044  calico网络模型中的路由原理

18 几张图解释明白 Kubernetes IngressKubernetes Ingress 原理介绍，简单来说：它不过是一种轻松配置 Nginx 服务器的方法，它可以将请求重定向到其他内部服务去。这为我们节省了宝贵的静态 IP 和 LoadBalancers 资源。https://mp.weixin.qq.com/s/y02ao1Pvo8lFqPL3sTIupw

原理:

Flannel的两种模式解析（VXLAN、host-gw)    Flannel的两种模式解析（VXLAN、host-gw)

深入理解CNI（容器网络接口）   深入理解CNI（容器网络接口）

Linux 虚拟网络设备之 tun/tap   Linux 虚拟网络设备之 tun/tap

Lance   k8s网络 ebpf   网络策略实现(推荐)

技术|深入理解 BPF：一个阅读清单我收集了非常多的关于 BPF 的阅读材料：介绍、文档，也有教程或者示例。这里有很多的材料可以去阅读https://linux.cn/article-9507-1.html

Kubernetes容器网络模型解析 - 51CTO.COM云原生（Cloud Native）可以认为是一套技术体系或生态，它包含2大部分：云（Cloud）和原生（Native）。https://cloud.51cto.com/art/202111/691136.htm