讓外部的開發機直接訪問Kubernetes群集內的服務！

1.場景

容器化+K8s編排已經是現在進行時把網站的多個項目設計為雲原生（Cloud Native）或老項改造為雲原生可以獲得諸多能力例如無雲綁定、彈性、部署環境一致性、微服務、DevOps、持續交付同時下一代微服務框架服務網格（ServiceMesh）也能無痛接入

博主現有項目后端開發語言為 PHP、GolangGolang做一些基礎公共服務（短信、消息、搜索等）這些公共服務化的項目已經容器化PHP的項目做應用邏輯層，會調用Golang寫的一些公共基礎服務PHP項目中直接通過服務名調用服務

需求： PHP項目A 依賴短信、消息、搜索這3個服務，開發人員無需在本機啟動依賴的服務，通過服務直接名透明的調用開發環境dev下的服務，開發人員只需要關注PHP項目A的開發。

☆本文的方案完成了開發人員開發機透明的直接訪問K8s服務，從而滿足了本需求☆

需要開發機透明訪的直接問Kubernetes群集內的服務本文講的方案都適用

開發機直接訪問Kubernetes群集內的服務示意圖

2.基本信息和完成的目標

2.1基本信息

開發辦公內網 192.168.1.0/24開發機2 192.168.1.2

運行K8s群集的Node網絡 10.2.0.0/16Node1 10.2.1.4Node2 10.2.1.8K8s 群集網絡 10.3.0.0/16

部署deployment whoami服務用於測試命名空間 default （這里可以用命名空間來區分環境例如dev為開發環境）鏡像 wwek/whoami服務名 whoami

Pod ip10.3.0.8在node1 10.2.1.410.3.0.70在node2 10.2.1.8

2.3完成的目標

開發機2 192.168.1.2 可以直接訪問 whoami服務也就是可以直接 curl http://whomai 就可以訪問服務本目標即完成需求

3.網絡互通1 開發辦公內網 <==> 公有雲VPC（私有雲內網）基礎互通

開發辦公內網和公有雲VPC、私有雲內網網絡互通

和公有雲互通的方案公有雲VPN專線（SDWAN）

私有雲互通就不多講了，很多公司內網的K8s開發測試群集和開發網絡本身就是互通的

各家網絡情況各有各的不同，相同的是這些有用的Tips無論是在公有雲VPC、私有雲、K8s群集非常關鍵的一點，子網網段不要沖突不要沖突、子網網段不要沖突、子網網段不要沖突做基礎互通的時候善用公有雲的VPC和路由配置功能甚至你可以不用買公有雲自帶的VPN網關服務，直接配合VPC路由表用一台VM充當路由器網關、VPN網關開發測試環境下用zerotier來打通各個內網性價比極高

最終要完成是開發辦公內網和公有雲VPC（私有雲內網）基礎互通

4.網絡互通2 開發辦公內網 <==> K8s群集內部Pod和Service網絡

☆☆☆ K8s Node本身是直接可以訪問K8s群集內部Pod網絡的！☆☆☆在Node1上用ping/curl測試 whoami服務分布在2個Node的2個Pod可以看到，whoami的2個pod ip都能ping通，用curl測試也能訪問到

通過Edge Node互通K8s群集和開發辦公之間的網絡那么用Node1作為開發辦公內網和 K8s群集內部網絡的“連接”點我們把這個Node1節點叫做邊緣節點(Edge Node)邊緣節點(Edge Node)可以在運行K8s群集中Node中隨便選一個這里選擇Node1，他的網卡信息如下eth0 vm網卡 ip 10.2.1.4cbr0 K8s群集創建的網卡 ip 10.3.0.1

可以有2種方式方式1 在 Edge Node eth0 上啟用NAT 這樣其他的子網的訪問在K8s群集中看到的IP是 10.2.1.4方式2 K8s群集子網和開發辦公內網完全對等互通（公有雲VPC路由表、開發辦公網絡路由表配合做）

完成后開發辦公網絡中在開發機2 192.168.1.2 ping/curl K8s群集中的pod ip可ping/curl 屬於whoami的2個Pod ip

㊗️網絡搞通了，那么再解決DNS解析的問題就可以了

5.打通K8s群集中的DNS （開發辦公內網的DNS，設置K8s中KubeDns為上游DNS）

