React - 组件 概念：一个组件即用户界面的一部分，它有自己的逻辑和样式，如：Header、SiderBar、MainPage在 React 中，一个组件就是首字母大写（大驼峰）的函数，内部存放对应组件的逻辑和视图 UI，使用时把组件当成标签书写即可// 定义组件 const Button = () => { return <button>Click</button> } function App() { return ( <div className="App"> {/* 使用/渲染组件 */} <Button /> </div> ) } export default App

React - 事件绑定 1. 基础事件绑定语法：on + 事件名称 = { 事件处理方法/函数 }function App() { const clickHandler = () => { alert('事件绑定') } return ( <div className="App"> <button onClick={clickHandler}>Click</button> </div> ) } export default App 2. 使用事件对象参数function App() { const clickHandler = (e) => { alert('事件绑定') console.log('事件参数', e) } return ( <div className="App"> <button onClick={clickHandler}>Click</button> </div> ) } export default App 3. 传递自定义参数语法：绑定事件时改造为箭头函数（通过函数引用的方式实现），通过形参传递function App() { const clickHandler = (name) => { console.log('自定义参数', name) } return ( <div className="App"> <button onClick={() => clickHandler('孙笑川')}>Click</button> </div> ) } export default App 4. 同时传递事件对象和自定义参数语法：在绑定事件的位置传递事件实参 e，clickHandler 中声明形参，且需要注意参数的顺序function App() { const clickHandler = (name, e) => { console.log('自定义参数', name, '事件参数', e) } return ( <div className="App"> <button onClick={(e) => clickHandler('孙笑川', e)}>Click</button> </div> ) } export default App

React - 简介、JSX基础 一、搭建开发环境官网快速开始文档 - 创建一个 React 项目：https://18.react.dev/learn/creating-a-react-appnpx create-react-app react-demo npm start二、JSX 基础1. 概念JSX（JS的语法扩展）是JavaScript 和 XML（HTML）的缩写，表示在 js 代码中编写 HTML 模板结构，它是 React 中编写 UI 模板的方式2. 使用 js 表达式在 JSX 中可以通过大括号语法 {} 识别 js 中的表达式，如：变量、函数调用、方法调用等使用引号传递字符串使用 js 变量函数调用和方法调用使用 js 对象const index = 1 function getName() { return '孙笑川' } function App() { return ( <div className="App"> 这是 React Demo {/* 使用引号传递字符串 */} {'这是 React Demo'} {/* 使用 js 变量 */} {index} {/* 函数调用 */} {getName()} {/* 方法调用 */} {new Date().getDate()} {/* 使用js对象 */} <div style={{ color: 'red' }}>这是 React Demo</div> </div> ); } export default App; 3. 列表渲染const list = [ {id: '1', name: '孙笑川'}, {id: '2', name: '药水哥'}, {id: '3', name: '刘波'} ] function App() { return ( <div className="App"> {/* 渲染列表 */} <ul> {list.map(item => <li key={item.id}>{item.name}</li>)} </ul> </div> ); } export default App; 4. 条件渲染通过逻辑运算符、三元表达式实现基础的条件渲染const flag = true function App() { return ( <div className="App"> {/* 逻辑运算 */} {flag && <span>这是 span 标签</span>} {/* 三元运算 */} {!flag ? <span>这是 span 标签</span> : <p>这是 p 标签</p>} </div> ); } export default App; 5. 复杂条件渲染通过自定义函数 + if 判断语句实现const type = 1 // 0 1 2 function getType() { if (type === 0) { return <div>孙笑川</div> } if (type === 1) { return <div>药水哥</div> } if (type === 2) { return <div>刘波</div> } } function App() { return ( <div className="App"> {/* 复杂条件渲染 */} {getType()} </div> ); } export default App;

