上个月底， 由于一些迷之原因我从扇贝跑路了

又过回了大学那会养生的日子，有空来捣鼓一些奇奇怪怪的东西。 最近在研究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": "[email protected]"
 }
 ]
 }
 },
 "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 命令获得

测个速度看看：

效果不错，打完收工！

最后

这篇文章还是会发在爬虫的专栏下

如果这篇文章反响好的话 我可能会再开一个伺服器/云相关的专栏

哪位大佬给取个名字呗？

推荐阅读：

相关文章