該實踐來自于客戶的一個真實需求

1. 問題背景

• gitlab是基于混合架構部署
• gitlab沒有使用ingress
• gitlab的webservice的service類型為nodeport，然后通過lb來轉發(fā)實現(xiàn)，域名掛在lb上

關于 gitlab的webservice的service類型為nodeport 可以稍微展開一下，其實就是通過創(chuàng)建一個新的webservice的service yaml文件，然后修改該service的類型是 nodeport，這樣可避免后續(xù)通過helm upgrade 升級/更新 gitlab的時候，導致service又還原為配置中默認的ClusterIP或LoadBalancer而是的gitlab訪問出現(xiàn)問題。

2. 部署gitlab 17.5

在k8s集群中搭建gitlab17.5，不啟用ngix-ingress，同時將webservice的service類型使用nodeport的方式。

2.1 添加repo源

## 添加gitlab-jh源
helm repo add gitlab-jh https://charts.gitlab.cn
## 更新gitlab-jh源
helm repo update
## 查看gitlab-jh的charts包,包含了gitlab和gitlab-runner
helm search repo gitlab-jh -l

2.2 添加repo源 下載17.5.0的charts包

## 拉取對應版本的charts包
helm fetch gitlab-jh/gitlab --version 8.5.0
## 解壓
tar -xf gitlab-8.5.0.tgz
cd gitlab

2.3 修改values文件

2.3.1 hosts修改如下

• 添加gitlab的域名
• 禁用https
• 配置externalIP

  hosts:domain: bdeet.top # 添加域名...https: false # 禁用httpsexternalIP:- 43.133.36.192 #配置externalIP

2.3.2 appConfig修改如下

• 添加sidekiq的路由規(guī)則

  appConfig:sidekiq:routingRules:- ["feature_category=source_code_management","code"]- ["feature_category=integrations","integrations"]- ["feature_category=continuous_integration,continuous_delivery", "pipeline"]- ["feature_category=code_review","code_review"]- ["*", "default"]

2.3.3 gitlab下的sidekiq配置

• 添加sidekiq的隊列組

gitlab:sidekiq:concurrency: 25pods:- name: codequeues: code- name: integrationsqueues: integrations- name: pipelinequeues: pipeline- name: code-reviewqueues: code-review- name: default

2.3.4 certmanager修改如下

• installCRDs設置為false，不安裝
• install設置為false，不安裝

certmanager:installCRDs: false...install: false

2.3.5 nginx-ingress修改如下

• enabled設置false，不用自帶的nginx

nginx-ingress: &nginx-ingressenabled: falsetcpExternalConfig: "false"

2.3.6 <可選> prometheus修改如下

• install設置為false，不安裝

prometheus:install: false

2.3.7 <可選> runner配置

• 禁用runner，單獨部署

gitlab-runner:install: false

2.3.8 <可選> 數(shù)據(jù)庫連接數(shù)配置

• 調整數(shù)據(jù)庫的連接數(shù)

postgresql:install: true...primary:extendedConfiguration: |max_connections = 500

2.3.9 創(chuàng)建webservice新的service yaml

apiVersion: v1
kind: Service
metadata:labels:app: gitlab-shellname: gitlab-server-gitlab-shell-nodeportnamespace: gitlab
spec:internalTrafficPolicy: ClusteripFamilies:- IPv4ipFamilyPolicy: SingleStackports:- name: sshport: 22protocol: TCPtargetPort: 2222selector:app: gitlab-shelltype: NodePort
---
apiVersion: v1
kind: Service
metadata:labels:app: webservicename: gitlab-server-webservice-nodeportnamespace: gitlabspec:internalTrafficPolicy: ClusteripFamilies:- IPv4ipFamilyPolicy: SingleStackports:- name: http-workhorseport: 8181protocol: TCPtargetPort: http-workhorseselector:app: webservicetype: NodePort

2.3.10 騰訊云上配置lb，并配置后端轉發(fā)的服務

此處 負載均衡快速入門，將lb的22和80/443 映射到后端服務的2222和8181即可，域名可以直接掛在lb上。

2.4 部署gitlab

 helm upgrade --install gitlab gitlab-jh/gitlab --timeout 600s --set certmanager-issuer.email=wkx_0422@163.com  --version 8.5.0 -f values.yaml

2.4.1 查看密碼

kubectl get secret <name>-gitlab-initial-root-password -ojsonpath='{.data.password}' | base64 --decode ; echo

2.5 訪問gitlab

經過測試發(fā)現(xiàn)確實webservice的log中的remote ip都是nodeport的ip，已經和用戶的環(huán)境一致。

3. 解決

3.1 技術調研

關于 externalTrafficPolicy 的解釋，參考如下：

• https://kubernetes.io/zh-cn/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip
• https://www.cnblogs.com/zhangmingcheng/p/17637712.html

3.2 解決方案

將webservice的service類型為nodeport的yaml中的 externalTrafficPolicy: Cluster 改成 externalTrafficPolicy: Local 即可。

關于 externalTrafficPolicy 的策略說明

• Cluster 隱藏了客戶端源 IP，可能導致第二跳到另一個節(jié)點，但具有良好的整體負載分布。
• Local 保留客戶端源 IP 并避免 LoadBalancer 和 NodePort 類型服務的第二跳， 但存在潛在的不均衡流量傳播風險。

因此對 上面2.3.9的yaml文件修改如下（見紅色字體）：

apiVersion: v1
kind: Service
metadata:
labels:
app: gitlab-shell
name: gitlab-server-gitlab-shell-nodeport
namespace: gitlab
spec:
externalTrafficPolicy: Local
internalTrafficPolicy: Cluster
ipFamilies:

• IPv4
  ipFamilyPolicy: SingleStack
  ports:
• name: ssh
  port: 22
  protocol: TCP
  targetPort: 2222
  selector:
  app: gitlab-shell
  type: NodePort

---

apiVersion: v1
kind: Service
metadata:
labels:
app: webservice
name: gitlab-server-webservice-nodeport
namespace: gitlab
spec:
externalTrafficPolicy: Local
internalTrafficPolicy: Cluster
ipFamilies:

• IPv4
  ipFamilyPolicy: SingleStack
  ports:
• name: http-workhorse
  port: 8181
  protocol: TCP
  targetPort: http-workhorse
  selector:
  app: webservice
  type: NodePort

4. 驗證

4.1 gitlab 請求驗證

如下是本地ip

本地訪問gitlab，查看日志

4.2 runner 請求驗證

本地runner的IP

gitlab上跑一個流水線

綜上所述，在gitlab的日志中，客戶的端的請求都已經為真實的ip地址。

5. 思考

拋開gitlab本身，其實對于在k8s中部署的服務而言，如果走了ingress網絡是不存在這個問題，而恰恰是因為繞過了ingress，通過nodeport的方式產生了這個問題，而externalTrafficPolicy 恰恰是可以解決這樣的流量請求地址地址顯示的問題。