gitlab流水线与k8s集群的联通

gitlab流水线与k8s集群的连接，首先是通过gitlab-ci.yml文件中的命令，通过runner执行器实例运行对应的kubectl命令实现的。

那么runner执行器实例执行器如何执行kubectl命令，执行环境的配置，kubectl命令如何与k8s集群互认，以及从git push到k8s集群的运行，都需要逐步进行配置并确定连通性。

这个流程应当是：

IDE->gitlab->gitlab runner->shell->docker+kubectl->k8s集群

1.runner与k8s的连接

我们安装gitlab runner肯定是为了构建自动化流水线的。现在考虑如何将自动化流水线与k8s相连接。

1.1 执行器实例机器kubectl安装

首先我在gitlab runner的runner实例的执行器（我选的shell）运行的位置安装kube，方便kubectl命令的执行。

下载。换google的官方源难以yum安装，尝试使用io提供的文件。

curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"

我是x86架构的centos7.4内核的系统，如上命令即可。如果是arm架构等其他情况，可以修改对应的位置。

下载后转移到自己的PATH下即可。一般放到/usr/local/bin/下就行。

为了保持学习的态度，我们可以通过echo $PATH命令查看自己系统的PATH有哪些。他会返回一系列用:结尾的字符串，这些就是你的PATH地址。

下一步，修改kubectl文件的可执行权限。

bash 复制代码

# 在kubectl存放的位置检查一下权限
ls -la kubectl
# 可以看到只有所有者有读写权限。考虑到中标麒麟的权限管理严格，我计划给所有用户执行权限。
sudo chmod 711 kubectl
# 更改完后查询权限
ls -la kubectl
# 可以看到执行权限被添加了

转移到bin下

bash 复制代码

sudo mv kubectl /usr/local/bin/

验证安装成功

bash 复制代码

kubectl version --client

#返回值为
Client Version: v1.34.0
Kustomize Version: v5.7.1

说明安装成功了

1.2 测试gitlab能否正常连接kubectl

我们操作k8s执行的整个链条为：

通过IDE在本地编辑gitlab-ci.yml文件。
文件指导gitlab，通过文件中的tag和gitlab中注册的runner实例tag匹配，选择gitlab runner特定执行器执行相关命令。
执行器选择使用shell
shell命令使用kubectl命令
kubectl按照IDE中编辑的deployment.yaml和service.yaml，将要执行的内容部署到K8S集群上

我需要确认gitlab-ci.yml能正常命令shell级别的kubectl能正常执行。既确认IDE到kubectl的连接。

首先修改gitlab-ci.yml内容为：

yaml 复制代码

stages:
  - build
  - deploy

variables:
  DOCKER_DRIVER: overlay2
  DOCKER_TLS_CERTDIR: ""

build:
  stage: build
  tags:
    - shell
  script:
    - docker --version

deploy:
  stage: deploy
  tags:
    - shell
  script:
    - kubectl version --client

之后进行commit和push。

之后前往gitlab->demo项目->构建->作业下查看build和deploy是否正常反馈。

build里会看到Job succeeded的字样：

复制代码

# 省略一大段
$ docker --version
Docker version 17.03.2-ce,
 build f5ec1e2
Job succeeded

deploy里也会看到：

复制代码

# 省略一大段
$ kubectl version --client
Client Version: v1.34.0
Kustomize Version: v5.7.1
Job succeeded

至此我可以确认IDE->gitlab->gitlab runner->shell->docker/kubectl是正常的。

1.3 将k8s集群与kubectl连接

在端口开通没有障碍的情况下，直接在k8s节点复制config文件到kubectl运行的位置是最方便的，命令如下：

bash 复制代码

# 在k8s主节点执行
scp /etc/kubernetes/admin.conf 目标机器用户名@IP地址:/etc/kubernetes/config

考虑到我这边开通机器到机器的权限比较麻烦，我选择手动复制。从k8s的master机器，或者通过kubephere手动拷贝config内容。

到了本地机器之后，在本地执行环境配置：

bash 复制代码

echo "export KUBECONFIG=/etc/kubernetes/config" >> ~/.bashrc
source ~/.bashrc

你的config文件存储位置/etc/kubernetes/config不是这个的话，记得进行修改。

测试一下能不能连接集群

复制代码

kubectl get nodes

执行上述命令你会发现，哎他通不了

1.4 集群和本级策略开通

基于内网环境，各种端口默认是不能通信的，那么需要调查确定需要开通哪些权限。

1.4.1 开通端口的确认

k8s集群的kubernetes API server服务监听端口需要确认。k8s默认监听6443端口，进行API server。

受限网络环境下，我申请到开通一个策略的时间代价是很长的，所以我倾向于先确认再后续操作。下面通过命令确认开通情况。

bash 复制代码

ps -ef | grep kube-apiserver | grep -E 'secure-port|bind-address'

正常情况你能在返回中看到--secure-port=6443

1.4.2 端口监听情况确认

查看端口监听情况是否正常

bash 复制代码

sudo netstat -tnlp | grep kube-apiserver

正常你会看到kube-apiserver监听：：：6443，就是监听的6443端口，看到：：：*，就是所有来源的都收。

1.4.3 开通策略

runner机器-》k8s master节点，需要开通all-〉6443

因为runner机器与k8s master节点通信的端口是随机的。所以这一侧应该是要开通all

1.5 为执行器指引配置文件位置

在gitlab-ci.yml中编辑一行variables

yml 复制代码

variables:          # 告诉 Runner kubeconfig 在哪
  KUBECONFIG: "<to your config flie path>/config"

具体位置改成你存放config文件的位置。

1.6 集成连通性测试

gitlab-ci.yml中编辑一行kubectl get nodes。

之后执行推送。

到gitlab流水线中查看deploy阶段情况。

能正常展示你的几个节点的列表那就是和k8s集群通常起来了。