在Edge Node1上可以直接訪問到KubeDns

kubectl get svc -n kube-system
#kube-dns ip 10.3.254.107復制代碼

那么在Edge Node1上面裝一個DNS Server做個中間轉發（使用CoreDNS）開發網絡中的電腦無法直接使用kube-dns，非Edge Node解析結果為空所以需要在Edge Node1上轉一個 DNS Server 做一個ProxyCoreDNS的安裝使用參考我的另外一篇文章使用CoreDNS作為你的內網DNS服務器可用CoreDNS配置文件參考/etc/coredns/Corefile

# kubernetes設置
cluster.local:53 {
  # kube-dns
  forward . 10.3.254.107:53
  log
  errors
  #debug
}

# 默認設置
.:53 {
  # 先走本機的hosts
  # https://coredns.io/plugins/hosts/
  hosts {
    # 自定義sms.service search.service 的解析
    # 因為解析的域名少我們這里直接用hosts插件即可完成需求
    # 如果有大量自定義域名解析那么建議用file插件使用 符合RFC 1035規范的DNS解析配置文件
    #10.6.6.2 servicename
    # ttl
    ttl 60
    # 重載hosts配置
    reload 1m
    # 繼續執行
    fallthrough
  }

  # file enables serving zone data from an RFC 1035-style master file.
  # https://coredns.io/plugins/file/
  # file service.signed service
  # 最后所有的都轉發到系統配置的上游dns服務器去解析
  forward . /etc/resolv.conf

  # 緩存時間ttl  s
  #cache 6
  # 自動重新加載配置文件的間隔時間
  reload 6s
  # 輸出日志
  log
  # 輸出錯誤
  errors
  #debug
}復制代碼

啟動CoreDNS

dig @10.2.1.4 whoami.default.svc.cluster.local
# 測試下確保可以解析復制代碼

在開發機2配置DNS為 Edge Node1 IP 10.2.1.4配置搜索域為 default.svc.cluster.local

這個2個配置可以在開發辦公網絡中的DHCP服務器上統一配置

來測試下DNS解析 curl訪問

6.關鍵實現總結

網絡互通1 開發辦公內網 <==> 公有雲VPC（私有雲內網）基礎互通
網絡互通2 開發辦公內網 <==> K8s群集內部Pod和Service網絡（通過Edge Node）
打通K8s群集中的DNS （開發辦公內網的DNS，設置K8s中KubeDns為上游DNS）
開發機DNS配置 Edge Node DNS 和搜索域設置default.svc.cluster.local

7.QA

問1：這也太復雜了吧，有沒有簡單點的？答：解決的目標不同

如果只是單純的能訪問k8s中的服務有以下的方式訪問K8s中的服務還有這些方式telepresence （快速，本地開發面向k8s的微服務）K8s中裝個openvpn 撥入群集內網絡K8s自帶的服務暴露方式 NodePort Ingress

這些方法在一個應用有多個服務依賴的時候無法做到讓所有開發人員透明的直接通過服務名調用

為了做到對多個開發人員透明，所有人都不需要安裝項目依賴的服務，只需要運行項目本身，本項目透明的調用依賴的服務。所以才有了本文的“復雜”方案

問2：這樣直通了暴露K8s群集后豈不是不安全？答：是的，但是可以解決，我是這么解決的K8s群集分為線上和線下實現了隔離線上為准生產、生產，線下為開發、測試k8s中可以用命名空間（namespace）來做環境的區分dev、testing、staging、prod

問題3：開發機中DNS用K8s的DNS作為上游后網站的CDN亂解析了！答：開發辦公網絡和公有雲的網絡運營商和地理位置都不同，也就是如果網絡出口不一樣這會導致CDN解析的IP是錯的

需要在開發辦公網絡也部署一個DNS Server成為二級DNS開發辦公網絡開發機設置DNS為這個二級DNScluster.local轉發到 Edge Node DNS上其他的走本地默認的DNS同樣采用CoreDNS，配置文件參考

cluster.local:53 {
  # Edge Node DNS
  forward . 10.2.1.4:53
  log
  errors
  #debug
}
.:53 {
   ....
}復制代碼

私有雲或者自己在開發辦公網絡部署的K8s群集，因為是同一個網絡出口那么網站的DNS解析應該不會有問題

流水理魚發布！