一、gitlab介绍

1.gitlab简介

Gitlab是一个开源分布式版本控制系统,由Ruby开发,有管理项目源代码、版本控制、代码复用与查找等功能。

2.gitlab的特点

1. 开源免费,社区免费版本适合中小型公司;

2. 差异化的版本管理,离线同步以及强大分支管理功能;

3. 便捷的GUI操作界面以及强大账户权限管理功能;

4. 集成度很高,能够集成绝大多数的开发工具;

3.github和gitlab区别

github是分布式在线代码托管仓库,个人版本可直接在线免费使用,企业版本收费且需要服务器安装。

gitlab是分布式在线代码仓库托管软件,分社区免费版本与企业收费版本,都需要服务器安装。

二、检查本地k8s集群状态

[root@k8s-master gitlab]# kubectl get nodes -owide

NAME         STATUS   ROLES                  AGE     VERSION   INTERNAL-IP     EXTERNAL-IP   OS-IMAGE                KERNEL-VERSION          CONTAINER-RUNTIME

k8s-master   Ready    control-plane,master   4d16h   v1.23.1   192.168.3.201   <none>        CentOS Linux 7 (Core)   3.10.0-957.el7.x86_64   containerd://1.6.6

k8s-node01   Ready    <none>                 4d16h   v1.23.1   192.168.3.202   <none>        CentOS Linux 7 (Core)   3.10.0-957.el7.x86_64   containerd://1.6.6

k8s-node02   Ready    <none>                 4d16h   v1.23.1   192.168.3.203   <none>        CentOS Linux 7 (Core)   3.10.0-957.el7.x86_64   containerd://1.6.6

三、配置并启动rpccbind和nfs-kernel-server服务

NFS文件系统仅占用系统挂载点。

NFS服务器设定好分享的目录/home/k8s-nfs/,其他客服端就可以将这个目录挂载到自己系统上的挂载点上,/home/k8s-nfs/就像自己的一个分区,但不占用自己的磁盘空间。

虽然NFS有自己的协议及端口号,但是在传送数据或其他相关信息时,NFS使用的是远程过程调用(Remote Procedure Call,RPC)协议来协助NFS本身的运作。

NFS服务器需要启用至少两个后台进程,rpc.nfsd 这个后台进程主要的功能是管理客户机是否有登入主机的权利,其中还包含对这个登入者ID的判断。rcp.mountd的功能是管理NFS的文件系统,当客服机端顺利通过rpc.nfsd登入主机后,在使用nfs服务器提供的文件之前,还需要经过文件使用权限的认证。系统会读取NFS的配置文件/etc/exports来对比客户机的权限,通过检测后,客服机就可以取得使用NFS文件的权限。

Ubuntu服务器端是nfs-kernel-server。

NFS的安装只需要安装rpcbind与nfs-server就可以对外提供服务了。

为了使NFS服务器能正常工作,需要启动rpcbind和nfs-kernel-server两个服务,并且rpcbind一定要先于nfs-kernel-server启动。

1. 配置并启动rpccbind和nfs-kernel-server服务

sudo service rpcbind start

sudo service nfs-kernel-server start

若要开机自启动nfs服务,可以通过sysv-rc-conf配置自启动服务。

apt-get install sysv-rc-conf

sudo sysv-rc-conf --level 35 rpcbind on

sudo sysv-rc-conf --level 35 nfs-kernel-server on

2.创建共享目录

nfs服务器创建共享目录,部署的gitlib使用共享目录来进行持久化,这样不管在哪个节点运行gitlib都没有关系。

# mkdir -p /home/k8s-nfs/gitlab/config

# mkdir -p /home/k8s-nfs/gitlab/logs

# mkdir -p /home/k8s-nfs/gitlab/data

3.配置共享目录

vim /etc/exports

/home/k8s-nfs/gitlab/config *(insecure,rw,sync,no_root_squash,subtree_check)

/home/k8s-nfs/gitlab/logs *(insecure,rw,sync,no_root_squash,subtree_check)

/home/k8s-nfs/gitlab/data *(insecure,rw,sync,no_root_squash,subtree_check)

4.使配置生效

# exportfs -r

远程共享挂载需要开通四个端口,可以正常挂载了。

tcp 111 2049 端口

udp 111 4046 端口

NFS客户端的挂载:

客户端的挂载很简单,先建立一个挂载目录

# mkdir -p /home/k8s-nfs

手动挂载至本地/home/k8s-nfs/目录

sudo mount -t nfs 172.17.131.4:/home/k8s-nfs/ /home/k8s-nfs

之后客户端对应的文件目录便挂载上对应的文件系统了。

