使用系统软件包管理器安装
yum install -y inotify-tools |
安装后包含2个命令： inotifywait , inotifywatch,较为常用的命令是 inotifywait
编译安装
此处安装版本 3.22.6.0 [1]
wget https://github.com/inotify-tools/inotify-tools/archive/refs/tags/3.22.6.0.tar.gz |
Centos 7 默认安装的 gcc 版本太低，无法满足 fswatch-1.17.1 的编译配置要求，需要首先升级 gcc 版本，本示例中 gcc-8.3.0 安装位置为 /usr/local/gcc-8.3.0/，如果系统安装的 gcc 版本符合要求，无需在 ./configure 时指定 gcc 环境变量 CXX=/usr/local/gcc-8.3.0/bin/g++。
wget https://github.com/emcrisostomo/fswatch/archive/refs/tags/1.17.1.tar.gz |
常用选项。参考文档安装 man 手册 后可以查看详细的帮助文档
fswatch 会为监控到的每条事件记录以下信息
timestamp - 事件发生的时间戳path - 触发事件的文件（夹）路径event types - 空格分割的事件类型| 选项 | 说明 | 示例 |
|---|---|---|
-0, --print0 |
ASCII NUL character (\0) as line separatorSince file names can potentially contain any character but NUL, this option assures that the output of fswatch can be safely parsed using NUL as delimiter, such as using xargs -0 and the shell builtin read -d ''. |
使用示例 |
-1, --one-event |
Exit fswatch after the first set of events is received | |
--event name |
can be used multiple times | |
-e, --exclude regexp |
Exclude paths matching regexp, Multiple exclude filters can be specified using this option multiple times | |
-i, --include regexp |
Include paths matching regexp | |
-f, --format-time format |
Print the event time using the specified format | |
-I, --insensitive |
Use case insensitive regular expressions | |
-m, --monitor name |
Uses the monitor specified by name 可用的 monitor： - inotify_monitor- poll_monitor |
|
-r, --recursive |
Watch subdirectories recursively | |
-t, --timestamp |
Print the event timestamp. | |
-u, --utf-time |
Print the event time in UTC format. When this option is not specified, the time is printed using the system local time, as defined by localtime | |
-l, --latency latency |
监听间隔，默认1s |
常用事件
| 事件 | 说明 | 示例 |
|---|---|---|
NoOp |
Idle event, optionally issued when no changes were detected | |
Created |
The object has been created. | |
Updated |
The object has been updated. The kind of update is monitor-dependent. | |
Removed |
The object has been removed. | |
Renamed |
The object has been renamed. | |
OwnerModified |
The object’s owner has changed. | |
AttributeModified |
An object’s attribute has changed. | |
MovedFrom |
The object has moved from this location to a new location of the same file system. | |
MovedTo |
The object has moved from another location in the same file system into this location. | |
IsFile |
The object is a regular file. | |
IsDir |
The object is a directory. | |
IsSymLink |
The object is a symbolic link. | |
Link |
The object link count has changed. | |
Overflow |
The monitor has overflowed. |
以下示例中监视文件 nohup.out，输出事件的每一行使用 \0 分割，read 读取时也使用 \0 ("") 分割，可以防止文件名中包含了空格，使用 read 时读取文件名不全。
fswatch -0 nohup.out | while read -d "" file; do echo ${file}; done |
fswatch -0 [opts] [paths] | xargs -0 -n 1 -I {} [command] |
fswatch -0 will split records using the NUL character.
xargs -0 will split records using the NUL character. This is required to correctly match impedance with fswatch.
xargs -n 1 will invoke command every record. If you want to do it every x records, then use xargs -n x.
xargs -I {} will substitute occurrences of {} in command with the parsed argument. If the command you are running
does not need the event path name, just delete this option. If you prefer using another replacement string, substi‐
tute {} with yours.
以下示例监视文件变化后进行备份
fswatch -0 nohup.out | xargs -0 -I {} cp {} {}.`date +%Y%m%d%H%M%S` |
以上命令中
date +%Y%m%d%H%M%S只会被计算一次，假如第一次执行时date +%Y%m%d%H%M%S=nohup.out.20230609132143，那么之后每次触发xargs，变量date +%Y%m%d%H%M%S的值都是nohup.out.20230609132143，不会被重新计算
执行以下命令，过一段时间后会输出 Event queue overflow
fswatch -0 nohup.out | xargs -0 -I {} cp {} {}.`date +%Y%m%d%H%M%S` |
解决方法 可以选择以下之一。
使用 poll_monitor monitor 而不是默认的 inotify_monitor
fswatch -0 --monitor=poll_monitor nohup.out | xargs -0 -I {} cp {} {}.`date +%Y%m%d%H%M%S` |
此限制是因为内核参数限制，主要参数 fs.inotify.max_queued_events [1]
查看内核参数 fs.inotify.max_queued_events 的值，默认值为 16384
sysctl fs.inotify.max_queued_events |
修改默认值后，重新测试，结果正常
sysctl fs.inotify.max_queued_events=1000000 |
永久修改此参数的值，可以将其写入内核配置文件 /etc/sysctl.conf
yum install -y lftp |
查看帮助信息
lftp -h |
命令格式
lftp ${USER}:${PASSWORD}@${FTPIP}:${FTPPORT} |
在一条 shell 命令中执行登陆、上传、退出操作
lftp -u ${USER},${PASSWORD} -p ${FTPPORT} ${FTPIP} -e "put /1.mp4 && exit" |
pip install tencentcloud-sdk-python-intl-en |
import json |
Kubernetes Metrics Server 从 kubelet 收集资源使用指标（情况）并通过 Metrics API 将其暴露给 Kubernetes API Server，以供 HPA(Horizontal Pod Autoscaler) 和 VPA(Vertical Pod Autoscaler) 使用。kubectl top 也使用 Metrics API。[1]
Kubernetes Metrics Server 安装之前必须要开启 kube api-server 的聚合层功能以及认证鉴权功能 [3]
检查 Kubernetes API Server 是否启用了聚合层功能及认证鉴权功能
ps -ef | grep apiserver | grep -E "authorization-mode|enable-aggregator-routing" |
输出中包含了 --authorization-mode=Node,RBAC 和 --enable-aggregator-routing=true，表示已开启对应功能。如若未开启，修改 api-server 的 manifest 文件 /etc/kubernetes/manifests/kube-apiserver.yaml，在 kube-apiserver 的启动参数中添加 --enable-aggregator-routing=true 和 --authorization-mode=Node,RBAC
以下命令使用 yaml 文件安装最新版本 Metrics Server [2]
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml |
参考部署步骤 部署后，Metrics Server 的 Pod 一直处于未就绪状态
kubectl get pods -A | grep metrics |
检查 Pod 日志
kubectl logs -n kube-system metrics-server-5cdf47479d-rwtd6 |
根据日志提示，由于 metrics-server 未获得TLS Bootstrap 签发证书的导致访问各节点资源时报错。
--kubelet-insecure-tls 不验证 Kubelet 的 CA 证书 spec: |
参考部署步骤 部署后，Metrics Server 的 Pod 一直处于未就绪状态，检查 Pod 日志
kubectl logs -n kube-system metrics-server-5cdf47479d-rwtd6 |
根据日志显示，API Server 的主机名解析存在问题。这是因为节点主机名在集群的 DNS 中无法解析导致，可以通过在 Metrics Server 的 Pod 中手动添加解析解决
metadata: |
Metrics Server 部署成功后，无法获取所在节点的主机的监控信息，获取其他主机的监控信息正常，具体信息如下
kubectl get nodes -o wide |
查看 Metrics Server Pod 日志，显示
kubectl logs -n kube-system metrics-server-c48655c66-jxwpt |
根据日志显示，是因为无法连接节点的 kubelet (端口 10250) 导致。为了定位问题，修改 Metrics Server 的部署 Yaml 文件，在其中加入一个容器，来方便使用工具测试问题。参考以下内容，在 Pod 中加入容器 centos:centos7.9.2009
apiVersion: apps/v1 |
重新部署后，登陆容器 centos7，安装所需工具进行测试。根据日志信息，首先测试 Pod 是否能连接到节点的 kubelet
curl -v 172.31.16.124:10250 |
根据以上测试，Metrics Server 的 Pod 无法连接所在节点 k8s-worker1（172.31.16.124）的 kubelet （172.31.16.124:10250），可以正常连接其他节点的 kubelet。由此可以确定问题原因。
考虑到 Metrics Server 的 Pod 只是访问不到宿主节点所在的 kubelet，可以访问其他节点的 kubelet，梳理其中的网络连同流程发现，在访问其他节点的 kubelet 时，Metrics Server Pod 的报文在流出宿主节点前，会被 SNAT 为宿主节点的出口 IP，报文源 IP 为 宿主节点的 IP。而访问宿主节点的 kubelet 的报文，其源 IP 为 Metrics Server Pod 的 IP，目的 IP 为宿主节点的 IP。怀疑可能因为集群节点上的 iptables 允许集群节点的 IP 访问 kubelet，而 Pod 的 IP 未被允许访问 kubelet。为验证此猜想，在节点 k8s-worker1 的 iptables 添加允许 Metrics Server Pod 的 IP 访问的规则进行测试
iptables -I INPUT 7 -s 10.244.4.138 -j ACCEPT |
再次测试和 kubelet 的连通性，发现可以正常连通，再次检查 kubectl top node，可以查到所有节点的监控数据
curl -v 172.31.16.124:10250 |
默认情况下，集群中的 master 节点被设置成了污点，以确保只有控制平面的 Pod 才能调度部署到主节点上。
kubectl describe node k8s-master1 |
Master 节点包含 2 个污点
node-role.kubernetes.io/control-plane:NoSchedulenode-role.kubernetes.io/master:NoSchedule这 2 个污点将阻止 Pod 调度到这个节点上面，除非有 Pod 能够容忍这个污点(Taints)，通常能容忍这个污点的都是控制平面的 Pod。
kubectl describe pod -n kube-system kube-proxy-2cslw |
命令格式 [1]
./ossutil64 ls oss://bucketname[/prefix] [-s] [-d] [--limited-num] [--marker] [--include] [--exclude] [--version-id-marker] [--all-versions] |
ossutil64 du oss://test-bucket |
比如 A 域名使用 B 域名的共享缓存，测试的时候先访问一条 B 域名中的新资源，使用 B 域名查看对应的缓存状态响应头，第一次访问应该是 X-Cache: MISS，重新访问一次，应该变成 X-Cache: HIT。接下来使用 A 域名访问，如果首次访问结果即为 HIT，说明共享缓存配置成功
curl -v -I B/test.png |
Pod 是由一个或多个容器构成的集合，被 Kubernetes 作为一个整体进行部署和调度，是 Kubernetes 调度的最小单元。同一个 Pod 内的容器共享 network namespace、UTS nanespace
当用户在 Kubernetes 中创建了一个 Pod 后，CRI 和 CNI 协同创建 Pod 所属容器，并为 Pod 中的容器初始化网络协议栈的具体过程如下
用户在 Kubernetes 中创建了一个 Pod 后，Kubelet 接收到创建新 Pod 的任务，首先调用 CRI 创建 Pod 内的容器
Pod 中第一个被创建的容器是 pause 容器。pause 容器中运行着一个功能非常简单的 C 程序，具体逻辑是把自己永远阻塞，没有实际的业务逻辑，主要功能是用来占用一个 network namespace。
创建 pause 容器，使用 docker none 网络模式，创建出来的容器除了 lo 回环网卡外没有其他网络设备。
Pod 内的其他用户容器通过加入 pause 容器已占用的 network namespace 的方式共享同一个 network namespace。对应于 docker 的 Container 模式
其他用户容器都使用 pause 容器的主机名，但并不使用同一个 UTS namespace。
CNI 负责 Pod 中容器的网络初始化工作。主要为 Pod 内的 pause 容器添加 eth0 网卡、分配 IP、配置网关等。
pause 容器是 Pod 中被创建的第一个容器，Pod 中的其他容器通过使用 pause 容器的 network namespace 共享网络协议栈和主机名。它是 Pod 中其他容器的父容器。
1.8 以后版本默认不启用 PID namespace 共享。每个容器拥有独立的 PID namespace。
以下步骤通过 docker 演示 Pod 容器创建的整个过程。首先，创建 pause 容器
docker run --name=test-pause \ |
然后在 Pod 中运行其他容器，本示例启动 2 个应用容器，一个 nginx 容器，里面启动了 nginx 服务，一个自定义的容器，里面包含常用工具
docker run --name=pod_nginx_test \ |
进入 pod_centos_test 容器，查看网络、端口、主机名信息
hostname |
pause 容器的主机名，但实际并未共享 UTS namespace。可以通过找到对应 docker 容器的进程 PID，找到对应进程的 namespace 信息对比确认
4 S root 35333 35311 0 80 0 - 6218 skb_wa 01:01 ? 00:00:00 ping 127.1
ls -l /proc/35333/ns/
total 0
lrwxrwxrwx 1 root root 0 Apr 8 01:13 cgroup -> cgroup:[4026531835]
lrwxrwxrwx 1 root root 0 Apr 8 01:02 ipc -> ipc:[4026532664]
lrwxrwxrwx 1 root root 0 Apr 8 01:02 mnt -> mnt:[4026532662]
lrwxrwxrwx 1 root root 0 Apr 8 01:02 net -> net:[4026532588]
lrwxrwxrwx 1 root root 0 Apr 8 01:02 pid -> pid:[4026532665]
lrwxrwxrwx 1 root root 0 Apr 8 01:13 pid_for_children -> pid:[4026532665]
lrwxrwxrwx 1 root root 0 Apr 8 01:13 user -> user:[4026531837]
lrwxrwxrwx 1 root root 0 Apr 8 01:02 uts -> uts:[4026532663]
ps -elf | grep nginx
4 S root 34909 34887 0 80 0 - 2233 sigsus 00:59 ? 00:00:00 nginx: master process nginx -g daemon off;
ls -l /proc/34909/ns/
total 0
lrwxrwxrwx 1 root root 0 Apr 8 01:14 cgroup -> cgroup:[4026531835]
lrwxrwxrwx 1 root root 0 Apr 8 01:00 ipc -> ipc:[4026532660]
lrwxrwxrwx 1 root root 0 Apr 8 01:00 mnt -> mnt:[4026532658]
lrwxrwxrwx 1 root root 0 Apr 8 01:00 net -> net:[4026532588]
lrwxrwxrwx 1 root root 0 Apr 8 01:00 pid -> pid:[4026532661]
lrwxrwxrwx 1 root root 0 Apr 8 01:14 pid_for_children -> pid:[4026532661]
lrwxrwxrwx 1 root root 0 Apr 8 01:14 user -> user:[4026531837]
lrwxrwxrwx 1 root root 0 Apr 8 01:00 uts -> uts:[4026532659]
ps -elf | grep pause
4 S root 34239 34221 0 80 0 - 241 ia32_s 00:51 ? 00:00:00 /pause
ls -l /proc/34239/ns/
total 0
lrwxrwxrwx 1 root root 0 Apr 8 01:15 cgroup -> cgroup:[4026531835]
lrwxrwxrwx 1 root root 0 Apr 8 00:51 ipc -> ipc:[4026532585]
lrwxrwxrwx 1 root root 0 Apr 8 00:51 mnt -> mnt:[4026532583]
lrwxrwxrwx 1 root root 0 Apr 8 00:51 net -> net:[4026532588]
lrwxrwxrwx 1 root root 0 Apr 8 00:51 pid -> pid:[4026532586]
lrwxrwxrwx 1 root root 0 Apr 8 01:15 pid_for_children -> pid:[4026532586]
lrwxrwxrwx 1 root root 0 Apr 8 01:15 user -> user:[4026531837]
lrwxrwxrwx 1 root root 0 Apr 8 00:51 uts -> uts:[4026532584]以上观察可以看到，Pod 中的容器共享了 network namespace，未共享 UTS namespace。Kubernetes 中 Pod 中的容器同理。
localhost 互相访问ServiceAccount 就像 Pod、Secret、ConfigMap 等一样，都是资源，属于 namespace 级别，作用在单独的命名空间。默认情况，每个 namespace 都有一个默认的 ServiceAccount。
kubectl get serviceaccount |
namespace 中的每个 Pod 都和一个 ServiceAccount 关联，它代表了运行在 Pod 中的应用程序的身份证明。Pod 中的每个容器都会挂载此 ServiceAccount token
在 Pod 的 manifest 定义文件中，可以通过指定账户名称的方式将一个 ServiceAccount 关联到 Pod。如果不显示指定 ServiceAccount 的账户名称，Pod 会使用 namespace 中默认的 ServiceAccount。可以将不同的 ServiceAccount 关联给不同的 Pod 来控制每个 Pod 可以访问的资源。
当 API 服务接收到一个带有认证 token 的请求时， API 会用这个 token 来验证发送请求的客户端所关联的 ServiceAccount 是否允许执行请求的操作。
以 rancher 相关的 ServiceAccount 为例，查看 ServiceAccount 信息
kubectl get serviceaccount -n cattle-system |
以下输出名为 rancher 的 ServiceAccount 信息
kubectl describe sa rancher -n cattle-system |
ServiceAccount 主要包含了密钥（token）信息，客户端 (Pod)请求 API Service 时使用的 token 文件（如 /var/run/secrets/kubernetes.io/serviceaccount/token）持有 ServiceAccount 的 token 。
kubectl describe secret rancher-token -n cattle-system |
在新建了 ServiceAccount 之后，若要将它赋值给 Pod，通过在 Pod 定义中的 spec.serviceAccountName 字段上配置 ServiceAccount 名称来分配。Pod 的 ServiceAccount 必须在 Pod 创建时进行配置，后续不能被修改
从 Kubernetes 1.8.0 开始，RBAC（基于角色的权限控制）授权插件升级为 GA（通用可用性），并在大多数集群上默认开启（比如通过 kubeadm 部署的集群）。RBAC 会阻止未授权的用户查看和修改集群状态，默认的 ServiceAccount 不允许查看集群状态。
RBAC 授权规则是通过四种资源对象来进行配置的，他们可以分为 2 个组 [1]
Role、ClusterRole - 一组代表相关权限的规则，他们指定了在资源上可以执行哪些操作（动词）RoleBinding、ClusterRoleBinding - 将角色中定义的权限赋予一个或者一组用户。它包含若干主体（用户、组或者 ServiceAccount）的列表和对这些主体所获得的角色的引用。
Role和RoleBinding属于 namespace 范围的资源，必须在 namespace 中配置
ClusterRole和ClusterRoleBinding是集群作用域的资源一个 RoleBinding 可以引用某 ClusterRole 并将该 ClusterRole 绑定到 RoleBinding 所在的名字空间。但是，RoleBinding 不能授予主体集群级别的资源的访问权限，即使它引用了一个 ClusterRoleBinding
根据参考文档说明，获取到 key 和 secret
Python3 sdk 可以使用 godaddypy
godaddypy 主要提供了 2 个类，分别为
account - 使用 key 和 secret 为 client 生成鉴权头部client - 连接 Godaddy API 并执行相应的请求具体使用方法可以查看帮助信息，或者查看 Godaddy API 参考文档
help(godaddypy) |
import godaddypy |
根据 Godaddy API 文档说明，获取域名，每次默认获取 500 个，最多可以一次性获取 1000 个。
# 获取域名，默认 100 个。如果账户内的域名数量少于 100，则一次性可以获取完毕，多于 100，获取前 100 个 |
以下是几种可用卷类型：
emptyDir - 用于存储临时数据的简单空目录，生命周期和 Pod 一致。hostPath - 用于将宿主机中的文件系统挂载到 Pod 中，生命周期不与 Pod 绑定。gitRepo - 通过拉取 Git 仓库的内容来初始化的卷。已弃用nfs - 挂载到 Pod 中的 NFS 共享文件系统。configMap、secret - 用于将 Kubernetes 中的部分资源和集群信息公开给 Pod 的特殊类型的卷persistentVolumeClaim - 简称 PVC，使用预置和动态配置的持久卷。downwardAPI - 在不使用 Kubernetes 客户端或 API 服务器的情况下获得自己或集群的信息 [5]emptyDir 表示与 Pod 生命周期相同的临时目录。[4]
emptyDir 配置示例
apiVersion: v1 |
emptyDir.medium - 表示此目录应使用哪种类别的存储介质，默认为 ""，表示使用节点的默认介质（一般是节点的本地磁盘）。可选值必须为 "" 或者 Memory， Memory 表示使用 tmfs (存在内存而非硬盘)PersistentVolume (PV)（持久化卷），是对底层的共享存储的一种抽象，PV 由管理员进行创建和配置，它和具体的底层的共享存储技术的实现方式有关，比如 Ceph、GlusterFS、NFS 等，都是通过插件机制完成与共享存储的对接。[1]
PersistentVolumeClaim（PVC）是由用户发起的对存储的请求。 它类似于 Pod。 Pod 消耗节点资源，PVC 消耗 PV 资源。Pod 可以请求特定级别的资源（CPU和内存）。PVC 可以请求特定的存储大小和访问模式（例如，可以一次读/写或多次只读）匹配的 PV。
PVC 和 PV 中的 spec 关键字段要匹配，比如存储（storage）大小、读写模式，才能申请到对应的 PV 中的资源。PV 和 PVC 处于一一对应的关系。 [2]
PV 可以设置三种回收策略：
PV卷阶段状态
Available – 资源尚未被 claim 使用Bound – 卷已经被绑定到 claim 了Released – claim 被删除，卷处于释放状态，但未被集群回收。Failed – 卷自动回收失败Kubernetes 的 Service 代表的是 Kubernetes 后端服务的入口，它主要包含服务的访问 IP（虚拟 IP）和端口，工作在 L4.
Service 只存储服务的入口信息（IP:PORT），不存储后端 Pod 信息，Service 是通过 Label Selector 选择与之匹配的后端 Pod。当被 Service 选择的后端 Pod 运行且能正常向外提供服务时，Kubernetes 的 Endpoint Controller 会生成一个新的 Endpoint 对象，指向此 Pod 的 IP:PORT。Service 接收到访问请求，会将请求转发到对应的 Endpoint。同时，Service 的访问 IP 和 Endpoint/Pod 的 IP 都会在 Kubernetes 的 DNS 服务里面进行注册以记录域名和 IP 的对应关系，因此用户可以在集群中通过域名的方式访问 Service 和 Pod。
用户创建 Service 后，Kubernetes 会从集群的可用服务 IP 池中为 Service 分配一个稳定的集群内访问 IP，称为 Cluster IP。Kubernetes 还会通过注册 DNS 条目为 Cluster IP 分配 域名（主机名）。Cluster IP 和 域名 在集群内是独一无二的，并且在服务的整个生命周期中保持不变，直到将 Service 从集群中删除，Kubernetes 才会释放 Cluster IP 和 域名 。通过此方法，Service 作为代理，向客户端提供了稳定不变的访问后端服务的入口。
Service 除了作为 代理 功能，同时也提供了 负载均衡 和 高可用。当后端的 Pod 有多个时，默认会通过 轮询 将请求流量均匀分布到多个 Pod 上，当某个 Pod 不可用是，Service 不会将请求调度到问题节点。
Kubernetes 使用节点上运行的 kube-proxy 组件管理各 Service 和后端 Pod 的连接。kube-proxy 是一个基于出战流量的 负载均衡控制器，它监控 Kubernetes API Service 并持续将 Service IP （ClusterIP）映射到运行状况良好的后端 Pod，具体实现是通过主机上的 iptables/IPVS 的规则。访问 Service 的 IP 会被这些（路由）规则直接 DNAT 到后端 Pod 的 IP。
kube-proxy 默认使用 iptables 模式实现 Service 的代理转发和负载均衡。检查 kube-proxy 使用的代理模式
本示例使用相关信息如下
kubectl get services |
针对 api-service，后端的 Pod 就绪后，生成了 ENDPOINTS，kube-proxy 会为该服务创建以下 iptables 规则
-A PREROUTING -m comment --comment "kubernetes service portals" -j KUBE-SERVICES |
具体工作流程如下：
PREROUTING 链的流量会被跳转到 KUBE-SERVICES 自定义链api-service 的访问数据包（目的地址为 10.106.126.96:10302）在 PREROUTING 链中被 -d 10.106.126.96/32 -p tcp -m comment --comment "default/api-service:api-pord cluster IP" -m tcp --dport 10302 匹配到，根据规则跳转到自定义链 KUBE-SVC-DVTQLPR6DVOLBZS4KUBE-SVC-DVTQLPR6DVOLBZS4 中，实现了负载均衡，一半的流量会被跳转到链 KUBE-SEP-JXBL7O23XHVFQV2I，另一半的流量会被跳转到 KUBE-SEP-BBPDSOPRICLINLPYKUBE-SEP-JXBL7O23XHVFQV2I 和 KUBE-SEP-BBPDSOPRICLINLPY 中，流量分别被 DNAT 分配到了后端的 Pod（就绪的 Endpoints）。POSTROUTING 链上要对数据包做 SNAT 处理，以确保客户端接收到的数据包的源地址是其发送请求时的目标地址。通过以上 kube-proxy 管理的规则，Service 实现了对后端 Pod 的服务代理及负载均衡功能。
综上所述，iptables 模式最主要的链是 KUBE-SERVICES 、KUBE-SVC-*、KUBE-SEP-*
KUBE-SERVICES - 访问集群服务的数据包入口，它会根据匹配到的目标 IP:PORT 将数据包分发到相应的链 KUBE-SVC-*KUBE-SVC-* - 相当于一个负载均衡器，它会将数据包平均分配到 KUBE-SEP-* 链。每个 KUBE-SVC-* 链后面的 KUBE-SEP-* 链的数量和 Service 后端就绪的 Pod 数量一致。KUBE-SEP-* - 通过 DNAT 将数据包的目的地址（IP:PORT）修改为后端就绪的 Pod 的 IP:PORT，从而将流量转发到相应的 Podkube-proxy 的 iptables 模式因为使用 DNAT 转发数据包，存在一定的性能损耗，另外，当集群中的 Service 数量上万时，节点上的 iptables rules 会非常庞大，对管理是个不小的负担，性能也会大打折扣。
Kubernetes DNS 服务的功能，是用来解析 Kubernetes 集群内的 Pod 和 Service 的域名，一般只供集群内部使用，不给外部使用。
默认情况下，Kubernetes DNS 应用部署后，会对外暴露一个 Service，集群内的容器通过访问该 Service 获得域名解析服务，这个 Service 的 ClusterIP 一般情况下都是固定的。
kubectl get services -n kube-system -o wide |
当 Kubernetes DNS 服务获得 ClusterIP 后，系统会给 Kubelet 配置启动参数指定 DNS Service 的 ClusterIP，DNS Service 的 IP 会在容器启动时传入，并写入容器系统的 DNS 配置中（一般为 /etc/resolv.conf 文件）
根据 kubelet 服务的启动命令，配置参数可以写在以下相关配置文件中
systemctl status kubelet -l |
DNS 的相关配置在文件 /var/lib/kubelet/config.yaml 中，主要选项为 clusterDNS
apiVersion: kubelet.config.k8s.io/v1beta1 |
VNC 是一个图形桌面共享系统，可以通过远程连接的方式连接到服务器的图形系统以控制操作系统VNC 包括以下四个部分 ： vncserver，vncviewer，vncpassword 及 vncconnect。VNC client 端通过 VNC 协议远程连接到 vnc server 端，进行桌面共享及交互；
安装之前首先要确保系统已安装图形系统，本文以 GNOME Desktop 为图形桌面系统，执行以下命令检查是否已安装 GNOME Desktop，如果未安装，使用命令 yum groupinstall "GNOME Desktop" 安装
yum grouplist |
桌面系统安装后，使用以下命令，安装 tigervnc
yum install -y tigervnc-server |
可以参考 /lib/systemd/system/vncserver@.service 中的指示，生成服务配置文件：
cp /lib/systemd/system/vncserver@.service /etc/systemd/system/vncserver@:1.service |
修改以下行，将其中的 <USER> 改为要远程登录的用户名，例如 root
ExecStart=/usr/bin/vncserver_wrapper root %i |
如果有多个用户需要远程连接，可以重复以上步骤，建立多个配置文件，如 /etc/systemd/system/vncserver@:2.service，各个服务之间互不影响，关闭一个服务，不影响其他的 vnc 服务 (如关闭： vncserver@:2.service，vncserver@:1.service的 vnc 远程依旧可以使用)
修改服务文件后，使用以下命令重新加载服务启动脚本：
systemctl daemon-reload |
启动服务：
systemctl start vncserver@:1.service |
服务启动后，会监听 5901 端口，如果有第二个服务，会监听在 5902 端口，以此类推，防火墙需要放通此端口
切换到需要 vnc 远程登录的用户，使用以下命令配置 vnc 远程登录用户的密码(只是 vnc 登录时使用的密码，非系统用户密码)
[root@localhost ~]# su - USER |
设置 vncpasswd 密码后，在账号的家目录里就会自动建立 .vnc 文件，其中包括对应用户的 vnc 相关的日志
配置完成后，下载客户端 进行远程登录
vncserver@:1.service 服务启动失败，端口未监听
netstat -anutp | grep LIST |
解决方法 配置登陆用的 VNC 密码，重启服务
su - root |
激活密钥： NZ4RR-FTK5H-H81C1-Q30QH-1V2LA
Centos 7 server版本（无图形界面）安装使用 Vmware workstation 参考链接
aws workspace 中不兼容 Vmware workstation
参考 Centos7 server 中安装使用 Vmware workstation ，安装后，vmware 无法启动
/etc/rc.d/init.d/vmware start |
执行以下命令 [1]
vmware-modconfig --console --install-status |
查看内核版本
uname -r |
使用命令启动，报错
/sbin/rabbitmq-server -v |
关键错误信息 Protocol 'inet_tcp': register/listen error: ehostunreach，根据提示，可能是某个地址不可达，rabbitmq 启动时需要连接 epmd ，默认端口为 4369，在本地测试连接此端口，发现不通 [1]
curl -v 127.0.0.1:4369 |
根据输出的错误可知，是因为 127.0.0.1 无法连接，检查 iptables 防火墙策略，发现未允许回环网卡访问，在 iptables 中添加以下规则允许回环网卡访问
*filter |
允许回环网卡访问后，重新测试连接 epmd ，可以正常连接，重新启动 rabbitmq-server 正常。
curl -v 127.0.0.1:4369 |
Macvlan 本身是 linxu kernel 模块
Macvlan 接口是物理以太网接口的虚拟子接口，Macvlan 允许用户在一个物理网络接口上面配置多个虚拟的网络接口，每个 Macvlan 接口都有自己的区别与父接口的 MAC 地址，并且可以像普通的物理网络接口一样分配 IP 地址。使用 Macvlan 技术实现的效果是一块物理网卡可以绑定多个 IP 地址，并且每个 IP 地址有自己独立的 MAC 地址。
Macvlan 虚拟出来的虚拟网卡，在逻辑上和物理网卡是对等的。使用 Macvlan 的虚拟网卡要和父接口在同一个网段。
Macvlan 的最大优点是性能极好，相比其他方式，macvlan 不需要创建 Linux bridge，而是直接通过interface 连接到物理网络。
为保证父接口能接收多个不同 MAC 地址的网络包，需要开启网卡的 混杂模式
本示例演示 docker 环境中使用 macvlan。首先创建使用 macvlan 驱动的 network，Docker 中 macvlan 只支持 bridge 模式 [1]
docker network create -d macvlan --subnet=192.168.142.0/24 \ |
在 docker 环境中，创建网络时，会自动将宿主机网卡设置为混杂模式，此时查看网卡信息，未显示混杂模式，但是查看
dmesg日志，会看到网卡进入了混杂模式
[93203.228311] device ens33 entered promiscuous mode
运行容器并连接到新建的 macvlan 网络 macvlan1
docker run -itd --name test01 \ |
使用命令 docker exec -it test01 bash 进入容器查看容器的 IP 地址信息，可以看到容器中的网卡类型为 macvlan，模式为 bridge，网关为 docker 网络 macvlan1 中配置的网关。
ip -d add |
测试容器可以和宿主机网络一样访问外网。
此时检查宿主机网卡信息，系统上只有 lo，ens33，docker0，未出现其他网卡。
ip -d link |
在另一个 docker 节点上同样配置 docker 网络和容器
docker network create -d macvlan --subnet=192.168.142.0/24 \ |
进入容器 test01 ，访问到另一个节点上的容器的连通性
ping 192.168.142.12 |
进入容器 test01 ，测试和宿主机 ip 的连通性，结果发现不通，原因为：在 macvlan 虚拟网络中，父接口（物理网卡）相当于一个交换机，对于其子 macvlan 网卡的数据包，只进行转发而不处理，于是造成了使用本机 macvlan 网卡的虚拟 IP 无法和本机物理网卡的 IP 通信。
ping 192.168.142.10 |
Linux 的 namespace 的作用是 隔离内核资源，目前主要实现了以下 namespace
mount namespace - 文件系统挂载点UTS namespace - 主机名IPC namespace - POSIX 进程间通信消息队列PID namespace - 进程 pid 数字空间network namespace - networkuser namespace - user ID 数字空间其中，除了 network namespace，其他 namespace 的操作需要使用 C 语言调用系统 API 实现。network namespace 的增删改查功能已经集成到了 Linux 的 ip 工具集的 netns 子命令中
Linux 里面的 namespace 给处在其中的进程造成 2 个错觉：
默认情况下，Linux 里面的所有进程处在和宿主机相同的 namespace ，即初始 namespace 里，默认享有全局系统资源。
network namespace 的增删改查功能已经集成到了 Linux 的 ip 工具集的 netns 子命令中，因此在 Linux 系统中，对 network namespace 的操作主要使用 ip netns 命令
ip netns help |
使用以下命令创建名为 netns1 的 network namespace
ip netns add netns1 |
以下命令查看系统中的 network namespace
ip netns list |
新的 network namespace 创建后，系统会在 /var/run/netns/ 下面生成一个同名的挂载点
ls -l /var/run/netns/ |
此挂载点的主要作用一方面是方便对 namespace 的管理，一方面是使 namespace 即使没有进程运行也能继续存在。
新的 network namespace 创建后，可以使用 ip netns exec 命令进入 namespace，做网络配置或者查询的工作。
ip netns exec命令只能根据 network namespace 的名称进入 namespace
以下命令查询 netns1 的 network namespace 的 IP 地址信息
ip netns exec netns1 ip add |
默认的 network namespace 除了附带一个 lo 网卡外，没有任何其他网络设备，并且此 lo 接口还处于 DOWN 的状态，因此此回环网卡也是不可访问的。
ip netns exec netns1 ping 127.0.0.1 |
在此示例中，如果想启用本地回环地址，首先需要进入 namespace，将本地回环网卡的状态修改为 UP
ip netns exec netns1 ip link set dev lo up |
此时，namespace 中的 lo 网卡可以正常使用，但是因为 namespace 中没有其他网络设备，此 network namespace 无法和其他网络通信，要和其他网络通信，需要用到其他的网络技术，例如 veth pair
要删除 network namespace，可以使用以下命令
ip netns delete netns1 |
上面这条命令并没有实际删除
netns1这个network namespace，它只是移除了这个 namespace 对应的挂载点(/var/run/netns/netns1)，只要里面的进程还运行着，network namespace就会一直存在
veth 是虚拟以太网（Virtual Ethernet）的缩写。veth 设备总是成对出现的，因此我们称之为 veth pair，veth pair 的一端发送的数据会在另外一端接收。根据这一特性，veth pair 常被用于跨 network namespace 的通信，即分别将 veth pair 的 2 端放在不同的 network namespace。
从 Linux 文件系统的角度看，tun/tap 设备是用户可以使用文件句柄操作的字符设备
从 Linux 网络虚拟化的角度看，tun/tap 设备是虚拟网卡，一端连接内核网络协议栈，一端连接用户态的程序。
tun/tap 设备主要的作用是可以将 TCP/IP 协议栈处理好的数据包发送给任何一个使用 tun/tap 设备驱动的程序，由用户态程序重新处理数据包后重新发送到 TCP/IP 协议栈。
tun/tap 设备的工作原理完全相同，主要区别在于：
上图展示了物理设备上的数据是如何通过 Linux 内核网络协议栈发送到用户态程序的。
物理网卡的数据送达网络协议栈，进程通过 Socket 创建特殊套接字，从网络协议栈接收数据。
从网络协议栈的角度看，tun/tap 设备这类虚拟网卡与物理网卡并无区别。对 tun/tap 设备而言，他与物理网卡的不同表现在它的数据源不是物理链路，而是来自用户态。
普通的物理网卡通过网线收发数据包，而 tun/tap 设备通过一个设备文件 （/dev/tunX，/dev/tapX）收发数据包，所有对这个文件的写操作会通过 tun/tap 设备转换成一个网络数据包传送给内核的网络协议栈。当内核网络协议栈发送一个包给 tun/tap 设备时，用户态的进程通过读取设备文件，就可以拿到报的内容。用户态的程序也可以通过写入这个设备文件向 tun/tap 设备发送数据。
如上图所示，整个数据包的流程包括
综上所述，发到 192.168.1.0/24 的数据包，首先通过监听在 tun0 设备上的 App2 （VPN 客户端）进行封包，再利用物理网卡 eth0 发送到远端网络的物理网卡上，从而实现 VPN。
VPN 网络报文真正从物理网卡出去需要经过 2 次内核网络协议栈，因此会有一定的性能损耗。