本篇博客将具体介绍如何在云服务器上搭建 Kubernetes 1.19 集群，以及在咱们部署好的集群上应用 Helm 部署 gitlab和 minio 服务。
部署环境
两台云服务器
配置为:
- 4 核 8GB 内存
- 2 核 4GB 内存
- 操作系统：ubuntu 18.04
目录
- 搭建 Kubernetes 1.19 集群
- 应用 helm 部署 gitlab 与 minio
1. 搭建 Kubernetes 1.19 集群
我的master节点设定为4核8gb的机器，这里称其为master,另一台机称为worker。
Step 1: 进入root用户的身份（master）
su输出root的明码即可。
Step 2: 装置docker（master和worker都要操作）
对于 docker 的装置倡议参考官网文档. 这里给出疾速装置的脚本:
curl -fsSL https://get.docker.com | sudo sh -s -- --mirror Aliyunsudo usermod -aG docker $USERsudo mkdir -p /etc/dockersudo tee /etc/docker/daemon.json <<-'EOF'{ "exec-opts": ["native.cgroupdriver=systemd"], "log-driver": "json-file", "log-opts": { "max-size": "100m" }, "storage-driver": "overlay2", "registry-mirrors": ["https://t9ab0rkd.mirror.aliyuncs.com"]}EOFsudo systemctl daemon-reloadsudo systemctl restart dockerStep3: 装置 Kubernetes 三件套: kubelet kubeadm kubectl(仅在master)
# 增加并信赖APT证书curl https://mirrors.aliyun.com/kubernetes/apt/doc/apt-key.gpg | sudo apt-key add -# 增加源地址add-apt-repository "deb https://mirrors.aliyun.com/kubernetes/apt/ kubernetes-xenial main"# 更新源并装置最新版 kubenetessudo apt update && apt install -y kubelet kubeadm kubectl# 增加 completion，最好放入 .bashrc 中source <(kubectl completion bash)source <(kubeadm completion bash)Step4: 敞开 swap（master和worker都要操作）
这里因为腾讯云主机是默认敞开 swap 的，如果是其余主机，则执行以下操作并重启机器:
$ vim /etc/fstab// 正文掉带有swap的一行# UUID=xxxxxxxxx none swap sw 0 0Step5: 启动 master（仅在master操作）
kubeadm init --image-repository='registry.cn-hangzhou.aliyuncs.com/google_containers'这里指定了镜像源为阿里云，所以可能防止从 k8s.gcr.io 这个官网默认源拉取时失败。执行胜利之后，会生成一串相似于如下格局的信息：
kubeadm join 172.16.0.15:6443 --token qi9srp.7sudphpyhmkm8sw6 \ --discovery-token-ca-cert-hash sha256:a30870d86f7d19aff4d57a2dd64d58736012dfa3b3d5b53c0e45413ba8f039bf 这串信息稍后会在退出worker节点的时候用到。
Step6: 配置读取门路（仅在master操作）
export KUBECONFIG=/etc/kubernetes/admin.confStep7：装置网络插件（仅在master操作）
kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d 'n')" Step8：将 worker 节点退出到集群（仅在worker 操作）
如果有保留在master节点执行 kubeadm init 生成的信息，即：
kubeadm join 172.16.0.15:6443 --token qi9srp.7sudphpyhmkm8sw6 \ --discovery-token-ca-cert-hash sha256:a30870d86f7d19aff4d57a2dd64d58736012dfa3b3d5b53c0e45413ba8f039bf 能够间接复制过去应用. 没有保留的话，--token 能够通过 kubeadm token list 获取；--discovery-tolen-ca-cert-hash 能够通过上面的命令获取:
openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | sha256sum | awk '{print $1}'Step9: 验证执行后果
2. 通过 yaml 文件部署前后端利用
因为服务计算的第九次作业开发了一个前后端拆散的应用程序，并打包成了 docker 镜像，所以正好能够利用搭建好的集群部署前后端利用。查阅了 Kubernetes 官网文档后，我决定别离为前后端服务配置一个 Deployment 类型的资源和 Service 类型的资源。Deployment 类型资源负责管理 pod 的生命周期，调整动静伸缩的尺度，Service 负责裸露 Deployment 所对应的容器的端口到公网，使得服务能够在集群内部被拜访。
上面介绍 yaml 文件的写法。
bbs_backend 的部署
Deployment
apiVersion: apps/v1kind: Deploymentmetadata: name: bbs-backendspec: selector: matchLabels: app: bbs-backend tier: backend track: stable replicas: 3 # 正本数 template: metadata: labels: app: bbs-backend tier: backend track: stable spec: containers: - name: bbs-backend image: "docker.io/bobbai/bbs_backend" # 这里pod要拉取的镜像 ports: - name: port containerPort: 5000 # 这里指定了基于镜像创立容器之后服务所在的端口Service
apiVersion: v1kind: Servicemetadata: name: bbs-backend-servicespec: selector: app: bbs_backend tier: backend ports: - protocol: "TCP" # 服务提供的协定 port: 5000 # service裸露在cluster ip上的端口，<cluster ip>:port 是提供给集群外部客户拜访service的入口。 targetPort: 5000 # targetPort是pod上的端口，从port和nodePort上到来的数据最终通过kube-proxy流入到后端pod的targetPort上进入容器 nodePort: 30086 # 裸露在公网的端口，服务能够通过 <master ip>:nodePort 拜访 type: NodePortbbs_frontend 的部署
这里yaml文件与后端部署所用到的相似，不再反复，间接上文件：
apiVersion: apps/v1kind: Deploymentmetadata: name: bbs-frontendspec: selector: matchLabels: app: bbs-frontend tier: frontend track: stable replicas: 3 template: metadata: labels: app: bbs-frontend tier: frontend track: stable spec: containers: - name: bbs-frontend image: "docker.io/bobbai/bbs_frontend:k8s" ports: - name: port containerPort: 3000---apiVersion: v1kind: Servicemetadata: name: bbs-frontend-servicespec: selector: app: bbs-frontend tier: frontend ports: - protocol: "TCP" port: 3000 targetPort: 3000 nodePort: 30087 type: NodePort执行：
kubectl apply -f bbs_backend -n bbskubectl apply -f bbs_frontend -n bbs后，能够通过 dashboard 查看服务是否部署胜利：
3. Gitlab 的 Helm 部署
Gitlab 是什么？Gitlab 是一个十分驰名的开源项目管理工具。除了具备治理进度，我的项目版本等基本功能之外，gitlab还附带有一个弱小的 CI/CD 零碎，这使得我的项目的自动化测试，部署变得非常不便。
为什么要是用 Helm 进行部署呢？依照官网文档提供的，应用 yaml 文件部署一个服务的话，失常来说须要编写 yaml 文件来申明相应的 Deployment, Service, PersistentVolumeClaim, PersistentVolume 等等资源。如果后续要对于资源的一些属性，比方 PersistentVolume 的挂载目录，卷的大小等等就会比拟麻烦。Helm 则提供了一种模版化的形式，将服务的属性提取到一个对立的文件中，而后只须要批改一次，就能在整个服务中失效，同时它也为Kubernetes 生态中的服务提供了包治理的性能，不便用户在本人的集群下疾速部署提供了 helm chart 的服务。
对于 Helm 的装置，能够参考官网文档，这里不再具体阐明.
(1) Gitlab 的 Helm 部署
step1: 增加 helm 源(在master执行)
helm repo add stable https://kubernetes-charts.storage.googleapis.comhelm repo add aliyun https://kubernetes.oss-cn-hangzhou.aliyuncs.com/chartshelm repo add apphub https://apphub.aliyuncs.com/step2: 下载 gitlab-ce 的 charts
helm pull stable/gitlab-ce// 目录下会生成一个 gitlab-ce-版本号的压缩包，通过tar命令解压即可tar -zxvf gitlab-ce-xxx.tgz解压后该当生成了一个名为 gitlab-ce 的目录
step3: 进入解压后的目录，并依据需要批改 values.yaml 文件
cd gitlab-cevim values.yaml
这几处须要咱们依据需要来批改，externalUrl 能够随便写，后续能够批改; 因为我并没有购买额定的load balancer 服务，所以想要裸露服务，只能应用 NodePort 类型。
step4：适配 1.19 集群（如果您的集群是1.16版本之前的，则这一步能够疏忽）
kubernetes 每个版本的yaml文件版本都有所不同，须要咱们依据本人集群的版本进行适配，即批改 helm/template 中的一些 yaml 文件。
- 批改1: vim gitlab-ce/templates/deployment.yaml
增加：
- 批改2: vim gitlab-ce/charts/postgresql/templates/deployment.yaml
增加：
- 批改3：vim gitlab-ce/charts/redis/templates/deployment.yaml
step5：创立 PersistentVolume
因为gitlab须要将 postgres, redis 的数据长久化，因而如果此时依据gitlab-ce的charts来创立服务，因为咱们并没有申明对应到gitlab自带的 PersistentVolumeClaim 对应的挂载目录下的 PersistentVolume, 服务就无奈失常启动。因而，咱们首先创立四个文件夹：
mkdir -p /data/gitlab/pv{1..4}而后创立4个申明pv的yaml文件，模版如下：
---apiVersion: v1kind: PersistentVolumemetadata: name: gitlab-pv1 namespace: gitlabspec: accessModes: - ReadWriteOnce capacity: storage: 10Gi hostPath: path: /data/gitlab/pv1 persistentVolumeReclaimPolicy: Retain volumeMode: Filesystem而后顺次 apply 这些 yaml 文件：
kubectl apply -f pv1.yamlkubectl apply -f pv2.yamlkubectl apply -f pv3.yamlkubectl apply -f pv4.yaml随后查看 pv 的状态
证实创立胜利
step6：创立服务
输出:
helm install gitlab gitlab-ce -n gitlab这里，-n 参数指定了服务的命名空间，您能够依据需要自行更改。
查看服务状态：
证实服务创立胜利，咱们拜访 http://master IP:32363
证实部署胜利。