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地址。
2. 下一步，修改kubectl文件的可执行权限。
# 在kubectl存放的位置检查一下权限
ls -la kubectl
# 可以看到只有所有者有读写权限。考虑到中标麒麟的权限管理严格，我计划给所有用户执行权限。
sudo chmod 711 kubectl
# 更改完后查询权限
ls -la kubectl
# 可以看到执行权限被添加了
- 转移到bin下
sudo mv kubectl /usr/local/bin/
- 验证安装成功
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内容为：
stages:- build- deployvariables:DOCKER_DRIVER: overlay2DOCKER_TLS_CERTDIR: ""build:stage: buildtags:- shellscript:- docker --versiondeploy:stage: deploytags:- shellscript:- 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运行的位置是最方便的，命令如下：
# 在k8s主节点执行
scp /etc/kubernetes/admin.conf 目标机器用户名@IP地址:/etc/kubernetes/config
考虑到我这边开通机器到机器的权限比较麻烦，我选择手动复制。从k8s的master机器，或者通过kubephere手动拷贝config内容。
到了本地机器之后，在本地执行环境配置：
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。
受限网络环境下，我申请到开通一个策略的时间代价是很长的，所以我倾向于先确认再后续操作。下面通过命令确认开通情况。
ps -ef | grep kube-apiserver | grep -E 'secure-port|bind-address'
正常情况你能在返回中看到–secure-port=6443
1.4.2 端口监听情况确认
查看端口监听情况是否正常
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
variables: # 告诉 Runner kubeconfig 在哪KUBECONFIG: "<to your config flie path>/config"
具体位置改成你存放config文件的位置。
1.6 集成连通性测试
gitlab-ci.yml中编辑一行kubectl get nodes。
之后执行推送。
到gitlab流水线中查看deploy阶段情况。
能正常展示你的几个节点的列表那就是和k8s集群通常起来了。