自动挂载(生产环境不建议自动挂载,如果服务器异常会导致客户端启动不起来)

vim /etc/fstab

172.17.131.4:/home/k8s-nfs    /home/k8s-nfs nfs rw,netdev 0 0

原因分析:

Linux内核启动的流程中,网络的启动是在本机文件系统挂载之后,所以直接利用 /etc/fstab 尝试挂载 NFS 时,系统由于尚未启动网络,是无法挂载成功的。

2. 部署gitlib

2.1 准备部署文件(gitlib-deploy.yaml

#cat gitlab-deploy.yaml

apiVersion: v1

kind: Service

metadata:

  name: gitlab

spec:

  type: NodePort

  ports:

  # Port上的映射端口

  - port: 443

    targetPort: 443

    nodePort: 31443

    name: gitlab443

  - port: 80

    nodePort: 31080

    targetPort: 80

    name: gitlab80

  - port: 22

    targetPort: 22

    name: gitlab22

  selector:

    app: gitlab

---

apiVersion: apps/v1

kind: Deployment

metadata:

  name: gitlab

spec:

  selector:

    matchLabels:

      app: gitlab

  revisionHistoryLimit: 2

  template:

    metadata:

      labels:

        app: gitlab

    spec:

      containers:

      # 应用的镜像

      - image: gitlab/gitlab-ce

        name: gitlab

        imagePullPolicy: IfNotPresent

        # 应用的内部端口

        ports:

        - containerPort: 443

          name: gitlab443

        - containerPort: 80

          name: gitlab80

        - containerPort: 22

          name: gitlab22

        volumeMounts:

       # gitlab持久化

        - name: gitlab-persistent-config

          mountPath: /etc/gitlab

        - name: gitlab-persistent-logs

          mountPath: /var/log/gitlab

        - name: gitlab-persistent-data

          mountPath: /var/opt/gitlab

      imagePullSecrets:

      - name: devops-repo

      volumes:

      # 使用nfs互联网存储

      - name: gitlab-persistent-config

        nfs:

          server: 172.17.131.4

          path: /home/k8s-nfs/gitlab/config

      - name: gitlab-persistent-logs

        nfs:

          server: 172.17.131.4

          path: /home/k8s-nfs/gitlab/logs

      - name: gitlab-persistent-data

        nfs:

          server: 172.17.131.4

          path: /home/k8s-nfs/gitlab/data

2.2 执行部署

# kubectl apply -f gitlib-deploy.yaml

2.3 查看部署结果

# kubectl get deploy

NAME     READY   UP-TO-DATE   AVAILABLE   AGE

gitlab   1/1     1            1           15m

以上说明部署完成。

3. gitlib初始化

3.1 访问登录页面

通过查看service映射的端口:

# kubectl get svc -o wide

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR

Gitlab NodePort 10.104.247.91 <none>        443:31443/TCP,80:31080/TCP,22:31697/TCP   16m   app=gitlab

可以看到映射80端口的节点端口为:31080

通过制定端口访问登录页:

3.2 初始用户名和密码

初始用户名为root,初始密码gitlib自动创建,在如下文件中:

cat /home/k8s-nfs/gitlab/config/initial_root_password

拷贝密码进行登录。文件内容类似:

# WARNING: This value is valid only in the following conditions

#          1. If provided manually (either via `GITLAB_ROOT_PASSWORD` environment variable or via `gitlab_rails['initial_root_password']` setting in `gitlab.rb`, it was provided before database was seeded for the first time (usually, the first reconfigure run).

#          2. Password hasn't been changed manually, either via UI or via command line.

#

#          If the password shown here doesn't work, you must reset the admin password following https://docs.gitlab.com/ee/security/reset_user_password.html#reset-your-root-password.

Password: +uzp6caehgB3CJtz9ZojA+zRcMMIbFr2ik8eyyM9lT8=

# NOTE: This file will be automatically deleted in the first reconfigure run after 24 hours.

问题描述:在单机版k8s上部署应用后,发现Pod的状态一直处于pending状态,

于是 kubectl describe pods 查看了下发现:
Events:
  Type     Reason            Age   From               Message
  ----     ------            ----  ----               -------
  Warning  FailedScheduling  10m   default-scheduler  0/1 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate.
  
  意思是   1个节点有pod不能容忍的污点{node-role.kubernetes.io/master:}。

原因:当创建单机版的 k8s 时,这个时候 master 节点是默认不允许调度 pod 。

解决:执行命令:

# kubectl taint nodes --all node-role.kubernetes.io/master-

将 master 标记为可调度即可

Logo

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