L B T

记 录 过 去 的 经 验

发表于 更新于 上层目录

Pod 是由一个或多个容器构成的集合，被 Kubernetes 作为一个整体进行部署和调度，是 Kubernetes 调度的最小单元。同一个 Pod 内的容器共享 network namespace、UTS nanespace

环境信息

  • Centos7
  • Kubernetes v1.24.7

Pod 创建过程

当用户在 Kubernetes 中创建了一个 Pod 后，CRI 和 CNI 协同创建 Pod 所属容器，并为 Pod 中的容器初始化网络协议栈的具体过程如下

  1. 用户在 Kubernetes 中创建了一个 Pod 后，Kubelet 接收到创建新 Pod 的任务，首先调用 CRI 创建 Pod 内的容器

  2. Pod 中第一个被创建的容器是 pause 容器。pause 容器中运行着一个功能非常简单的 C 程序，具体逻辑是把自己永远阻塞，没有实际的业务逻辑，主要功能是用来占用一个 network namespace。

    创建 pause 容器，使用 docker none 网络模式，创建出来的容器除了 lo 回环网卡外没有其他网络设备。

  3. Pod 内的其他用户容器通过加入 pause 容器已占用的 network namespace 的方式共享同一个 network namespace。对应于 docker 的 Container 模式

    其他用户容器都使用 pause 容器的主机名，但并不使用同一个 UTS namespace。

  4. CNI 负责 Pod 中容器的网络初始化工作。主要为 Pod 内的 pause 容器添加 eth0 网卡、分配 IP、配置网关等。

pause 容器

pause 容器是 Pod 中被创建的第一个容器，Pod 中的其他容器通过使用 pause 容器的 network namespace 共享网络协议栈和主机名。它是 Pod 中其他容器的父容器。

1.8 以后版本默认不启用 PID namespace 共享。每个容器拥有独立的 PID namespace。

以下步骤通过 docker 演示 Pod 容器创建的整个过程。首先，创建 pause 容器

docker run --name=test-pause \
	--hostname=test-pause \
	--network=none \
	--workdir=/ \
	--log-opt max-size=100m \
	--runtime=runc \
	--detach=true \
	k8s.gcr.io/pause:3.4.1

然后在 Pod 中运行其他容器，本示例启动 2 个应用容器，一个 nginx 容器，里面启动了 nginx 服务，一个自定义的容器，里面包含常用工具

$ docker run --name=pod_nginx_test \
             --network=container:0eec8dd9d164 \
             --restart=no --log-opt max-size=100m \
             --runtime=runc --detach=true \
             nginx
             
$ docker run --name=pod_centos_test \
             --network=container:0eec8dd9d164 \
             --restart=no --log-opt max-size=100m \
             --runtime=runc --detach=true \
             centos7:my ping 127.1             
             
$ docker ps -a
CONTAINER ID   IMAGE                    COMMAND                  CREATED          STATUS          PORTS     NAMES
54d57add44d2   centos7:my               "ping 127.1"             3 seconds ago    Up 2 seconds              pod_centos_test
cd0c661774e2   nginx                    "/docker-entrypoint.…"   2 minutes ago    Up 2 minutes              pod_nginx_test
0eec8dd9d164   k8s.gcr.io/pause:3.4.1   "/pause"                 10 minutes ago   Up 10 minutes             test-pause

进入 pod_centos_test 容器，查看网络、端口、主机名信息

$ hostname
test-pause

$ s -elf
F S UID         PID   PPID  C PRI  NI ADDR SZ WCHAN  STIME TTY          TIME CMD
4 S root          1      0  0  80   0 -  6218 skb_wa 17:01 ?        00:00:00 ping 127.1
4 S root          7      0  0  80   0 -  2959 do_wai 17:02 pts/0    00:00:00 bash
0 R root         30      7  0  80   0 - 12935 -      17:08 pts/0    00:00:00 ps -elf

$ netstat -anutp
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      -                   
tcp6       0      0 :::80                   :::*                    LISTEN      - 

$ ip add
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
       
$ curl  localhost:80
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>
  • Pod 中的容器主机名相同，都使用 pause 容器的主机名，但实际并未共享 UTS namespace。

    可以通过找到对应 docker 容器的进程 PID，找到对应进程的 namespace 信息对比确认

    $ ps -elf | grep ping
    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 中的容器同理。

  • Pod 中容器的 PID namespace 进行了隔离，各个容器的 PID 进行了隔离，PID namespace 不同。
  • Pod 中的容器共享了 network namespace，具有相同的网络信息（网卡、IP、端口资源）
  • Pod 中的容器直接可以通过 localhost 互相访问
阅读全文 »

发表于 更新于 上层目录

环境信息

  • Centos 7
  • Kubernetes 1.24

ServiceAccount

ServiceAccount 就像 Pod、Secret、ConfigMap 等一样，都是资源，属于 namespace 级别，作用在单独的命名空间。默认情况，每个 namespace 都有一个默认的 ServiceAccount。

$ kubectl get serviceaccount
NAME      SECRETS   AGE
default   0         160d

$ kubectl describe serviceaccount default
Name:                default
Namespace:           default
Labels:              <none>
Annotations:         <none>
Image pull secrets:  <none>
Mountable secrets:   <none>
Tokens:              <none>
Events:              <none>

namespace 中的每个 Pod 都和一个 ServiceAccount 关联，它代表了运行在 Pod 中的应用程序的身份证明。Pod 中的每个容器都会挂载此 ServiceAccount token

在 Pod 的 manifest 定义文件中，可以通过指定账户名称的方式将一个 ServiceAccount 关联到 Pod。如果不显示指定 ServiceAccount 的账户名称，Pod 会使用 namespace 中默认的 ServiceAccount。可以将不同的 ServiceAccount 关联给不同的 Pod 来控制每个 Pod 可以访问的资源。

当 API 服务接收到一个带有认证 token 的请求时， API 会用这个 token 来验证发送请求的客户端所关联的 ServiceAccount 是否允许执行请求的操作。

查看 ServiceAccount

以 rancher 相关的 ServiceAccount 为例，查看 ServiceAccount 信息

$ kubectl get serviceaccount -n cattle-system
NAME                      SECRETS   AGE
default                   0         160d
git-webhook-api-service   0         160d
rancher                   0         160d
rancher-webhook           0         160d

$ kubectl describe sa default -n cattle-system
Name:                default
Namespace:           cattle-system
Labels:              <none>
Annotations:         <none>
Image pull secrets:  <none>
Mountable secrets:   <none>
Tokens:              <none>
Events:              <none>


以下输出名为 rancher 的 ServiceAccount 信息

$ kubectl describe sa rancher -n cattle-system
Name:                rancher
Namespace:           cattle-system
Labels:              app=rancher
                     app.kubernetes.io/managed-by=Helm
                     chart=rancher-2.7.0
                     heritage=Helm
                     release=rancher
Annotations:         meta.helm.sh/release-name: rancher
                     meta.helm.sh/release-namespace: cattle-system
Image pull secrets:  <none>
Mountable secrets:   <none>
Tokens:              rancher-token
Events:              <none>

ServiceAccount 主要包含了密钥（token）信息，客户端 (Pod)请求 API Service 时使用的 token 文件（如 /var/run/secrets/kubernetes.io/serviceaccount/token）持有 ServiceAccount 的 token 。

$ kubectl describe secret rancher-token -n cattle-system
Name:         rancher-token
Namespace:    cattle-system
Labels:       <none>
Annotations:  field.cattle.io/projectId: local:p-76mvn
              kubernetes.io/service-account.name: rancher
              kubernetes.io/service-account.uid: 1e80ce10-2ba3-4bc3-81d9-ccc72001431b

Type:  kubernetes.io/service-account-token