四、Podman - 网络 1. 简介Podman 管理的容器在进行网络连接时，非特权用户无法在主机上创建网络接口，默认是 slirp4netns，相比于特权用户而言缺少一部分功能，如：无法为容器分配 IP 地址；特权用户运行的容器默认网络模式是 netavark。防火墙当容器执行端口映射时，防火墙也会同步打开对应的端口，但当重新加载防火墙规则时，会删除 netavark iptables，导致容器丢失网络连接，Podman v3 提供了 podman network reload 命令来恢复对应设置，且无需重启容器。2. 桥接桥接指创建一个内部网络，容器和主机都连接到该网络，以此实现容器与外部主机通信Podman 默认使用桥接模式，同时也提供了一个默认的桥接网络，从 4.0 版本开始，非特权用户运行的容器也可以使用 netavark（但不提供默认配置）从旧版本 CNI 切换到 netavark 时，需执行 podman system reset --force 命令，该命令会删除所有的镜像、容器和自定义网络rootless 容器的网络操作是在一个额外的命名空间内执行的，可以通过 podman unshare --rootless-netns 命令加入3. 默认Netavark 是纯内存网络，由于需要向后兼容 Docker，因此不支持 DNS 解析，可通过以下命令修改对应的配置文件# 特权 podman network inspect podman | jq .[] > /etc/containers/networks/podman.json # 非特权 podman network inspect podman | jq .[] > ~/.local/share/containers/storage/networks/podman.json以特权和非特权为例，将服务暴露至主机外# 特权 sudo podman run -d --name webserver -p 8080:80 quay.io/libpod/banner 00f3440c7576aae2d5b193c40513c29c7964e96bf797cf0cc352c2b68ccbe66a # 非特权 podman run -d --name webserver --network podman1 -p 8081:80 quay.io/libpod/banner 269fd0d6b2c8ed60f2ca41d7beceec2471d72fb9a33aa8ca45b81dc9a0abbb12外部客户端可通过8080 或 8081 端口访问到对应的服务4. MacvlanPodman 必须以 root 身份才能操作 macvlan# 创建 macvlan，eth0 为主机的网络接口（与 Docker 的创建方式一致） sudo podman network create -d macvlan -o parent=eth0 macvlan_test macvlan_test # --subnet指定子网，不使用 DHCP（可选） sudo podman network create -d macvlan \ --subnet 192.168.123.0/24 \ --gateway 192.168.123.1 \ -o parent=eth0 \ macvlan_test # 使用 DHCP # 查看当前使用的网络后端 sudo podman info --format {{.Host.NetworkBackend}} # NetAvark 启用 DHCP（以systemd为例） sudo systemctl enable --now netavark-dhcp-proxy.socket # CNI 启用 DHCP（以systemd为例） sudo systemctl enable --now cni-dhcp.socket# 容器使用 macvlan sudo podman run -d --name webserver --network macvlan_test quay.io/libpod/banner 03d82083c434d7e937fc0b87c25401f46ab5050007df403bf988e25e52c5cc40 # 使用外部客户端访问 (outside_host): $ curl http://<容器分配到的ip> ___ __ / _ \___ ___/ /_ _ ___ ____ / ___/ _ \/ _ / ' \/ _ `/ _ \ /_/ \___/\_,_/_/_/_/\_,_/_//_/5. Slirp4netnsSlirp4netns 是 rootless 容器和 Pod 的默认网络配置，它的出现是因为非特权用户无法在主机上创建网络接口。Slirp4netns 会在容器的网络命名空间中创建一个 TAP 设备，并连接到用户模式 TCP/IP 协议栈非特权用户必须使用 1024 到 65535 端口，因为更低的端口需要 root 权限，可以使用以下方法调整默认的设置 sysctl net.ipv4.ip_unprivileged_port_startslirp4netns 网络模式下，容器与容器之间完全隔离，且没有虚拟网络，容器之间要进行通信时，需要使用与宿主机的端口映射，或者将它们放入同一个 Pod 中（即共享同一个网络命名空间）以两个 rootless 容器通信为例# 假设主机 ip 为 192.168.123.123 # 运行 rootless 容器 podman run -d --name webserver -p 8080:80 quay.io/libpod/banner 17ea33ccd7f55ff45766b3ec596b990a5f2ba66eb9159cb89748a85dc3cebfe0 # 运行另一个 rootless 容器，并执行 curl podman run -it quay.io/libpod/banner curl http://192.168.123.123:8080 # 外部客户端访问 (outside_host): $ curl http://192.168.123.123:8080 ___ __ / _ \___ ___/ /_ _ ___ ____ / ___/ _ \/ _ / ' \/ _ `/ _ \ /_/ \___/\_,_/_/_/_/\_,_/_//_/6. 容器与 Pod 之间的通信Podman Pod 中的所有容器共享同一个网络命名空间（即它们将具有相同的 IP 地址、MAC 地址和端口映射），Pod 中的容器之间可以使用 localhost 方便地进行通信如上图所示，该 Pod 中的 DB Container 和 Web Container 所属同一个网络命名空间下，他们之间可以通过 localhost:[port] 进行通信，也可以通过分配给 Pod 的 ip 进行寻址，在 DNS 服务可用时，也可以使用 dns name 进行通信（类似于 K8s 中的 Core DNS）。

