k3s历险记(一):先跑起来 上个月底, 由于一些迷之原因我从扇贝跑路了 又过回了大学那会养生的日子,有空来捣鼓一些奇奇怪怪的东西。 最近在研究k3s,最终目标是将自己的一些项目迁移上去 这里开始准备写一系列的文章来记录一下整个过程 什么是k3s? Lightweight Kubernetes. 5 less than k8s 先简单解释一下啥是k8s k8s是容器编排系统 说的再直白一点: k8s可以管理不同机子上的docker 现在各厂都在像容器化的方向发展作为个人开发者当然也想用类似的工具 但k8s集群的部署要求太高了(因为要跑etcd)而不得不放弃 一个小型k8s集群master节点的推荐配置是 2c 8g !! 今年2月26日Rancher发布了k3s 那时我就知道,有戏了!k3s其实是k8s的一个超轻量的发型版 轻量到啥地步呢?k3s打包后只有一个40mb大小的二进位包运行k3s server只需要200m左右的ram这样看来一台1c1g的vps就能愉快的跑起来了 我还发现有国外老哥用k3s组了一个树莓派集群效果大概是这样的: 先跑起来 由于k3s目前不支持mac 所以我找了一台1c1g的vultr家的vps来当master node 如果你也想要买一台来练练手 这里有个推广链接 注册冲5刀可送50刀: 注册地址 可以通过官网的一键安装脚本来安装 curl -sfL https://get.k3s.io | sh - 这样一个单节点的k3s服务就跑起来了 在本机访问k3s集群 安装kubectl :brew install kubectl配置集群证书:将vps上的 /etc/rancher/k3s/k3s.yaml 的内容 写入本机的~/.kube/config文件试一下: kubectl get node 可以看到这台节点已经成功跑起来了(ready) 再跑个应用 一般都会跑个helloworld之类的app来试一下效果我觉得这样太没意思啦,我们来跑个能用的比如 v2ray 起一个namepace kind: Namespace apiVersion: v1 metadata: name: playground labels: name: playground 拷贝以上文件为ns-playgroud.yml 在文件对应的目录运行: kubectl apply -f ns-playground.yml 这样我们就有一个名为playground的namespce了运行 kubectl get ns 可以查看所有的namespace 起一个configmap 来存v2ray的配置文件 apiVersion: v1 kind: ConfigMap metadata: name: v2ray-config-file namespace: playground labels: k8s-app: v2ray data: config.json: |- { "stats": {}, "api": { "tag": "api", "services": [ "StatsService" ] }, "policy": { "levels": { "0": { "statsUserUplink": true, "statsUserDownlink": true } }, "system": { "statsInboundUplink": true, "statsInboundDownlink": true } }, "log": { "access": "/dev/stdout", "error": "/dev/stderr", "loglevel": "info" }, "inbound": { "port": 8002, "tag": "statin", "protocol": "vmess", "settings": { "clients": [ { "id": "11111111-2222-3333-4444-555555555555", "level": 1, "alterId": 16, "email": "ehco@ss.com" } ] } }, "inboundDetour": [ { "listen": "127.0.0.1", "port": 6000, "protocol": "dokodemo-door", "settings": { "address": "127.0.0.1" }, "tag": "api" } ], "outbound": { "protocol": "freedom", "settings": {} }, "routing": { "strategy": "rules", "settings": { "rules": [ { "inboundTag": [ "api" ], "outboundTag": "api", "type": "field" } ] } } } 拷贝以上文件为cm-v2ray.yml 在文件对应的目录运行: kubectl apply -f cm-v2ray.yml -n playground 这样v2ray的配置文件就作为一种资源被存在k3s里了 起一个deployment来跑v2ray apiVersion: extensions/v1beta1 kind: Deployment metadata: name: v2ray-vu namespace: playground spec: replicas: 1 selector: matchLabels: app: v2ray-vu strategy: rollingUpdate: maxSurge: 25% maxUnavailable: 25% type: RollingUpdate template: metadata: labels: app: v2ray-vu spec: containers: - name: app image: v2ray/official imagePullPolicy: IfNotPresent ports: - containerPort: 8002 resources: limits: cpu: 200m memory: 200Mi requests: cpu: 100m memory: 100Mi volumeMounts: - name: v2ray-config-file mountPath: "/etc/v2ray" readOnly: true volumes: - name: v2ray-config-file configMap: name: v2ray-config-file 这里用了我们刚创建的configmap :v2ray-config-file 并将其挂载到容器的/etc/v2ray目录下 这样v2ray跑起来的时候就能读取到准备的配置了拷贝以上文件为dp-v2ray.yml在文件对应的目录运行: kubectl apply -f dp-v2ray.yml -n playground playground 看一下服务有没有跑起来: kubectl get pod -n playground 可以看到v2ray已经处于running状态了 起一个service来暴露v2ray的服务 kind: Service apiVersion: v1 metadata: name: v2ray-vu namespace: playground spec: selector: app: v2ray-vu ports: - port: 8002 targetPort: 8002 externalIPs: - xx.xx.xx.xx 注意配置里的externalIPs 需要替换成你自己vps的ip拷贝以上文件为svc-v2ray.yml 在文件对应的目录运行: kubectl apply -f svc-v2ray.yml -n playground playground这样我们就将v2ray的服务暴露在节点的8002埠 所有从8002埠流量都会被转发到v2ray的pod里 看一下效果 查看访问日志 : kubectl logs -f podname -n playground podname 可以通过之前的get pod 命令获得 测个速度看看: 效果不错,打完收工! 最后 这篇文章还是会发在爬虫的专栏下 如果这篇文章反响好的话 我可能会再开一个伺服器/云相关的专栏 哪位大佬给取个名字呗? 推荐阅读: 相关文章 {{#data}} {{title}} {{/data}}