Data
====
ca.crt:     1099 bytes
namespace:  13 bytes
token:      eyJhbGciOiJSUzI1NiIsImtpZCI6Ik51eFpuNU9MUlp2Qkxm

通过 ServiceAccount 配置镜像拉取密钥

在新建了 ServiceAccount 之后，若要将它赋值给 Pod，通过在 Pod 定义中的 spec.serviceAccountName 字段上配置 ServiceAccount 名称来分配。Pod 的 ServiceAccount 必须在 Pod 创建时进行配置，后续不能被修改

RBAC

从 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

阅读全文 »

发表于 更新于 上层目录 ，

Godaddy API 参考文档

根据参考文档说明，获取到 key 和 secret

Python3 sdk 可以使用 godaddypy

环境信息

  • Python 3.11.2
  • godaddypy

godaddypy 主要提供了 2 个类，分别为

  • account - 使用 key 和 secret 为 client 生成鉴权头部
  • client - 连接 Godaddy API 并执行相应的请求

具体使用方法可以查看帮助信息，或者查看 Godaddy API 参考文档

>>> help(godaddypy)

godaddypy 常见用法示例

获取账号中的所有域名

>>> import godaddypy

>>> ak = 'AAAAAAAAAAAAAA'
>>> sk = 'BBBBBBBBBBBBBBB'

>>> account = godaddypy.Account(ak, sk)
>>> client = godaddypy.Client(account)

根据 Godaddy API 文档说明，获取域名，每次默认获取 500 个，最多可以一次性获取 1000 个。

# 获取域名，默认 100 个。如果账户内的域名数量少于 100，则一次性可以获取完毕，多于 100，获取前 100 个
>>> client.get_domains()

# 获取前 1000 个，最多一次性获取 1000 个。如果账户内的域名数量少于 1000，则一次性可以获取完毕，多于 1000，获取前 1000 个
>>> client.get_domains(limit=1000)

# 超过 1000 会报错
>>> client.get_domains(limit=1001)
Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/godaddypy/client.py", line 105, in _validate_response_success
    response.raise_for_status()
  File "/usr/local/lib/python3.11/site-packages/requests/models.py", line 1021, in raise_for_status
    raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 422 Client Error: Unprocessable Entity for url: https://api.godaddy.com/v1/domains?limit=1001

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.11/site-packages/godaddypy/client.py", line 149, in get_domains
    data = self._get_json_from_response(url, params=params)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/godaddypy/client.py", line 75, in _get_json_from_response
    return self._request_submit(requests.get, url=url, json=json, **kwargs).json()
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/godaddypy/client.py", line 97, in _request_submit
    self._validate_response_success(resp)
  File "/usr/local/lib/python3.11/site-packages/godaddypy/client.py", line 107, in _validate_response_success
    raise BadResponse(response.json())
godaddypy.client.BadResponse: Response Data: {'code': 'VALUE_OVER', 'message': 'Limit must have a value no greater than 1000'}

阅读全文 »

发表于 更新于 上层目录

常用 Volume 类型

以下是几种可用卷类型：

  • emptyDir - 用于存储临时数据的简单空目录，生命周期和 Pod 一致。
  • hostPath - 用于将宿主机中的文件系统挂载到 Pod 中，生命周期不与 Pod 绑定。
  • gitRepo - 通过拉取 Git 仓库的内容来初始化的卷。已弃用
  • nfs - 挂载到 Pod 中的 NFS 共享文件系统。
  • configMap、secret - 用于将 Kubernetes 中的部分资源和集群信息公开给 Pod 的特殊类型的卷
  • persistentVolumeClaim - 简称 PVC，使用预置和动态配置的持久卷。
  • downwardAPI - 在不使用 Kubernetes 客户端或 API 服务器的情况下获得自己或集群的信息 [5]

emptyDir 卷

emptyDir 表示与 Pod 生命周期相同的临时目录。[4]

emptyDir 配置示例

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: registry.k8s.io/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /cache
      name: cache-volume
  volumes:
  - name: cache-volume
    emptyDir:
      sizeLimit: 500Mi
      medium: Memory
  • emptyDir.medium - 表示此目录应使用哪种类别的存储介质，默认为 ""，表示使用节点的默认介质（一般是节点的本地磁盘）。可选值必须为 "" 或者 Memory， Memory 表示使用 tmfs (存在内存而非硬盘)

PersistentVolume 和 PersistentVolumeClaim

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 可以设置三种回收策略：

  • 保留（Retain） - 保留产生的数据，PV 不进行处理
  • 回收（Recycle） - 将执行清除操作，之后可以被新的pvc使用，需要插件支持。NFS 支持全部 3 种。
  • 删除（Delete） - 删除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。

Service 配置语法参考

环境信息

  • Centos 7 3.10.0-1160
  • Kubernetes v1.24.7

kube-proxy iptables 模式下的规则解析

kube-proxy 默认使用 iptables 模式实现 Service 的代理转发和负载均衡。检查 kube-proxy 使用的代理模式

本示例使用相关信息如下

$ kubectl get services 
NAME             TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)     AGE
api-service      ClusterIP   10.106.126.96    <none>        10302/TCP   145d

$ kubectl get endpoints api-service
NAME          ENDPOINTS                               AGE
api-service   10.244.3.138:10302,10.244.4.120:10302   145d


针对 api-service，后端的 Pod 就绪后，生成了 ENDPOINTS，kube-proxy 会为该服务创建以下 iptables 规则

-A PREROUTING -m comment --comment "kubernetes service portals" -j KUBE-SERVICES

-A KUBE-SERVICES -d 10.106.126.96/32 -p tcp -m comment --comment "default/api-service:api-pord cluster IP" -m tcp --dport 10302 -j KUBE-SVC-DVTQLPR6DVOLBZS4

-A KUBE-SVC-DVTQLPR6DVOLBZS4 ! -s 10.244.0.0/16 -d 10.106.126.96/32 -p tcp -m comment --comment "default/api-service:api-pord cluster IP" -m tcp --dport 10302 -j KUBE-MARK-MASQ
-A KUBE-SVC-DVTQLPR6DVOLBZS4 -m comment --comment "default/api-service:api-pord -> 10.244.3.138:10302" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-JXBL7O23XHVFQV2I
-A KUBE-SVC-DVTQLPR6DVOLBZS4 -m comment --comment "default/api-service:api-pord -> 10.244.4.120:10302" -j KUBE-SEP-BBPDSOPRICLINLPY

-A KUBE-SEP-JXBL7O23XHVFQV2I -s 10.244.3.138/32 -m comment --comment "default/api-service:api-pord" -j KUBE-MARK-MASQ
-A KUBE-SEP-JXBL7O23XHVFQV2I -p tcp -m comment --comment "default/api-service:api-pord" -m tcp -j DNAT --to-destination 10.244.3.138:10302

-A KUBE-SEP-BBPDSOPRICLINLPY -s 10.244.4.120/32 -m comment --comment "default/api-service:api-pord" -j KUBE-MARK-MASQ
-A KUBE-SEP-BBPDSOPRICLINLPY -p tcp -m comment --comment "default/api-service:api-pord" -m tcp -j DNAT --to-destination 10.244.4.120:10302

-A POSTROUTING -m comment --comment "flanneld masq" -j FLANNEL-POSTRTG
-A POSTROUTING -m comment --comment "kubernetes postrouting rules" -j KUBE-POSTROUTING-A FLANNEL-POSTRTG -m mark --mark 0x4000/0x4000 -m comment --comment "flanneld masq" -j RETURN
-A FLANNEL-POSTRTG -s 10.244.0.0/16 -d 10.244.0.0/16 -m comment --comment "flanneld masq" -j RETURN
-A FLANNEL-POSTRTG -s 10.244.0.0/16 ! -d 224.0.0.0/4 -m comment --comment "flanneld masq" -j MASQUERADE
-A FLANNEL-POSTRTG ! -s 10.244.0.0/16 -d 10.244.3.0/24 -m comment --comment "flanneld masq" -j RETURN
-A FLANNEL-POSTRTG ! -s 10.244.0.0/16 -d 10.244.0.0/16 -m comment --comment "flanneld masq" -j MASQUERADE