三、Podman - 对镜像进行签名和分发 以 GNU Privacy Guard（GPG）密钥为例如果使用 Podman 在将镜像推送到镜像仓库前对其进行了签名，则拉取时的客户端必须配置为从远程服务器获取签名，未签名的镜像都将被拒绝1. 生成 GPG密钥gpg --full-gen-key # 验证密钥 gpg --list-keys xxx@gmail.com2. 拉取镜像# 拉取镜像 podman pull docker://docker.io/alpine:latest # 查看 podman images alpine REPOSITORY TAG IMAGE ID CREATED SIZE docker.io/library/alpine latest e7b39c54cdec 4 weeks ago 8.74 MB # 自定义 tag（localhost:5000 为本地镜像仓库） sudo podman tag alpine localhost:5000/alpine3. 修改配置/etc/containers/registries.d/default.yaml default-docker: sigstore: http://localhost:8000 # 引用网络服务器进行签名读取 sigstore-staging: file:///var/lib/containers/sigstore # 引用文件路径进行签名写入4. 签名并推送镜像sudo -E GNUPGHOME=$HOME/.gnupg \ podman push \ --tls-verify=false \ --sign-by sgrunert@suse.com \ localhost:5000/alpine … Storing signatures推送镜像后，可以看到产生的新的可用签名ls /var/lib/containers/sigstore 'alpine@sha256=e9b65ef660a3ff91d28cc50eba84f21798a6c5c39b4dd165047db49e84ae1fb9'5. 自定义本地8000端口服务bash -c 'cd /var/lib/containers/sigstore && python3 -m http.server' Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...6. 强制签名要求配置nano /etc/containers/policy.json { "default": [{ "type": "insecureAcceptAnything" }], "transports": { "docker": { "localhost:5000": [ { "type": "signedBy", "keyType": "GPGKeys", "keyPath": "/tmp/key.gpg" } ] } } }# 将 GPG 密钥放置到 keyPath 目录下 gpg --output /tmp/key.gpg --armor --export xxx@gmail.com7. 拉取测试# 先删除本地已经拉取的 alpine 镜像 podman rmi docker.io/alpine localhost:5000/alpine # 重新拉取 podman pull --tls-verify=false localhost:5000/alpine此时在8000端口的服务日志中可以看到访问签名的日志8. 错误配置示例keyPath 路径配置错误，在拉取镜像时会报错sudo podman pull --tls-verify=false localhost:5000/alpine Trying to pull localhost:5000/alpine... Error: pulling image "localhost:5000/alpine": unable to pull localhost:5000/alpine: unable to pull image: Source image rejected: Invalid GPG signature: ......

