作者介绍:简历上没有一个精通的运维工程师。下面的思维导图也是预计更新的内容和当前进度(不定时更新)。
我们上一章介绍了Docker基本情况,目前在规模较大的容器集群基本都是Kubernetes,但是Kubernetes涉及的东西和概念确实是太多了,而且随着版本迭代功能在还增加,笔者有些功能也确实没用过,所以只能按照我自己的理解来讲解。
我们前面讲解过Docker的仓库Registry和Harobr,默认数据都是存储本地的,并不符合高可用的原则。今天我们来提供一个数据在对象存储的思路,可供参考。这个也是我以前在某云厂商时候的标注方案。
首先说明下,默认的对象存储,都不能直接使用当前功能。包括公有云(测试过阿里云和腾讯云)和本地Ceph搭建的对象存储,都会遇到类似的问题。
下面则是我向云厂商要求配置支持的工单,当对象存储确认无误以后,就可以开始配置使用。下面的范例也是基于腾讯云。
1.准备COS需要的AK&SK
#注意权限控制和安全
https://console.cloud.tencent.com/cam/capi
2.开通对象存储
#需要获取桶名字,地域名字,eb地址。
https://console.cloud.tencent.com/cos/bucket
3.创建Secret
#使用我们第一步获得的AK和SK,然后按照secret方式配置
#下面的数据需要进行base64转码
apiVersion: v1
kind: Secret
metadata:
name: cos-secret
type: Opaque
data:
accessKey: xxxx
secretKey: xxxx
4.创建Deployment
#自己使用,需要替换地域,域名,桶名字
#由于后端不在本地,所以他是可以跑多副本的
apiVersion: apps/v1
kind: Deployment
metadata:
name: registry
spec:
replicas: 1
selector:
matchLabels:
app: registry
template:
metadata:
labels:
app: registry
spec:
containers:
- name: registry
image: registry:latest
ports:
- containerPort: 5000
protocol: TCP
env:
- name: REGISTRY_STORAGE
value: s3
- name: REGISTRY_STORAGE_S3_REGION
value: ap-chengdu
- name: REGISTRY_STORAGE_S3_SECURE
value: "true"
- name: REGISTRY_STORAGE_S3_REGIONENDPOINT
value: cos.ap-chengdu.myqcloud.com
- name: REGISTRY_STORAGE_S3_BUCKET
value: registry-1252129165
- name: REGISTRY_STORAGE_S3_ACCESSKEY
valueFrom:
secretKeyRef:
name: cos-secret
key: accessKey
- name: REGISTRY_STORAGE_S3_SECRETKEY
valueFrom:
secretKeyRef:
name: cos-secret
key: secretKey
5.创建Service
由于我们这里使用的Containerd版本,而他是没有修改tag的参数,所以我们这里需要通过NodePort方式暴露到集群外。至于集群外的tag修改和规避https的问题可以去翻看我的Docker-总结篇。
apiVersion: v1
kind: Service
metadata:
name: registry-svc
namespace: default # 如果你在不同的命名空间,请修改此处
spec:
selector:
app: registry # 必须匹配 Deployment 中的标签
ports:
- protocol: TCP
port: 5000 # Service 端口
targetPort: 5000 # 容器端口
nodePort: 30007 # 可选:指定一个特定的 NodePort,范围应为 30000-32767
type: NodePort # 使用 NodePort 类型
6.上传镜像测试
7.检查对象存储
当然这里还有些以前调试留下的数据,但是这里的pasue是可以和上图的pause镜像匹配上的。
总结
这里我使用的是registry默认仓库,如果你需要使用Harbor其实也可以只是需要把对应的信息放置到Harbor即可。
如果是生产环境,把仓库本身也放置到Kubernetes的集群里面,需要考虑的一个问题就是如果仓库服务宕机,迁移到其他没有镜像的服务器就会出现死循环:仓库服务启动需要下载镜像,而镜像服务目前还没启动。解决办法就是把这个镜像放置到每个节点或者多副本。