-A KUBE-POSTROUTING -m mark ! --mark 0x4000/0x4000 -j RETURN
-A KUBE-POSTROUTING -j MARK --set-xmark 0x4000/0x0
-A KUBE-POSTROUTING -m comment --comment "kubernetes service traffic requiring SNAT" -j MASQUERADE

具体工作流程如下：

  1. 所有进入 PREROUTING 链的流量会被跳转到 KUBE-SERVICES 自定义链
  2. 本示例中请求 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-DVTQLPR6DVOLBZS4
  3. 在自定义链 KUBE-SVC-DVTQLPR6DVOLBZS4 中，实现了负载均衡，一半的流量会被跳转到链 KUBE-SEP-JXBL7O23XHVFQV2I，另一半的流量会被跳转到 KUBE-SEP-BBPDSOPRICLINLPY
  4. 在自定义链 KUBE-SEP-JXBL7O23XHVFQV2I 和 KUBE-SEP-BBPDSOPRICLINLPY 中，流量分别被 DNAT 分配到了后端的 Pod（就绪的 Endpoints）。
  5. Pod 处理完数据请求，向客户端返回请求结果时，在 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，从而将流量转发到相应的 Pod

kube-proxy 的 iptables 模式因为使用 DNAT 转发数据包，存在一定的性能损耗，另外，当集群中的 Service 数量上万时，节点上的 iptables rules 会非常庞大，对管理是个不小的负担，性能也会大打折扣。

发表于 上层目录

环境信息

  • Centos 7 5.4.225-1
  • Kubernetes v1.24.7

Kubernetes DNS 服务的功能，是用来解析 Kubernetes 集群内的 Pod 和 Service 的域名，一般只供集群内部使用，不给外部使用。

默认情况下，Kubernetes DNS 应用部署后，会对外暴露一个 Service，集群内的容器通过访问该 Service 获得域名解析服务，这个 Service 的 ClusterIP 一般情况下都是固定的。

$ kubectl get services -n kube-system -o wide
NAME       TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)                  AGE    SELECTOR
kube-dns   ClusterIP   10.96.0.10   <none>        53/UDP,53/TCP,9153/TCP   147d   k8s-app=kube-dns

当 Kubernetes DNS 服务获得 ClusterIP 后，系统会给 Kubelet 配置启动参数指定 DNS Service 的 ClusterIP，DNS Service 的 IP 会在容器启动时传入，并写入容器系统的 DNS 配置中（一般为 /etc/resolv.conf 文件）

根据 kubelet 服务的启动命令，配置参数可以写在以下相关配置文件中

$ systemctl status kubelet -l
● kubelet.service - kubelet: The Kubernetes Node Agent
   Loaded: loaded (/usr/lib/systemd/system/kubelet.service; enabled; vendor preset: disabled)
  Drop-In: /usr/lib/systemd/system/kubelet.service.d
           └─10-kubeadm.conf
   Active: active (running) since Tue 2023-05-02 16:06:16 CST; 21h ago
     Docs: https://kubernetes.io/docs/
 Main PID: 1413 (kubelet)
    Tasks: 29
   Memory: 203.0M
   CGroup: /system.slice/kubelet.service
           └─1413 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf \
                                   --kubeconfig=/etc/kubernetes/kubelet.conf \
                                   --config=/var/lib/kubelet/config.yaml \
                                   --container-runtime=remote \
                                   --container-runtime-endpoint=unix:///var/run/cri-dockerd.sock \
                                   --pod-infra-container-image=k8s.gcr.io/pause:3.7

$ ps aux | grep kubelet
/usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf 、
                 --kubeconfig=/etc/kubernetes/kubelet.conf \
                 --config=/var/lib/kubelet/config.yaml \
                 --container-runtime=remote \
                 --container-runtime-endpoint=unix:///var/run/cri-dockerd.sock \
                 --pod-infra-container-image=k8s.gcr.io/pause:3.7

DNS 的相关配置在文件 /var/lib/kubelet/config.yaml 中，主要选项为 clusterDNS

/var/lib/kubelet/config.yaml
apiVersion: kubelet.config.k8s.io/v1beta1
authentication:
  anonymous:
    enabled: false
  webhook:
    cacheTTL: 0s
    enabled: true
  x509:
    clientCAFile: /etc/kubernetes/pki/ca.crt
authorization:
  mode: Webhook
  webhook:
    cacheAuthorizedTTL: 0s
    cacheUnauthorizedTTL: 0s
cgroupDriver: systemd
clusterDNS:
- 10.96.0.10
clusterDomain: cluster.local
cpuManagerReconcilePeriod: 0s
evictionPressureTransitionPeriod: 0s
fileCheckFrequency: 0s
healthzBindAddress: 127.0.0.1
healthzPort: 10248
httpCheckFrequency: 0s
imageMinimumGCAge: 0s
kind: KubeletConfiguration
logging:
  flushFrequency: 0
  options:
    json:
      infoBufferSize: "0"
  verbosity: 0
memorySwap: {}
nodeStatusReportFrequency: 0s
nodeStatusUpdateFrequency: 0s
rotateCertificates: true
runtimeRequestTimeout: 0s
shutdownGracePeriod: 0s
shutdownGracePeriodCriticalPods: 0s
staticPodPath: /etc/kubernetes/manifests
streamingConnectionIdleTimeout: 0s
syncFrequency: 0s
volumeStatsAggPeriod: 0s
阅读全文 »

发表于 更新于 上层目录

环境信息

  • Centos 7

VNC 是一个图形桌面共享系统，可以通过远程连接的方式连接到服务器的图形系统以控制操作系统
VNC 包括以下四个部分 ： vncserver，vncviewer，vncpassword 及 vncconnect。
VNC client 端通过 VNC 协议远程连接到 vnc server 端，进行桌面共享及交互；

安装 tigervnc

安装之前首先要确保系统已安装图形系统，本文以 GNOME Desktop 为图形桌面系统，执行以下命令检查是否已安装 GNOME Desktop，如果未安装，使用命令 yum groupinstall "GNOME Desktop" 安装

$ yum grouplist
Loaded plugins: fastestmirror, langpacks
Loading mirror speeds from cached hostfile
Installed Environment Groups:
   GNOME Desktop
Available Environment Groups:
   Minimal Install
   Compute Node
...

桌面系统安装后，使用以下命令，安装 tigervnc

yum install -y tigervnc-server

可以参考 /lib/systemd/system/vncserver@.service 中的指示，生成服务配置文件：

cp /lib/systemd/system/vncserver@.service /etc/systemd/system/vncserver@:1.service
vim /etc/systemd/system/vncserver@\:1.service

修改以下行，将其中的 <USER> 改为要远程登录的用户名，例如 root

/etc/systemd/system/vncserver@\:1.service
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
[USER@localhost ~]$ vncpasswd

设置 vncpasswd 密码后，在账号的家目录里就会自动建立 .vnc 文件，其中包括对应用户的 vnc 相关的日志

配置完成后，下载客户端 进行远程登录

常见错误

getpassword error: Inappropriate ioctl for device

vncserver@:1.service 服务启动失败，端口未监听