二、Podman - 安装和基础命令 1. 安装以 Debian 12 为例apt install podman root@debian:~# podman version Client: Podman Engine Version: 4.3.1 API Version: 4.3.1 Go Version: go1.19.8 Built: Thu Jan 1 08:00:00 1970 OS/Arch: linux/amd64 2. 基础命令运行示例容器# 以基础的 httpd 服务为例 podman run --name nginx-test -d -p 8080:80/tcp docker.io/nginx注：该命令下容器以分离模式运行（-d），Podman 会在运行结束后打印容器ID列出正在运行的容器podman ps # 列出所有容器 podman ps -a检查运行中的容器podman inspect <container>注：由于容器以 rootless 模式运行，因此不会分配 IP 地址，inspect 信息中该项的值为 none测试 httpd 服务root@debian:~# curl http://localhost:8080 <!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> 查看容器日志podman logs -f <container_id>root@debian:~# podman logs nginx-test /docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration /docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/ /docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh 10-listen-on-ipv6-by-default.sh: info: Getting the checksum of /etc/nginx/conf.d/default.conf 10-listen-on-ipv6-by-default.sh: info: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf /docker-entrypoint.sh: Sourcing /docker-entrypoint.d/15-local-resolvers.envsh /docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh /docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh /docker-entrypoint.sh: Configuration complete; ready for start up 2026/01/14 14:05:20 [notice] 1#1: using the "epoll" event method 2026/01/14 14:05:20 [notice] 1#1: nginx/1.29.4 2026/01/14 14:05:20 [notice] 1#1: built by gcc 14.2.0 (Debian 14.2.0-19) 2026/01/14 14:05:20 [notice] 1#1: OS: Linux 6.1.0-41-amd64 2026/01/14 14:05:20 [notice] 1#1: getrlimit(RLIMIT_NOFILE): 1048576:1048576 2026/01/14 14:05:20 [notice] 1#1: start worker processes 2026/01/14 14:05:20 [notice] 1#1: start worker process 24 2026/01/14 14:05:20 [notice] 1#1: start worker process 25 2026/01/14 14:05:20 [notice] 1#1: start worker process 26 2026/01/14 14:05:20 [notice] 1#1: start worker process 27 10.88.0.1 - - [14/Jan/2026:14:05:38 +0000] "GET / HTTP/1.1" 200 615 "-" "curl/7.88.1" "-" 查看容器信息和进程root@debian:~# podman top nginx-test USER PID PPID %CPU ELAPSED TTY TIME COMMAND root 1 0 0.000 2m26.588290297s ? 0s nginx: master process nginx -g daemon off; nginx 24 1 0.000 2m26.588345391s ? 0s nginx: worker process nginx 25 1 0.000 2m26.588369296s ? 0s nginx: worker process nginx 26 1 0.000 2m26.588388167s ? 0s nginx: worker process nginx 27 1 0.000 2m26.588406535s ? 0s nginx: worker process 检查容器对容器进行检查点操作会停止容器运行，并将容器内所有进程的状态写入磁盘，在有需要的时候可以恢复，并从检查点创建时的状态继续运行（此功能需要系统上安装 CRIU 3.11 或更高版本，且不支持 rootless）sudo podman container checkpoint <container_id>恢复容器创建过检查点的容器才支持快照sudo podman container restore <container_id>迁移容器创建检查点 ---> 将对应文件传输至目标主机 ---> 目标主机恢复容器# 原主机 sudo podman container checkpoint <container_id> -e /tmp/checkpoint.tar.gz scp /tmp/checkpoint.tar.gz <destination_host>:/tmp # 目标主机 sudo podman container restore -i /tmp/checkpoint.tar.gz 停止容器podman stop <container_id>移除容器podman rm <container_id>

一、Podman - 简介 一、简介1. 概念Podman 是一个无守护进程、开源、Linux原生的工具，遵循 OCI 开放容器倡议的容器合容器镜像，可以轻松的查找、运行、构建、共享和部署应用程序。与其他常见的容器（Docker、CRI-O、Containerd）类似，Podman 依赖于一个符合 OCI 规范的容器运行时（如 runc、crun、runv 等）来与操作系统交互并创建运行中的容器。2. 特性Podman 容器支持 root / rootless 模式，其使用 libpod 库来管理整个容器生态系统，包括 Pod、容器、容器镜像和容器卷。Linux 环境下提供管理容器的 RESTful API

