"eBPF 的全称“扩展的伯克利数据包过滤器 (Extended Berkeley Packet Filter)” 来看，它是一种数据包过滤技术，是从 BPF (Berkeley Packet Filter) 技术扩展而来的。\nBPF 提供了一种在 内核事件 和 用户程序 事件发生时安全注入代码的机制，这就让非内核开发人员也可以对内核进行控制。随着内核的发展，BPF 逐步从最初的数据包过滤扩展到了网络、内核、安全、跟踪等，而且它的功能特性还在快速发展中，这种扩展后的 BPF 被简称为 eBPF（早期的 BPF 被称为经典 BPF，简称 cBPF）。实际上，现代内核所运行的都是 eBPF，如果没有特殊说明，内核和开源社区中提到的 BPF 等同于 eBPF 。\n使用场景及分类 根据 eBPF 的功能和使用场景，主要分类三类：\n跟踪 从内核和程序的运行状态中提取跟踪信息，来了解当前系统正在发生什么。\n跟踪类 eBPF 程序主要用于从系统中提取跟踪信息，进而为监控、排错、性能优化等提供数据支撑。\n其中 BCC 工具集中包含的绝大部分工具也都属于这个类型。\n网络 对网络数据包进行过滤和处理，以便了 …"

"在执行 go build 命令的时候，经常需要添加一些参数，或许是为了调试，也或许是为了生成最终部署二进制文件。\n在编译特定包时需要传递参数，格式应遵守“包名=参数列表”，如\ngo build -gcflags -gcflags=\u0026#39;log=-N -l\u0026#39; main.go -gcflags go build 可以用 -gcflags 给_go_编译器传入参数，也就是传给 go tool compile 的参数，因此可以用 go tool compile –help 查看所有可用的参数。\n其中 -m 可以检查代码的编译优化情况，包括逃逸情况和函数是否内联。\n-ldflags go build用 -ldflags 给go链接器传入参数，实际是给go tool link的参数，可以用go tool link –help查看可用的参数。\n常用-X来指定版本号等编译时才决定的参数值。例如代码中定义var buildVer string，然后在编译时用go build -ldflags “-X main.buildVer=1.0” … 来赋值。注意-X只能给string类型变量赋值。"

"Golang中的编译参数\n开发中经常使用 go build 命令来编译我们的程序源码，然后将生成二进制文件直接部署，极其方便。\n对于 go build 有一些参数，对于针对程序源码进行一些编译优化，下面我们对经常使用的一些参数来介绍一下。\n环境变量 环境变量需要在go命令前面设置，如果多个变量的话，中间需要用“空格”分隔。下面我们介绍一个非常常见到的一些环境变量\n$ CGO_ENABLED=1 GOARCH=amd64 GOOS=linux go build -o myserver main.go 除了这里给出的这几个变量外，还有一些其它变量，如 GODEBUG、GOFLAGS、GOPROXY 等，所有支持环境变量都可以在 里找到，有兴趣的话可以看看他们的作用。\n这里重点介绍一下 CGO_ENABLED 环境变量对我们程序的影响。 CGO_ENABLED是用来控制golang 编译期间是否支持调用 cgo 命令的开关，其值为1或0，默认情况下值为1，可以用 go env 查看默认值。\n如果你的程序里调用了cgo 命令，此参数必须设置为1,否则将编译时出错。这里直接用文档 中的一个例子验 …"

"iptables 作为 Linux/Unix 下一款优秀的防火墙软件，在安全方面发挥着极其重要的作用，作为系统管理员来讲一点也不陌生。不过对于一些新手来说，复杂性是一个门槛，Linux厂商为了解决这个问题，于是推出了新的管理工具,如 Centos 下的 Firewalld 和 Ubuntu 下的ufw, 他们对新手十分友好，只需要几个很简单的命令即可实现想要的功能，再不也必为记不住iptables中的四表五键而烦恼了。 那么，是不是有了 firewalld 和 ufw就不需要iptables了呢？并不是的。\n首先我们要清楚firewalld、ufw 与iptables的关系，可以理解为两者只是对iptables其进行了一层封装，它们在用户交互方面做了非常多的改进，使其对用户更加友好，不需要再记住原来那么多命令了。\n而目前对于一些系统管理员来讲，大概率还是会直接使用 iptables，主要原因是灵活性，当然也有一定的历史原因。对比前面两个管理工具，他们也存在一定的问题，如只能对单条规则进行管理，详细参考相关文档。\n另外对于 firewalld 还有图形界面。 …"

"在日常开发中经常会遇到有些镜像在 gcr.io 仓库，其仓库是google提供的，由于国内网络环境的复杂性是无法拉取到这些镜像的，这时候就需要我们想一些办法来实现拉取了。\n这里给出了两种解决方法，一种是直接使用代理，这种可以直接拉取远程镜像到本地。另一种是通过中转的方法，先找一个可以直接拉取到镜像的网络，先将存储到本地，然后再转镜像上传到三方国内可以访问的镜像，如我们最常用镜像 https://hub.docker.com。\n代理方式 使用代理方法的时候，如果通过直接设置 http_proxy 和 https_proxy 这两个环境变量是不可行的。如果是k8s环境的话，可能会使用到 containerd 运行时，这时可能还需要设置 crictl 配置，因此下面将分别介绍这个软件的配置方式。\n如果k8s运行时，使用的是 Docker Engine ，则可以通过 docker 命令管理镜像；如果使用的是 containerd运行时，则需要通过 crictl 命令管理镜像。\n不同运行时需要不同的管理客户端，因此下面我们将一下针对这两个软件配置的不同代理配置。 …"