$ netstat -anutp | grep LIST
tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN      735/rpcbind         
tcp6       0      0 :::30000                :::*                    LISTEN      1251/sshd           
tcp6       0      0 :::80                   :::*                    LISTEN      17064/nginx: master 
tcp6       0      0 :::8181                 :::*                    LISTEN      17064/nginx: master 
tcp6       0      0 :::8443                 :::*                    LISTEN      14032/nginx-ingress 
tcp6       0      0 :::443                  :::*                    LISTEN      17064/nginx: master 
tcp6       0      0 :::10254                :::*                    LISTEN      14032/nginx-ingress 
tcp6       0      0 :::111                  :::*                    LISTEN      735/rpcbind

$ systemctl status vncserver@:1.service
● vncserver@:1.service - Remote desktop service (VNC)
   Loaded: loaded (/etc/systemd/system/vncserver@:1.service; disabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Tue 2023-05-02 13:29:44 CST; 14s ago
  Process: 28040 ExecStart=/usr/bin/vncserver_wrapper root %i (code=exited, status=2)
  Process: 28037 ExecStartPre=/bin/sh -c /usr/bin/vncserver -kill %i > /dev/null 2>&1 || : (code=exited, status=0/SUCCESS)
 Main PID: 28040 (code=exited, status=2)

May 02 13:29:44 test systemd[1]: Starting Remote desktop service (VNC)...
May 02 13:29:44 test systemd[1]: Started Remote desktop service (VNC).
May 02 13:29:44 test vncserver_wrapper[28040]: You will require a password to access your desktops.
May 02 13:29:44 test vncserver_wrapper[28040]: getpassword error: Inappropriate ioctl for device
May 02 13:29:44 test vncserver_wrapper[28040]: Password:FATAL: 'runuser -l root' failed!
May 02 13:29:44 test systemd[1]: vncserver@:1.service: main process exited, code=exited, status=2/INVALIDARGUMENT
May 02 13:29:44 test systemd[1]: Unit vncserver@:1.service entered failed state.
May 02 13:29:44 test systemd[1]: vncserver@:1.service failed.

解决方法 配置登陆用的 VNC 密码，重启服务

su - root
vncpasswd

systemctl start vncserver@:1.service

发表于 更新于 上层目录

环境信息

  • Vmware workstation 17

其他下载地址

激活密钥： NZ4RR-FTK5H-H81C1-Q30QH-1V2LA

Centos7 server 中安装使用 Vmware workstation

Centos 7 server版本（无图形界面）安装使用 Vmware workstation 参考链接

常见错误

VMware Workstation and Hyper-V are not compatible. Remove the Hyper-V role from the system before running VMware Workstation.

aws workspace 中不兼容 Vmware workstation

Failed to start SYSV: This service starts and stops VMware services.

参考 Centos7 server 中安装使用 Vmware workstation ，安装后，vmware 无法启动

$ /etc/rc.d/init.d/vmware start
Starting vmware (via systemctl):  Job for vmware.service failed because the control process exited with error code. See "systemctl status vmware.service" and "journalctl -xe" for details.
                                                           [FAILED]

$ journalctl -xe -u vmware
-- 
-- Unit vmware.service has failed.
-- 
-- The result is failed.
May 02 11:13:39 k8s-uat-xhy-mysql-new systemd[1]: Unit vmware.service entered failed state.
May 02 11:13:39 k8s-uat-xhy-mysql-new systemd[1]: vmware.service failed.
May 02 11:19:37 k8s-uat-xhy-mysql-new systemd[1]: Starting SYSV: This service starts and stops VMware services...
-- Subject: Unit vmware.service has begun start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit vmware.service has begun starting up.
May 02 11:19:37 k8s-uat-xhy-mysql-new vmware[22226]: Starting VMware services:
May 02 11:19:37 k8s-uat-xhy-mysql-new vmware[22226]: Virtual machine monitor[FAILED]
May 02 11:19:37 k8s-uat-xhy-mysql-new vmware[22226]: Virtual machine communication interface[  OK  ]
May 02 11:19:37 k8s-uat-xhy-mysql-new vmware[22226]: VM communication interface socket family[  OK  ]
May 02 11:19:37 k8s-uat-xhy-mysql-new vmware[22226]: Virtual ethernet[FAILED]
May 02 11:19:37 k8s-uat-xhy-mysql-new vmware[22226]: VMware Authentication Daemon[  OK  ]
May 02 11:19:37 k8s-uat-xhy-mysql-new systemd[1]: vmware.service: control process exited, code=exited status=1
May 02 11:19:37 k8s-uat-xhy-mysql-new systemd[1]: Failed to start SYSV: This service starts and stops VMware services.
-- Subject: Unit vmware.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit vmware.service has failed.
-- 
-- The result is failed.
May 02 11:19:37 k8s-uat-xhy-mysql-new systemd[1]: Unit vmware.service entered failed state.
May 02 11:19:37 k8s-uat-xhy-mysql-new systemd[1]: vmware.service failed.


执行以下命令 [1]

$ vmware-modconfig --console --install-status
[AppLoader] GLib does not have GSettings support.
vmmon: unknown
vmnet: unknown

查看内核版本

$ uname -r
3.10.0-1062.9.1.el7.x86_64

脚注

发表于 上层目录

环境信息

  • Centos7 3.10.0-1160.45.1.el7
  • RabbitMQ 3.9.10

常见错误

RabbitMQ 启动失败

使用命令启动，报错

$ /sbin/rabbitmq-server -v
2023-04-26 10:02:47.621248+08:00 [noti] <0.146.0> Protocol 'inet_tcp': register/listen error: ehostunreach
2023-04-26 10:02:47.621248+08:00 [noti] <0.146.0> 
2023-04-26 10:02:47.626643+08:00 [erro] <0.143.0>     supervisor: {local,net_sup}
2023-04-26 10:02:47.626643+08:00 [erro] <0.143.0>     errorContext: start_error
2023-04-26 10:02:47.626643+08:00 [erro] <0.143.0>     reason: {'EXIT',nodistribution}
2023-04-26 10:02:47.626643+08:00 [erro] <0.143.0>     offender: [{pid,undefined},
2023-04-26 10:02:47.626643+08:00 [erro] <0.143.0>                {id,net_kernel},
2023-04-26 10:02:47.626643+08:00 [erro] <0.143.0>                {mfargs,{net_kernel,start_link,
2023-04-26 10:02:47.626643+08:00 [erro] <0.143.0>                                    [[rabbit_prelaunch_21812@localhost,
2023-04-26 10:02:47.626643+08:00 [erro] <0.143.0>                                      shortnames],
2023-04-26 10:02:47.626643+08:00 [erro] <0.143.0>                                     false,net_sup_dynamic]}},
2023-04-26 10:02:47.626643+08:00 [erro] <0.143.0>                {restart_type,permanent},
2023-04-26 10:02:47.626643+08:00 [erro] <0.143.0>                {shutdown,2000},
2023-04-26 10:02:47.626643+08:00 [erro] <0.143.0>                {child_type,worker}]

关键错误信息 Protocol 'inet_tcp': register/listen error: ehostunreach，根据提示，可能是某个地址不可达，rabbitmq 启动时需要连接 epmd ，默认端口为 4369，在本地测试连接此端口，发现不通 [1]

$ curl -v 127.0.0.1:4369
* About to connect() to 127.0.0.1 port 4369 (#0)
*   Trying 127.0.0.1...
* No route to host
* Failed connect to 127.0.0.1:4369; No route to host
* Closing connection 0
curl: (7) Failed connect to 127.0.0.1:4369; No route to host

根据输出的错误可知，是因为 127.0.0.1 无法连接，检查 iptables 防火墙策略，发现未允许回环网卡访问，在 iptables 中添加以下规则允许回环网卡访问

/etc/sysconfig/iptables
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [9020367577:7010759848370]
-A INPUT -i lo -j ACCEPT

允许回环网卡访问后，重新测试连接 epmd ，可以正常连接，重新启动 rabbitmq-server 正常。

$ curl -v 127.0.0.1:4369
* About to connect() to 127.0.0.1 port 4369 (#0)
*   Trying 127.0.0.1...
* Connected to 127.0.0.1 (127.0.0.1) port 4369 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: 127.0.0.1:4369
> Accept: */*
> 
* Empty reply from server
* Connection #0 to host 127.0.0.1 left intact
curl: (52) Empty reply from server

脚注

发表于 上层目录 ，

Macvlan

Macvlan 本身是 linxu kernel 模块

Macvlan 接口是物理以太网接口的虚拟子接口，Macvlan 允许用户在一个物理网络接口上面配置多个虚拟的网络接口，每个 Macvlan 接口都有自己的区别与父接口的 MAC 地址，并且可以像普通的物理网络接口一样分配 IP 地址。使用 Macvlan 技术实现的效果是一块物理网卡可以绑定多个 IP 地址，并且每个 IP 地址有自己独立的 MAC 地址。

Macvlan 虚拟出来的虚拟网卡，在逻辑上和物理网卡是对等的。使用 Macvlan 的虚拟网卡要和父接口在同一个网段。

Macvlan 的最大优点是性能极好，相比其他方式，macvlan 不需要创建 Linux bridge，而是直接通过interface 连接到物理网络。

为保证父接口能接收多个不同 MAC 地址的网络包，需要开启网卡的 混杂模式

docker 中使用 Macvlan 虚拟网卡

本示例演示 docker 环境中使用 macvlan。首先创建使用 macvlan 驱动的 network，Docker 中 macvlan 只支持 bridge 模式 [1]

$ docker network create -d macvlan --subnet=192.168.142.0/24 \
                                   --gateway=192.168.142.2 \
                                   -o parent=ens33 \
                                   macvlan1

$ docker network ls
NETWORK ID     NAME       DRIVER    SCOPE
69324d203c35   bridge     bridge    local
f8943f720d73   host       host      local
0aa95ac8c0f4   macvlan1   macvlan   local
d400c40efdc5   none       null      local

在 docker 环境中，创建网络时，会自动将宿主机网卡设置为混杂模式，此时查看网卡信息，未显示混杂模式，但是查看 dmesg 日志，会看到网卡进入了混杂模式

$ dmesg
[93203.228311] device ens33 entered promiscuous mode

运行容器并连接到新建的 macvlan 网络 macvlan1

docker run -itd --name test01 \
                --ip=192.168.142.12 \
                --network macvlan1 centos:centos7.9.2009

使用命令 docker exec -it test01 bash 进入容器查看容器的 IP 地址信息，可以看到容器中的网卡类型为 macvlan，模式为 bridge，网关为 docker 网络 macvlan1 中配置的网关。

$ ip -d add
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 promiscuity 0 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
4: eth0@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether 02:42:c0:a8:8e:0c brd ff:ff:ff:ff:ff:ff link-netnsid 0 promiscuity 0 
    macvlan mode bridge numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 
    inet 192.168.142.12/24 brd 192.168.142.255 scope global eth0
       valid_lft forever preferred_lft forever
       
$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.142.2   0.0.0.0         UG    0      0        0 eth0
192.168.142.0   0.0.0.0         255.255.255.0   U     0      0        0 eth0

测试容器可以和宿主机网络一样访问外网。

此时检查宿主机网卡信息，系统上只有 lo，ens33，docker0，未出现其他网卡。

$ ip -d link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 promiscuity 0 addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether 00:0c:29:90:51:eb brd ff:ff:ff:ff:ff:ff promiscuity 1 addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default 
    link/ether 02:42:e9:a6:76:56 brd ff:ff:ff:ff:ff:ff promiscuity 0 
    bridge forward_delay 1500 hello_time 200 max_age 2000 ageing_time 30000 stp_state 0 priority 32768 vlan_filtering 0 vlan_protocol 802.1Q bridge_id 8000.2:42:e9:a6:76:56 designated_root 8000.2:42:e9:a6:76:56 root_port 0 root_path_cost 0 topology_change 0 topology_change_detected 0 hello_timer    0.00 tcn_timer    0.00 topology_change_timer    0.00 gc_timer  265.03 vlan_default_pvid 1 vlan_stats_enabled 0 group_fwd_mask 0 group_address 01:80:c2:00:00:00 mcast_snooping 1 mcast_router 1 mcast_query_use_ifaddr 0 mcast_querier 0 mcast_hash_elasticity 16 mcast_hash_max 4096 mcast_last_member_count 2 mcast_startup_query_count 2 mcast_last_member_interval 100 mcast_membership_interval 26000 mcast_querier_interval 25500 mcast_query_interval 12500 mcast_query_response_interval 1000 mcast_startup_query_interval 3125 mcast_stats_enabled 0 mcast_igmp_version 2 mcast_mld_version 1 nf_call_iptables 0 nf_call_ip6tables 0 nf_call_arptables 0 addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535

在另一个 docker 节点上同样配置 docker 网络和容器

$ docker network create -d macvlan --subnet=192.168.142.0/24 \
                                   --gateway=192.168.142.2 \
                                   -o parent=ens33 \
                                   macvlan1

$ docker run -itd --name test01 \
                --ip=192.168.142.13 \
                --network macvlan1 centos:centos7.9.2009

进入容器 test01 ，访问到另一个节点上的容器的连通性

$ ping 192.168.142.12
PING 192.168.142.12 (192.168.142.12) 56(84) bytes of data.
64 bytes from 192.168.142.12: icmp_seq=1 ttl=64 time=0.871 ms
64 bytes from 192.168.142.12: icmp_seq=2 ttl=64 time=0.403 ms
64 bytes from 192.168.142.12: icmp_seq=3 ttl=64 time=0.568 ms
^C
--- 192.168.142.12 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2047ms
rtt min/avg/max/mdev = 0.403/0.614/0.871/0.193 ms

进入容器 test01 ，测试和宿主机 ip 的连通性，结果发现不通，原因为：在 macvlan 虚拟网络中，父接口（物理网卡）相当于一个交换机，对于其子 macvlan 网卡的数据包，只进行转发而不处理，于是造成了使用本机 macvlan 网卡的虚拟 IP 无法和本机物理网卡的 IP 通信。 

$ ping 192.168.142.10
PING 192.168.142.10 (192.168.142.10) 56(84) bytes of data.
From 192.168.142.13 icmp_seq=1 Destination Host Unreachable
From 192.168.142.13 icmp_seq=2 Destination Host Unreachable
From 192.168.142.13 icmp_seq=3 Destination Host Unreachable
^C
--- 192.168.142.10 ping statistics ---
5 packets transmitted, 0 received, +3 errors, 100% packet loss, time 4073ms
pipe 4
阅读全文 »

发表于 更新于 上层目录 ，

环境信息

  • Centos 7 5.4.239-1

Linux 的 namespace 的作用是 隔离内核资源，目前主要实现了以下 namespace

  • mount namespace - 文件系统挂载点
  • UTS namespace - 主机名
  • IPC namespace - POSIX 进程间通信消息队列
  • PID namespace - 进程 pid 数字空间
  • network namespace - network
  • user namespace - user ID 数字空间

其中，除了 network namespace，其他 namespace 的操作需要使用 C 语言调用系统 API 实现。network namespace 的增删改查功能已经集成到了 Linux 的 ip 工具集的 netns 子命令中

Linux 里面的 namespace 给处在其中的进程造成 2 个错觉：

  1. 它是系统里面唯一的进程
  2. 它独享系统的所有资源

默认情况下，Linux 里面的所有进程处在和宿主机相同的 namespace ，即初始 namespace 里，默认享有全局系统资源。

network namespace 常用操作

network namespace 的增删改查功能已经集成到了 Linux 的 ip 工具集的 netns 子命令中，因此在 Linux 系统中，对 network namespace 的操作主要使用 ip netns 命令

$ ip netns help
Usage: ip netns list
       ip netns add NAME
       ip netns set NAME NETNSID
       ip [-all] netns delete [NAME]
       ip netns identify [PID]
       ip netns pids NAME
       ip [-all] netns exec [NAME] cmd ...
       ip netns monitor
       ip netns list-id

创建并查看 network namespace

使用以下命令创建名为 netns1 的 network namespace 

ip netns add netns1

以下命令查看系统中的 network namespace

$ ip netns list
netns1

新的 network namespace 创建后，系统会在 /var/run/netns/ 下面生成一个同名的挂载点

$ ls -l /var/run/netns/
total 0
-r--r--r-- 1 root root 0 Apr  3 13:33 netns1

此挂载点的主要作用一方面是方便对 namespace 的管理，一方面是使 namespace 即使没有进程运行也能继续存在。

新的 network namespace 创建后，可以使用 ip netns exec 命令进入 namespace，做网络配置或者查询的工作。

ip netns exec 命令只能根据 network namespace 的名称进入 namespace

以下命令查询 netns1 的 network namespace 的 IP 地址信息

$ ip netns exec netns1 ip add
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

默认的 network namespace 除了附带一个 lo 网卡外，没有任何其他网络设备，并且此 lo 接口还处于 DOWN 的状态，因此此回环网卡也是不可访问的。

$ ip netns exec netns1 ping 127.0.0.1
connect: Network is unreachable

在此示例中，如果想启用本地回环地址，首先需要进入 namespace，将本地回环网卡的状态修改为 UP

$ ip netns exec netns1 ip link set dev lo up

$ ip netns exec netns1 ip add
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever

$ ip netns exec netns1 ping 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.021 ms
^C
--- 127.0.0.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.021/0.021/0.021/0.000 ms

此时，namespace 中的 lo 网卡可以正常使用，但是因为 namespace 中没有其他网络设备，此 network namespace 无法和其他网络通信，要和其他网络通信，需要用到其他的网络技术，例如 veth pair

删除 network namespace

要删除 network namespace，可以使用以下命令

ip netns delete netns1

上面这条命令并没有实际删除 netns1 这个 network namespace，它只是移除了这个 namespace 对应的挂载点(/var/run/netns/netns1)，只要里面的进程还运行着，network namespace 就会一直存在

veth pair

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 设备的工作原理完全相同，主要区别在于：

  • tun 设备的 /dev/tunX 文件收发的是 IP 包，因此只能工作在网络层（L3），无法与物理网卡做桥接，可以通过三层交换(如 ip_forward) 与物理网卡交互
  • tap 设备的 /dev/tapX 文件收发的是数据链路层报文，可以与物理网卡做桥接。

tun/tap 设备的工作原理

上图展示了物理设备上的数据是如何通过 Linux 内核网络协议栈发送到用户态程序的。

物理网卡的数据送达网络协议栈，进程通过 Socket 创建特殊套接字，从网络协议栈接收数据。

从网络协议栈的角度看，tun/tap 设备这类虚拟网卡与物理网卡并无区别。对 tun/tap 设备而言，他与物理网卡的不同表现在它的数据源不是物理链路，而是来自用户态。

普通的物理网卡通过网线收发数据包，而 tun/tap 设备通过一个设备文件 （/dev/tunX，/dev/tapX）收发数据包，所有对这个文件的写操作会通过 tun/tap 设备转换成一个网络数据包传送给内核的网络协议栈。当内核网络协议栈发送一个包给 tun/tap 设备时，用户态的进程通过读取设备文件，就可以拿到报的内容。用户态的程序也可以通过写入这个设备文件向 tun/tap 设备发送数据。

VPN 原理简述

如上图所示，整个数据包的流程包括

  1. App1 通过 Socket API 发送了一个数据包，假设这个数据包的目的 IP 地址是 192.168.1.3，和 tun0 位于同一个网段
  2. 数据包到达网络协议栈后，协议栈根据数据包的目的 IP 地址进行路由，匹配到数据包应该发送给 tun0 网卡，于是将数据包发送给 tun0 网卡
  3. tun0 网卡收到数据包，将数据包写入 /dev/tun0，/dev/tun0 由 App2 打开，于是 App2 获得了数据包
  4. App2 获得数据包后，通过报文封装，将原来的目的 IP 为 192.168.1.3 的报文封装在源 IP 为 eth0 的 IP，目的 IP 为 VPN 对端 IP 地址的报文中，构造出新的报文，并通过 Socket API 发送给内核网络协议栈
  5. 内核网络协议栈根据路由，发现数据包应该由 eth0 发送出去，于是将数据包发给 eth0，最终通过 eth0 将数据包发送到 VPN 的对端。

综上所述，发到 192.168.1.0/24 的数据包，首先通过监听在 tun0 设备上的 App2 （VPN 客户端）进行封包，再利用物理网卡 eth0 发送到远端网络的物理网卡上，从而实现 VPN。

VPN 网络报文真正从物理网卡出去需要经过 2 次内核网络协议栈，因此会有一定的性能损耗。

发表于 更新于 上层目录

sysctl 命令被用于在内核运行时动态地修改内核的运行参数，可用的内核参数在目录 /proc/sys 中。

sysctl 命令对内核参数的修改仅在当前生效，重启系统后参数丢失。如果希望参数永久生效可以修改配置文件 /etc/sysctl.conf。

常用内核参数说明

内核参数 取值范围 含义 使用说明
kernel.hung_task_timeout_secs = 120 int 设置系统检测到进程阻塞(如 `D` 状态)后，等待进程结束的时常。
如果进程未在规定时间内结束，系统认为该进程无响应，则自动杀死以避免系统奔溃

mem

内核参数 取值范围 含义 使用说明
vm.min_free_kbytes = 2097152 单位 KB 设置系统最小剩余内存，以避免缓存不释放导致的死机
vm.oom-kill = 0 0,1
默认值为 1，开启		 是否启用 OOM-killer。
特定情况下，可能不希望核心执行 OOM killer 的工作,关闭 OOM killer。 例如，排错时
echo 0 > /proc/sys/vm/oom-kill 临时关闭 [1]
vm.overcommit_memory = 0 0,1,2 内存分配策略
/proc/sys/vm/overcommit_memory		 vm.overcommit_memory 详细说明
vm.overcommit_ratio = 50 int
default = 50		 vm.overcommit_memory = 2 时才生效，配置允许 overcommit 的百分比 vm.overcommit_memory 详细说明
vm.panic_on_oom = 0 0,1
默认为 0 ，开启		 表示当内存耗尽时，内核会触发 OOM killer 杀掉最耗内存的进程
vm.oom_kill_allocating_task = 0 0,1
默认为 0 ，不启用		 OOM-Killer 时，是否选择当前正在申请内存的进程进行 kill
阅读全文 »

发表于 上层目录

环境信息

  • Centos7 5.4.221-1.el7
  • Docker Engine - Community 20.10.9

本文档中的日志分析主要依赖于 journald 服务记录的日志，因此首先需要对 `journald` 服务记录的日志进行持久化配置

场景分析

k8s worker 节点经常死机(奔溃)

环境信息

  • Centos7 5.4.221-1.el7
  • Docker Engine - Community 20.10.9
  • Kubernetes v1.24.7

k8s 节点经常出现无响应(死机)，重启才能恢复正常。重启恢复后，检查系统 messages 日志。

/var/log/messages
Feb 10 12:21:40 k8s-work1 kernel: INFO: task dockerd:1443 blocked for more than 368 seconds.
Feb 10 12:21:40 k8s-work1 kernel:      Tainted: G            E     5.4.221-1.el7.elrepo.x86_64 #1
Feb 10 12:21:40 k8s-work1 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Feb 10 12:21:40 k8s-work1 kernel: dockerd         D    0  1443      1 0x00004080
Feb 10 12:21:40 k8s-work1 kernel: Call Trace:
Feb 10 12:21:40 k8s-work1 kernel: __schedule+0x2d2/0x730
Feb 10 12:21:40 k8s-work1 kernel: schedule+0x42/0xb0
Feb 10 12:21:40 k8s-work1 kernel: wb_wait_for_completion+0x56/0x90
Feb 10 12:21:40 k8s-work1 kernel: ? finish_wait+0x80/0x80
Feb 10 12:21:40 k8s-work1 kernel: sync_inodes_sb+0xd4/0x2c0
Feb 10 12:21:40 k8s-work1 kernel: ? __filemap_fdatawrite_range+0xf1/0x110
Feb 10 12:21:40 k8s-work1 kernel: sync_filesystem+0x5f/0xa0
Feb 10 12:21:40 k8s-work1 kernel: ovl_sync_fs+0x39/0x60 [overlay]
Feb 10 12:21:40 k8s-work1 kernel: sync_filesystem+0x79/0xa0
Feb 10 12:21:40 k8s-work1 kernel: generic_shutdown_super+0x27/0x110
Feb 10 12:21:40 k8s-work1 kernel: kill_anon_super+0x18/0x30
Feb 10 12:21:40 k8s-work1 kernel: deactivate_locked_super+0x3b/0x80
Feb 10 12:21:40 k8s-work1 kernel: deactivate_super+0x3e/0x50
Feb 10 12:21:40 k8s-work1 kernel: cleanup_mnt+0x109/0x160
Feb 10 12:21:40 k8s-work1 kernel: __cleanup_mnt+0x12/0x20
Feb 10 12:21:40 k8s-work1 kernel: task_work_run+0x8f/0xb0
Feb 10 12:21:40 k8s-work1 kernel: exit_to_usermode_loop+0x10c/0x130
Feb 10 12:21:40 k8s-work1 kernel: do_syscall_64+0x170/0x1b0
Feb 10 12:21:40 k8s-work1 kernel: entry_SYSCALL_64_after_hwframe+0x5c/0xc1
Feb 10 12:21:40 k8s-work1 kernel: RIP: 0033:0x55cf9a53e13b
Feb 10 12:21:40 k8s-work1 kernel: Code: Bad RIP value.
Feb 10 12:21:40 k8s-work1 kernel: RSP: 002b:000000c252fea778 EFLAGS: 00000212 ORIG_RAX: 00000000000000a6
Feb 10 12:21:40 k8s-work1 kernel: RAX: 0000000000000000 RBX: 000000c000070800 RCX: 000055cf9a53e13b
Feb 10 12:21:40 k8s-work1 kernel: RDX: 0000000000000000 RSI: 0000000000000002 RDI: 000000c2d000c3f0
Feb 10 12:21:40 k8s-work1 kernel: RBP: 000000c252fea7d0 R08: 0000000000000000 R09: 0000000000000000
Feb 10 12:21:40 k8s-work1 kernel: R10: 0000000000000000 R11: 0000000000000212 R12: 0000000000000000
Feb 10 12:21:40 k8s-work1 kernel: R13: 0000000000000001 R14: 000000000000000a R15: ffffffffffffffff

从日志中可看出，dockerd 进程处于 `D` 状态，说明 dockerd 在等待 IO 操作，根据进程调用的栈信息，显示存在对 overlay 文件系统的同步操作，初步猜测，可能是因为 overlay 文件系统中的某些操作未能及时完成，导致了 dockerd 进程的阻塞。

继续检查日志，看到系统连接 NFS 服务超时，怀疑可能是因为 NFS 异常导致。

/var/log/messages
Feb 10 12:21:40 k8s-work1 kernel: nfs: server 172.31.88.9 not responding, timed out
Feb 10 12:21:40 k8s-work1 kernel: nfs: server 172.31.88.9 not responding, still trying
Feb 10 12:21:40 k8s-work1 kernel: nfs: server 172.31.88.9 not responding, timed out
Feb 10 12:21:40 k8s-work1 kernel: nfs: server 172.31.88.9 not responding, still trying
Feb 10 12:21:40 k8s-work1 kernel: nfs: server 172.31.88.9 not responding, timed out

发表于 上层目录 ，

Linux 网卡的混杂模式（Promiscuous mode），简称 Promisc mode，俗称 监听模式。在非混杂模式下，网卡只会接受目的 MAC 地址是它自己的单播帧，以及多播帧；在混杂模式下，网卡会接受经过它的所有帧。

查看网卡是否处于 Promiscuous mode，可以使用 ifconfig 或者 netstat -i 命令

ifconfig ens33
ens33: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.142.10  netmask 255.255.255.0  broadcast 192.168.142.255
        inet6 fe80::20c:29ff:fee7:c027  prefixlen 64  scopeid 0x20<link>
        ether 00:0c:29:e7:c0:27  txqueuelen 1000  (Ethernet)
        RX packets 194243  bytes 257521006 (245.5 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 92488  bytes 6051258 (5.7 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

当输出包含 PROMISC 时，表明该网络接口处于 Promiscuous mode，否则表明未处于 Promiscuous mode。要开启网卡的 Promiscuous mode ，可以使用以下命令

$ ifconfig ens33 promisc

$ ifconfig ens33
ens33: flags=4419<UP,BROADCAST,RUNNING,PROMISC,MULTICAST>  mtu 1500
        inet 192.168.142.10  netmask 255.255.255.0  broadcast 192.168.142.255
        inet6 fe80::20c:29ff:fee7:c027  prefixlen 64  scopeid 0x20<link>
        ether 00:0c:29:e7:c0:27  txqueuelen 1000  (Ethernet)
        RX packets 194383  bytes 257531059 (245.6 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 92561  bytes 6058652 (5.7 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

以下命令使网卡退出 Promiscuous mode

ifconfig ens33 -promisc

将网络设备加入 Linux bridge 后，网络设备会自动进入混杂模式，此种情况使用 ifconfig 或者 netstat -i 命令查看网卡，未显示 PROMISC，但是查看内核日志，显示网卡已进入混杂模式，并且无法退出，直到将 veth 从Linux bridge 中移除。网络设备移除网桥后，会自动退出混杂模式。

$ ip link add veth0 type veth peer name veth1

$ brctl show
bridge name	bridge id		STP enabled	interfaces
br0		8000.000000000000	no		

$ brctl addif br0 veth0

$ ifconfig veth0
veth0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 192.168.10.1  netmask 255.255.255.0  broadcast 192.168.10.255
        ether b6:b3:aa:ae:61:05  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

$ netstat -i
Kernel Interface table
Iface             MTU    RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
br0              1500        0      0      0 0            34      0      0      0 BMU
ens33            1500   195528      0      1 0         93168      0      0      0 BMPRU
veth0            1500        0      0      0 0             0      0      0      0 BMU

$ dmesg | grep promisc
[75099.376421] device veth2d80973 entered promiscuous mode
[77630.104784] device ens33 entered promiscuous mode
[77719.626596] device ens33 left promiscuous mode
[77877.905587] device ens33 entered promiscuous mode
[78153.928533] device veth0 entered promiscuous mode
阅读全文 »

发表于 更新于 上层目录 ，

Django 自带的 Admin Site 管理页面可以方便用户快速构建一个简单的后台管理系统，少量代码即可快速实现对数据库中的数据进行展示、修改、保存的可视化页面和功能。当需要对后台展示的数据进行配置时，只需要在 app 的代码文件 admin.py 中进行相应配置即可。

环境信息

  • centos 7
  • python 3.10
  • django 4.0

为 model 配置 admin 管理页面

要为 model 启用 admin 管理接口，参考配置

阅读全文 »

发表于 上层目录

环境信息

  • Centos 7
  • mongodb 4.0.26

下载安装

官方社区版下载页面

wget https://repo.mongodb.org/yum/redhat/7/mongodb-org/4.0/x86_64/RPMS/mongodb-org-shell-4.0.28-1.el7.x86_64.rpm
wget https://repo.mongodb.org/yum/redhat/7/mongodb-org/4.0/x86_64/RPMS/mongodb-org-mongos-4.0.28-1.el7.x86_64.rpm
wget https://repo.mongodb.org/yum/redhat/7/mongodb-org/4.0/x86_64/RPMS/mongodb-org-server-4.0.28-1.el7.x86_64.rpm
wget https://repo.mongodb.org/yum/redhat/7/mongodb-org/4.0/x86_64/RPMS/mongodb-org-tools-4.0.28-1.el7.x86_64.rpm

yum localinstall mongodb-org-mongos-4.0.28-1.el7.x86_64.rpm mongodb-org-tools-4.0.28-1.el7.x86_64.rpm mongodb-org-server-4.0.28-1.el7.x86_64.rpm mongodb-org-shell-4.0.28-1.el7.x86_64.rpm

发表于 上层目录 ，

环境信息

  • Python 3.11
  • Django 4.1

admin 模板解析

Django 模板之间存在各种复杂的继承关系，最基础的模板为 base.html，文件位于 python3.11/site-packages/django/contrib/admin/templates/admin/base.html。下面以 Admin 页面中的各个模块来解析实现对应模块的模板及代码。

title

title 指网页标题，以 Admin 站点的首页为例，首页的模板文件 index.html 中未定义 title 信息，而是继承自 base_site.html

base_site.html
{% extends "admin/base.html" %}

{% block title %}{% if subtitle %}{{ subtitle }} | {% endif %}{{ title }} | {{ site_title|default:_('Django site admin') }}{% endblock 
%}

base_site.html 模板继承了模板 base.html，并使用 {% block title %} 标签复写了继承自 base.html 模板的 title 信息。默认显示 Django site admin，如果应用的 admin.py 中定义了 admin.site.site_title，则显示其内容

base.html
{% load i18n static %}<!DOCTYPE html>
{% get_current_language as LANGUAGE_CODE %}{% get_current_language_bidi as LANGUAGE_BIDI %}
<html lang="{{ LANGUAGE_CODE|default:"en-us" }}" dir="{{ LANGUAGE_BIDI|yesno:'rtl,ltr,auto' }}">
<head>
<title>{% block title %}{% endblock %}</title>

基础模板 base.html 中 title 信息默认为空。

Django 管理或站点标题

Admin 管理页面最顶部左上角会展示默认的 Django 管理 或者站点标题，如果应用的 admin.py 中配置了 admin.site.site_header，则显示站点标题，这是一个链接，点击后会跳转首页。

这部分的实现是通过继承 base_site.html 实现，其中的 {% block branding %} 定义了这部分内容。

base_site.html
{% extends "admin/base.html" %}

{% block title %}{% if subtitle %}{{ subtitle }} | {% endif %}{{ title }} | {{ site_title|default:_('Django site admin') }}{% endblock %}

{% block branding %}
<h1 id="site-name"><a href="{% url 'admin:index' %}">{{ site_header|default:_('Django administration') }}</a></h1>
{% endblock %}

{% block nav-global %}{% endblock %}

用户欢迎信息

Django admin 站点默认会显示如下的欢饮信息及修改密码、注销等链接

此处的配置位于 base.html 中的 {% block usertools %} 块内，{% block usertools %} 块位于 {% block header %} 块内。

base.html
{% block header %}
<div id="header">
    <div id="branding">
    {% block branding %}{% endblock %}
    </div>
    {% block usertools %}
 {% if has_permission %}
    <div id="user-tools">
        {% block welcome-msg %}
            {% translate 'Welcome,' %}
            <strong>{% firstof user.get_short_name user.get_username %}</strong>.
        {% endblock %}
        {% block userlinks %}
            {% if site_url %}
                <a href="{{ site_url }}">{% translate 'View site' %}</a> /
            {% endif %}
            {% if user.is_active and user.is_staff %}
                {% url 'django-admindocs-docroot' as docsroot %}
                {% if docsroot %}
                    <a href="{{ docsroot }}">{% translate 'Documentation' %}</a> /
                {% endif %}
            {% endif %}
            {% if user.has_usable_password %}
            <a href="{% url 'admin:password_change' %}">{% translate 'Change password' %}</a> /
            {% endif %}
            <a href="{% url 'admin:logout' %}">{% translate 'Log out' %}</a>
        {% endblock %}
    </div>
 {% endif %} 
    {% endblock %}
    {% block nav-global %}{% endblock %}
</div>
{% endblock %}

自定义页面

自定义和 Django admin 风格一样的页面

如果要自定义自己的页面，并实现和 Django admin 一致的风格，比如一样的 branding 和用户欢迎信息，可以使用如下代码实现

{% extends "admin/base_site.html" %}
{% load i18n static %}

{% block title %}
My Customize Site
{% endblock %}

{% block extrastyle %}

{% endblock %}

{% block branding %}
<h1 id="site-name"><a href="{% url 'admin:index' %}">My Customize Site</a></h1>
{% endblock %}

{% block usertools %}
<div id="user-tools">
            {% block welcome-msg %}
                {% translate 'Welcome,' %}
                <strong>{% firstof user.get_short_name user.get_username %}</strong>.
            {% endblock %}
            {% block userlinks %}
                {% if site_url %}
                    <a href="{{ site_url }}">{% translate 'View site' %}</a> /
                {% endif %}
                {% if user.is_active and user.is_staff %}
                    {% url 'django-admindocs-docroot' as docsroot %}
                    {% if docsroot %}
                        <a href="{{ docsroot }}">{% translate 'Documentation' %}</a> /
                    {% endif %}
                {% endif %}
                {% if user.has_usable_password %}
                <a href="{% url 'admin:password_change' %}">{% translate 'Change password' %}</a> /
                {% endif %}
                <a href="{% url 'admin:logout' %}">{% translate 'Log out' %}</a>
            {% endblock %}
        </div>

{% endblock %}

{% block breadcrumbs %}{% endblock %}
{% block content %}
hello world
{% endblock %}



发表于 上层目录 ，

环境信息

  • Python3.11
  • Django4

django-bootstrap5 安装配置

pip install django-bootstrap5

在项目配置文件 settings.py 中添加应用名

settings.py

INSTALLED_APPS = [
    ...
    'django_bootstrap5',
]

bootstrap5 使用

发表于 更新于 上层目录

环境信息

  • Mysql 5.7

常用 sql

导出数据

导出到文件

SELECT * FROM [TABLE] 
    INTO OUTFILE '[FILE]' 
    FIELDS TERMINATED BY ',' 
    OPTIONALLY ENCLOSED BY '"' 
    LINES TERMINATED BY '\n'；

参数说明：

  • into outfile ‘导出的目录和文件名’
  • fields terminated by ‘字段间分隔符’
  • optionally enclosed by ‘字段包围符’

  • optionally enclosed by 对数值型字段无效

  • lines terminated by ‘行间分隔符’

产生报错可参考 Mysql 常见错误

插入数据

批量插入

insert into tb(c1,c2) values(1,2),(3,4),(5,6);
阅读全文 »