关于 webservice 日志中 源IP是node IP的问题，是否能解决换成 真实的客户端IP呢

标签：node false webservice IP gitlab nodeport 2.3 name

本篇目录

• • 1. 问题背景
  • 2. 部署gitlab 17.5
  • • 2.1 添加repo源
    • 2.2 添加repo源 下载17.5.0的charts包
    • 2.3 修改values文件
    • • 2.3.1 hosts修改如下
      • 2.3.2 appConfig修改如下
      • 2.3.3 gitlab下的sidekiq配置
      • 2.3.4 certmanager修改如下
      • 2.3.5 nginx-ingress修改如下
      • 2.3.6 <可选> prometheus修改如下
      • 2.3.7 <可选> runner配置
      • 2.3.8 <可选> 数据库连接数配置
      • 2.3.9 创建webservice新的service yaml
      • 2.3.10 腾讯云上配置lb，并配置后端转发的服务
    • 2.4 部署gitlab
    • • 2.4.1 查看密码
    • 2.5 访问gitlab
  • 3. 解决
  • • 3.1 技术调研
    • 3.2 解决方案
  • 4. 验证
  • • 4.1 gitlab 请求验证
    • 4.2 runner 请求验证
  • 5. 思考

该实践来自于客户的一个真实需求

1. 问题背景

• gitlab是基于混合架构部署
• gitlab没有使用ingress
• gitlab的webservice的service类型为nodeport，然后通过lb来转发实现，域名挂在lb上

关于 gitlab的webservice的service类型为nodeport 可以稍微展开一下，其实就是通过创建一个新的webservice的service yaml文件，然后修改该service的类型是 nodeport，这样可避免后续通过helm upgrade 升级/更新 gitlab的时候，导致service又还原为配置中默认的ClusterIP或LoadBalancer而是的gitlab访问出现问题。

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 # 禁用https
    externalIP:
      - 43.133.36.192 #配置externalIP

2.3.2 appConfig修改如下

• 添加sidekiq的路由规则

  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: 25
    pods:
    - name: code
      queues: code
    - name: integrations
      queues: integrations
    - name: pipeline
      queues: pipeline
    - name: code-review
      queues: 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-ingress
  enabled: false
  tcpExternalConfig: "false"

2.3.6 <可选> prometheus修改如下

• install设置为false，不安装

prometheus:
  install: false

2.3.7 <可选> runner配置

• 禁用runner，单独部署

gitlab-runner:
  install: false

2.3.8 <可选> 数据库连接数配置

• 调整数据库的连接数

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

2.3.9 创建webservice新的service yaml

apiVersion: v1
kind: Service
metadata:
  labels:
    app: gitlab-shell
  name: gitlab-server-gitlab-shell-nodeport
  namespace: gitlab
spec:
  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:
  internalTrafficPolicy: Cluster
  ipFamilies:
  - IPv4
  ipFamilyPolicy: SingleStack
  ports:
  - name: http-workhorse
    port: 8181
    protocol: TCP
    targetPort: http-workhorse
  selector:
    app: webservice
  type: NodePort

2.3.10 腾讯云上配置lb，并配置后端转发的服务

此处 负载均衡快速入门，将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

经过测试发现确实webservice的log中的remote ip都是nodeport的ip，已经和用户的环境一致。

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，可能导致第二跳到另一个节点，但具有良好的整体负载分布。
• 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 恰恰是可以解决这样的流量请求地址地址显示的问题。

标签：node,false,webservice,IP,gitlab,nodeport,2.3,name
From： https://blog.csdn.net/weixin_44729138/article/details/144950724