"在k8s中的时间会提示证书过期问题，如\n# kubectl get nodes Unable to connect to the server: x509: certificate has expired or is not yet valid 这里我们介绍一下续期方法。\n注意：当前集群通过 kubeadm 命令创建。\nkubeadm 安装得证书默认为 1 年，注意原证书文件必须保留在服务器上才能做延期操作，否则就会重新生成，集群可能无法恢复。\n准备 这里先查看一下测试集群的证书过期时间\n# kubeadm certs check-expiration [check-expiration] Reading configuration from the cluster... [check-expiration] FYI: You can look at this config file with \u0026#39;kubectl -n kube-system get cm kubeadm-config -o yaml\u0026#39; CERTIFICATE EXPIRES RESIDUAL TIME …"

"建议参考官方文档 https://istio.io/latest/zh/docs/setup/install/virtual-machine/ ，这里提醒大家对于命令中文版部分命令与英文版不一致，请以 英文版 为准。\n对于istio在vm上的安装教程主要分为三部分。首先是在k8s的master节点生成vm连接主节点的一些配置信息，其实是在vm上应用这些配置信息，最后也就是验证连接是否成功。\n本篇主要介绍“单网络”的情况， 对于”多网络“请自行参考官方文档。\nvm环境准备 生成vm通讯配置信息 这里主要介绍一些新手迷惑的部分。如环境变量设置及vm注册的方式\n设置环境变量 在设置变量时，对于”单网络“来讲 CLUSTER_NETWORK 和 VM_NETWORK 保留空值即可。如我这里设置如下\n$ VM_APP=\u0026#34;myapp\u0026#34; $ VM_NAMESPACE=\u0026#34;vm\u0026#34; $ WORK_DIR=\u0026#34;/root/myapp\u0026#34; $ SERVICE_ACCOUNT=\u0026#34;vm-sa\u0026#34; $ CLUSTER_NETWORK=\u0026#34;\u0026#34; $ …"

"什么是 docker buildx Docker Buildx是一个CLI插件，它扩展了Docker命令，完全支持Moby BuildKit builder toolkit提供的功能。它提供了与docker build相同的用户体验，并提供了许多新功能，如创建作用域生成器实例和针对多个节点并发构建。\nDocker Buildx包含在Docker 19.03中，并与以下Docker Desktop版本捆绑在一起。请注意，必须启用“实验特性”选项才能使用Docker Buildx。\nDocker Desktop Enterprise version 2.1.0 Docker Desktop Edge version 2.0.4.0 or higher\n用法 Usage: docker buildx [OPTIONS] COMMAND Extended build capabilities with BuildKit Options: --builder string Override the configured builder instance Management Commands: …"

"在使用kubenetes的过程中，如何将服务开放到集群外部访问是一个重要的问题。当使用云平台（阿里云、腾讯云、AWS等）的容器服务时，我们可以通过配置 service 为 LoadBalancer 模式来绑定云平台的负载均衡器，从而实现外网的访问。但是，如果对于自建的 kubernetes裸机集群，这个问题则要麻烦的多。\n祼机集群不支持负载均衡的方式，可用的不外乎NodePort、HostNetwork、ExternalIPs等方式来实现外部访问。但这些方式并不完美，他们或多或少都存在的一些缺点，这使得裸机集群成为Kubernetes生态系统中的二等公民。\nMetalLB 旨在通过提供与标准网络设备集成的Network LB实施来解决这个痛点，从而使裸机群集上的外部服务也尽可能“正常运行”，减少运维上的管理成本。它是一种纯软件的解决方案，参考 https://kubernetes.github.io/ingress-nginx/deploy/baremetal/。\n从 v0.13.0 版本开始，官方对解决方案进行了部分调整，操作步骤简洁一些，建议使用最新版本， …"

"使用服务入口（Service Entry） 来添加一个服务入口到 Istio 内部维护的服务注册中心。添加了服务入口后，Envoy 代理可以向服务发送流量，就好像它是网格内部的服务一样，可参考 https://istio.io/latest/zh/docs/concepts/traffic-management/#service-entries。\n简单的理解就是允许内网向外网服务发送流量请求，但你可能会说正常情况下在pod里也是可以访问外网的，这两者有什么区别呢?\n确实默认情况下，Istio 配置 Envoy 代理可以将请求传递给外部服务。但是无法使用 Istio 的特性来控制没有在网格中注册的目标流量。这也正是 ServiceEntry 真正发挥的作用，通过配置服务入口允许您管理运行在网格外的服务的流量。\n此外，可以配置虚拟服务和目标规则，以更精细的方式控制到服务条目的流量，就像为网格中的其他任何服务配置流量一样。\n为了更好的理解这一块的内容，我们先看一下普通POD发送请求的流程图普通 Pod 请求\n创建 ServiceEntry 资源 举例来说：\nsvc-entry.yaml …"