五、DestinationRule 1. 概念字段名称说明spec.host关联 DestinationRule 配置的服务名称，可以是自动发现的服务（例如Kubernetes service name），或通过 ServiceEntry 声明的 hosts。如填写的服务名无法在上述源中找到。则该 DestinationRule 中定义的规则无效spec.subsets定义服务的版本（subsets），版本可通过标签键值对匹配服务中的endpoints。可以在 subsets 级覆盖流量策略配置spec.trafficPolicy定义流量策略，包括负载均衡、连接池、健康检查、TLS 策略等spec.spec.trafficPolicy.loadBalancer配置负载均衡算法，可配置：简单负载均衡算法(round robin，least conn，random...) ，一致性哈希（会话保持，支持按 header name，cookie，IP，query parameter 哈希)，地域感知负载均衡算法spec.trafficPolicy.connectionPool配置与上游服务的连接量，可设置 TCP/HTTP 连接池spec.trafficPolicy.outlierDetection配置从负载均衡池中驱逐不健康的 hostsspec.trafficPolicy.tls连接上游服务的 client 端 TLS 相关配置，与 PeerAuthentication 策略（server 端 TLS 模式配置）配合使用spec.trafficPolicy.portLevelSettings配置端口级的流量策略，该策略会覆盖服务 / subsets 级别的流量策略配置DestinationRule 在路由发生后应用于流量，支持如下配置：负载均衡连接池局部异常点检测客户端 TLS 配置端口流量策略2. 负载均衡设置通过负载均衡设置，可以控制目的地使用的负载均衡算法apiVersion: netweorking.istio.io/v1alpha3 kind: DestinationRule metadata: name: nginx-destination spec: host: nginx.test.svc.cluster.local trafficPolicy: loadBalancer: simple: ROUND_ROBIN # 轮询 subsets: - name: v1 labels: version: vl - name: v2 labels: version: v2simple字段：ROUND_ROBIN：轮询算法，如果未指定则默认采用这种算法LEAST_CONN：最少连接算法，从两个随机选择的服务选择一个活动请求数较少的后端实例RANDOM：从可用的健康实例中随机选择一个PASSTHROUGH：直接转发连接到客户端连接的目标地址，即不做做负载均衡consistentHash 字段：httpHeaderName：基于 HeaderhttpCookie：基于 CookieuseSourcelp：基于源 IP 计算哈希值minimumRingSize：哈希环上虚拟节点数的最小值，节点数越多则负载均衡越精细trafficPolicy: loadBalancer: consistentHash: httpCokkie: name: location ttl: 2s3. 连接池配置可以在 TCP 和 HTTP 层面应用于上游服务的每个主机，可以用它们来控制连接量tcp 连接池配置：maxConnections：上游服务的所有实例建立的最大连接数，默认值1024，属于 TCP 层的配置，对于HTTP，只作用于 HTTP/1.1，因为 HTTP/2 对每个主机都使用单个连接connectTimeout：TCP 连接超时，表示主机网络连接超时，可以改善因调用服务变慢而导致整个链路变慢的情况tcpKeepalive：lstio1.1 版本开始新支持的配置，定期给对端发送一个 keepalive 探测包，判断连接是否可用spec: host: nginx.test.svc.cluster.local trafficPolicy: connectionPool: tcp: maxConnections: 50 connectTimeout: 25ms tcpKeepalive: probes: 5 time: 3600 interval: 60shttp 连接池配置：http1MaxPendingRequests：最大等待 HTTP 请求数，默认值1024，只适用于 HTTP/1.1 的服务，因为 HTTP/2 协议的请求在到来时会立即复用连接，不会在连接池等待http2MaxRequests：最大请求数，默认值1024，只适用于 HTTP/2 服务，因为 HTTP/1.1 使用最大连接数 maxConnections 即可，表示上游服务的所有实例处理的最大请求数maxRequestsPerConnection：每个连接的最大请求数，HTTP/1.1 和 HTTP/2 连接池都遵循此参数，如果没有设置，则代表不限制设置为1时表示每个连接只处理一个请求，相当于禁用了 Keep-alivemaxRetries：最大重试次数，默认值3，表示服务可以执行的最大重试次数。如果调用端因为偶发的抖动导致请求直接失败，则可能会带来业务损失，一般建议配置重试，若重试成功则可正常返回数据，只不过比原来响应得慢一点，但如果重试次数太多，会对性能造成一定的影响idleTimeout：空闲超时，即：在多长时间内没有活动请求则关闭连接# 配置最大80个连接，最多100个并发请求，每个请求的连接数不超过10个，超时时间为30ms spec: host: nginx.test.cluster.local trafficPolicy: connectionPool: tcp: maxConnections: 80 connectTimeout: 30ms http: http2MaxRequests: 100 maxRequestsPerConnection: 104. 异常点检测异常点检测是一个断路器的实现，它跟踪上游服务中每个主机（Pod）的状态，如果其中一个主机开始返回 5xx HTTP 错误，它就会在预定的时间内被从负载均衡池中弹出，对于 TCP 服务，Envoy 将连接超时或失败计算为错误。两种健康检查：主动检查：定期探测目标服务实例，根据应答来判断服务实例的健康状态，如负载均衡器中的健康检查被动检查：通过实际的访问情况来找出不健康的实例，如 Istio 中的异常点检查异常实例检查相关的配置：consecutiveErrors：实例被驱逐前的连续错误次数，默认值5。对于 HTTP 服务，返回502、503 和 504 的请求会被认为异常；对于 TCP 服务，连接超时或者连接错误事件会被认为异常interval：驱逐的时间间隔，默认值10秒，要求大于1毫秒，单位可以是时、分、毫秒baseEjectionTime：最小驱逐时间，一个实例被驱逐的时间等于这个最小驱逐时间乘以驱逐的次数，这样一个因多次异常被驱逐的实例，被驱逐的时间会越来越长，默认值30秒，要求大于1毫秒，单位可以是时、分、毫秒maxEjectionPercent：指负载均衡池中可以被驱逐的故障实例的最大比例，默认值10%，该设置是为了避免太多的服务实例被驱逐导致服务整体能力下降minHealthPercent：最小健康实例比例，是 lstio 1.1 新增的配置，当负载均衡池中的健康实例数的比例大于这个比例时，异常点检查机制可用，反之该功能将被禁用；所有服务实例不管被认定为健康还是不健康，都可以接收请求，参数的默认值为50%# 最大500个http2请求，每个连接不超过10个请求，每5分钟扫描一次上游主机（Pod），如果其中任何一个主机连续失败10次，Envoy 会将其弹出10分钟 trafficPolicy: coninectionPool: http: http2MaxRequests: 500 maxRequestsPerConnection: 10 outlierDetection: consecutiveErrors: 10 interval: 5m baseEjectionTime: 1om5. TLS 设置其包含任何与上游服务连接的 TLS 相关设置trafficPolicy: tls: mode: MUTUAL clientCertificate: ./certs/cert.pem privatekey: ./certs/key - pem caCertificates: ./certs/ca.pemmTLS：双向认证，客户端和服务端都通过证书颁发机构验证彼此的身份，即：由同一个 root ca 生成两套证书，客户端、服务端各一个，客户端通过 https 访问服务时，双方会交换证书，并进行认证，认证通过后即可进行通信TLS 模式：DISABLE：无 TLS 连接SIMPLE：在上游端点发起 TLS 连接ISTIO_MUTUAL：与 MUTUAL 类似，使用 Istio 的 mTLS 证书6. 端口流量策略在端口上配置流量策略，配置后其会覆盖全局的流量策略trafficPolicy: connectionPool: tcp: maxConnections: 80 portLevelSettings: - port: number: 80 loadBalancer: simple: LEAST_CONN connectionPool: tcp: maxConnections: 100 - port: number: 80 loadBalancer: simple: ROUND_ROBIN7. 服务子集subset：定义服务的子集name：服务子集的名称，必填字段，VirtualService 通过该属性引用label：标签，通过一组标签定义属于这个服务子集的实例，如：version（版本）trafficPolicy：应用到该子集上的流量策略# 给名称为 nginx-v1 的服务子集配置最大连接数 spec: hosts: nginx subsets: - name: nginx-v1 labels: version: v2 trafficPolicy: connectionPool: tcp: maxConnections: 100