关于kubernetes:Kubernetes-119-国内镜像源部署部署前后端服务以及-Gitlab的helm部署

36次阅读

共计 5718 个字符,预计需要花费 15 分钟才能阅读完成。

本篇博客将具体介绍如何在云服务器上搭建 Kubernetes 1.19 集群,以及在咱们部署好的集群上应用 Helm 部署 gitlabminio 服务。

部署环境

  • 两台云服务器

    • 配置为:

      • 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 Aliyun
sudo usermod -aG docker $USER
sudo mkdir -p /etc/docker
sudo 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"]
}
EOF
sudo systemctl daemon-reload
sudo systemctl restart docker

Step3: 装置 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"

# 更新源并装置最新版 kubenetes
sudo 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       0

Step5: 启动 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.conf

Step7:装置网络插件(仅在 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/v1
kind: Deployment
metadata:
  name: bbs-backend
spec:
  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: v1
kind: Service
metadata:
  name: bbs-backend-service
spec:
  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: NodePort

bbs_frontend 的部署

这里 yaml 文件与后端部署所用到的相似,不再反复,间接上文件:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: bbs-frontend
spec:
  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: v1
kind: Service
metadata:
  name: bbs-frontend-service
spec:
  selector:
    app: bbs-frontend
    tier: frontend
  ports:
  - protocol: "TCP"
    port: 3000
    targetPort: 3000
    nodePort: 30087
  type: NodePort

执行:

kubectl apply -f bbs_backend -n bbs
kubectl 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.com
helm repo add aliyun https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts
helm 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-ce
vim 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: v1
kind: PersistentVolume
metadata:
  name: gitlab-pv1
  namespace: gitlab
spec:
  accessModes:
    - ReadWriteOnce
  capacity:
    storage: 10Gi
  hostPath:
    path: /data/gitlab/pv1
  persistentVolumeReclaimPolicy: Retain
  volumeMode: Filesystem

而后顺次 apply 这些 yaml 文件:

kubectl apply -f pv1.yaml
kubectl apply -f pv2.yaml
kubectl apply -f pv3.yaml
kubectl apply -f pv4.yaml

随后查看 pv 的状态

证实创立胜利

step6:创立服务

输出:

helm install gitlab gitlab-ce -n gitlab

这里,-n 参数指定了服务的命名空间,您能够依据需要自行更改。

查看服务状态:

证实服务创立胜利,咱们拜访 http://master IP:32363

证实部署胜利。

正文完
 0