network

frp就是一个反向代理软件，它体积轻量但功能很强大，可以使处于内网或防火墙后的设备对外界提供服务，它支持HTTP、TCP、UDP等众多协议。我们今天仅讨论TCP和UDP相关的内容。 为什么需要内网穿透功能 从公网中访问自己的私有设备向来是一件难事儿 自己的主力台式机、NAS等等设备，它们可能处于路由器后，或者运营商因为IP地址短缺不给你分配公网IP地址。如果我们想直接访问到这些设备（远程桌面，远程文件，SSH等等），一般来说要通过一些转发或者P2P组网软件的帮助。 我有一台计算机位于一个很复杂的局域网中，我想要实现远程桌面和文件访问，目前来看其所处的网络环境很难通过简单的端口映射将其暴露在公网之中，我试过这么几种方法： 远程桌面使用TeamViewer。可用，但需要访问端也拥有TeamViewer软件，不是很方便，希望能使用Windows自带的远程桌面。且TeamViewer不易实现远程文件访问。 使用蒲公英VPN软件进行组网，可用，但免费版本网络速度极慢，体验不佳，几乎无法正常使用。 使用花生壳软件进行DDNS解析，可用，但同第二点所述，免费版本有带宽限制，无法实际使用。 搭建frp服务器进行内网穿透，可用且推荐，可以达到不错的速度，且理论上可以开放任何想要的端口，可以实现的功能远不止远程桌面或者文件共享。 frp安装 curl -OL https://github.com/fatedier/frp/releases/download/v0.44.0/frp_0.44.0_linux_amd64.tar.gz tar xf frp_0.44.0_linux_amd64.tar.gz -C /usr/local/ cd /usr/local/ ln -sv frp_0.44.0_linux_amd64/ frp cd frp vim frps.ini frp服务端配置 [root@prometheus frp]# cat frps.ini [common] bind_port = 7123 #frp server port vhost_http_port = 8088 #http port vhost_https_port = 8099 #https port token = idBANrqAS3hDK #frp token [root@prometheus frp]# systemctl cat frp.service #frp服务端启动脚本 # /usr/lib/systemd/system/frp.service [Unit] Description=The nginx HTTP and reverse proxy server After=network....

kubernetes，简称K8s，是用8代替名字中间的8个字符“ubernete”而成的缩写。是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单并且高效（powerful）,Kubernetes提供了应用部署，规划，更新，维护的一种机制。 传统的应用部署方式是通过插件或脚本来安装应用。这样做的缺点是应用的运行、配置、管理、所有生存周期将与当前操作系统绑定，这样做并不利于应用的升级更新/回滚等操作，当然也可以通过创建虚拟机的方式来实现某些功能，但是虚拟机非常重，并不利于可移植性。 新的方式是通过部署容器方式实现，每个容器之间互相隔离，每个容器有自己的文件系统 ，容器之间进程不会相互影响，能区分计算资源。相对于虚拟机，容器能快速部署，由于容器与底层设施、机器文件系统解耦的，所以它能在不同云、不同版本操作系统间进行迁移。 容器占用资源少、部署快，每个应用可以被打包成一个容器镜像，每个应用与容器间成一对一关系也使容器有更大优势，使用容器可以在build或release 的阶段，为应用创建容器镜像，因为每个应用不需要与其余的应用堆栈组合，也不依赖于生产环境基础结构，这使得从研发到测试、生产能提供一致环境。类似地，容器比虚拟机轻量、更“透明”，这更便于监控和管理。 kubernetes高可用集群的典型架构 kubernetes github 组件 ### 控制面组件： etcd：多实例并行运行，通过Raft保证一致； apiserver：多实例并行运行； controller-manager：多实例仅有1个节点active； scheduler：多实例仅有1个节点active； ### 工作节点组件： kubelet kube-proxy ### 注： 1. apiserver多实例运行: apiserver是无状态的，所有数据保存在etcd中，apiserver不做缓存。apiserver多个实例并行运行，通过Loadbalancer负载均衡用户的请求。 2. scheduler和controller-manager单实例运行: scheduler和controller-manager会修改集群状态，多实例运行会产生竞争状态。通过--leader-elect机制，只有领导者实例才能运行，其它实例处于standby状态；当领导者实例宕机时，剩余的实例选举产生新的领导者。领导者选举的方法：多个实例抢占创建endpoints资源，创建成功者为领导者。比如多个scheduler实例抢占创建endpoints资源：kube-scheduler sh# kubectl get endpoints kube-scheduler -n kube-system -o yaml apiVersion: v1 kind: Endpoints metadata: annotations: control-plane.alpha.kubernetes.io/leader: '{"holderIdentity":"master1_293eaef2-fd7e-4ae9-aae7-e78615454881","leaseDurationSeconds":15,"acquireTime":"2021-10-06T20:46:43Z","renewTime":"2021-10-19T02:49:21Z","leaderTransitions":165}' creationTimestamp: "2021-02-01T03:10:48Z" ...... # 查询kube-scheduler endpoint资源，可以看到此时master1上的scheduler是active状态，其它实例则为standby。 3. kubelet和kube-proxy在工作节点上运行 1. kubelet负责：向apiserver创建一个node资源，以注册该节点； 持续监控apiserver，若有pod部署到该节点上，创建并启动pod； 持续监控运行的pod，向apiserver报告pod的状态、事件和资源消耗； 周期性的运行容器的livenessProbe，当探针失败时，则重启容器； 持续监控apiserver，若有pod删除，则终止该容器； 2. kube-proxy负责： 负责确保对服务ip和port的访问最终能到达pod中，通过节点上的iptables/ipvs来实现； 3. 控制平台组件开启和关闭实验结果： 3个kube-apiserver关掉2个，只保留1个，可以正常接收kubectl命令操作、 3个kube-scheduler和kube-controller-manager关掉2个节点，只保留1个节点可以正常操作 只保留1个kube-controller-manager，而kube-scheduler3个节点全部关闭，在创建deployment和service时候，任务会被创建成功，但是pod会被一直pending，因为pod没有调度器调度，此时开启一个kube-scheduler后，pending状态的pod正常运行。 只保留1个kube-scheduler，而kube-controller-manager3个节点全部关闭，在创建deployment和service时候，任务不会被创建成功，因为kube-controller-manager没有运行，无法使用deployment控制器创建pod，虽然kube-scheduler运行，但是控制器没有运行，后面的调度任务也就不会被运行。