一起来学k8s 40. kubernetes api操作

kubernetes api操作

kubectl 通过访问 Kubernetes API 来执行命令。我们也可以通过对应的TLS key和token, 使用curl 或是 golang client做同样的事。

API 请求必须使用 JSON 格式来发送。 kubectl 的作用是将 .yaml 转换为 JSON 格式进行 API 请求。

通过证书访问

我们从查看 kubectl 的配置文件开始,需要:三个证书和 API server 的地址:

[root@master01 ~]# kubectl config view
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://apiserver.k8s.local:8443
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    user: kubernetes-admin
  name: kubernetes-admin@kubernetes
current-context: kubernetes-admin@kubernetes
kind: Config
preferences: {}
users:
- name: kubernetes-admin
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED


[root@master01 ~]# cat /root/.kube/config 
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUN5RENDQWJDZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRJd01ERXdOekV5TURRek5sb1hEVE13TURFd05ERXlNRFF6Tmxvd0ZURVRNQkVHQTFVRQpBeE1LYTNWaVpYSnVaWFJsY3pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBTWllCkRVQ0N2enJwaXdCM2REcGhVK1BRRTFDVWFJVUQ4MG1UTjRSK1pyWHc4Qmc2WUxiQ1luN05IUExpZjNzU3owWTQKaHdWUkpJa3NaSWtzbVlGQ1lBUnIvQU5iZ0ZOZTFTRm9xaE5ZVlpHbnNGQjAzbEhzTnB2SHBKL1h3ZkZibldVcApZRlZvL0M2NEQzYmdmYTM4Q0M3LzJoRFhGMmFpd0syLzlnY2ZqMk91Z0w0UWNsU3VOclZCWlhLUkFyYkNMS3p3CkRuYmJ1bHByS2F2dXBaMnllL0JtN0ZaVjVtdFlJeXVhVXZtN1BaR0gvclo5UlduQzliSmRUbTNCWEtPZE9GajUKSEpoeHMwY0E2UXo0RGZZcEorWE5jYTJQRTFQZjZ3a1FUcHA1ZVBGcGo1aVljL1pkQUwwcW1BSzZYcjdWQ0lObgpZbFg1NFM1dzA0NEZsdlQ2MVVrQ0F3RUFBYU1qTUNFd0RnWURWUjBQQVFIL0JBUURBZ0trTUE4R0ExVWRFd0VCCi93UUZNQU1CQWY4d0RRWUpLb1pJaHZjTkFRRUxCUUFEZ2dFQkFKV2dQZy9BNk13eGxSQ2tkbG11TTlSd1MzaHEKNGJDeTQ1bUR4MGtMc21ESGFHakg3MWsyNGpJOGxjZDlzZU9rZ3JheWFpRFJEZ1piRTlXUmxldDE4TVovVkhuRApYSVFaZFRQVDZHaXNkelhnSGxIUWFRbmY3NDVnWVBiK2JhaUJvTjJENHJxbll2WXhVNUJQOTViT2ZwOGtHaHc2CkJ4YzZGYzV1Qzl6ZGRTRnZmUkpKUGs4NmszUHV1N05uMThWUHdDNHpFb1V2d0kyeUJ3Qlc5NmNCMlVBY3BxRHAKOGJWNGR6MTR2RFRPZ3p5UXpHQytWODU5eWR0ek84L1BxSGRRUmI0UktJVG9wNjc4dmZkWnpJTjRVN3dON1JwWQpQUFN1QjFvaGpkK21IRVE2cmRHcmdIYlNEODlsTTFSZG9VU05aaUNDZFQ4dlQ1NDlXVHJ3OWMzMXMzcz0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=
    server: https://apiserver.k8s.local:8443
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    user: kubernetes-admin
  name: kubernetes-admin@kubernetes
current-context: kubernetes-admin@kubernetes
kind: Config
preferences: {}
users:
- name: kubernetes-admin
  user:
    client-certificate-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUM4akNDQWRxZ0F3SUJBZ0lJSk9zeUlxZTgyL3N3RFFZSktvWklodmNOQVFFTEJRQXdGVEVUTUJFR0ExVUUKQXhNS2EzVmlaWEp1WlhSbGN6QWVGdzB5TURBeE1EY3hNakEwTXpaYUZ3MHlNVEF4TURZeE1qQTBNemhhTURReApGekFWQmdOVkJBb1REbk41YzNSbGJUcHRZWE4wWlhKek1Sa3dGd1lEVlFRREV4QnJkV0psY201bGRHVnpMV0ZrCmJXbHVNSUlCSWpBTkJna3Foa2lHOXcwQkFRRUZBQU9DQVE4QU1JSUJDZ0tDQVFFQXpnajFsZFMreXVrbEp0ekQKbXltN2k4MFMrdmRwWDA4TkR2T0lSVE15VEhNR293RmZuU3I0Y0w3Tm80S1F0VGtkR0E1YmxWZXBhMktseWtxMwpmS01kcUd6WlJSK3JxcGdQZzVOU1lBOVIxcUZWUlQzZCt3RDV1UEJHN3E3K0pJRUNGMnVhdlE2N2JLVUtQUXJWCjNWTitUa013dndxUFd0UHE3VDRHd3hDQUNxL0psUzBYVWdycExHL0NrMmd3NmFEcWtRSTlOT0Z1WktjL0lnR0MKSkpZaWNybmdlRnNPUUpOTmIxWEt0WnhFaDMydkdPVVlkWGxzb0ZDYUtuTnQ2TzY3Y0tyalEwWmNVeHRzM1BKYQpWTEtpVjlZbnBrK09TbkJZV3g4ZmNEQkp1SUo1dzRUYSsvMjdaQW9iN0JPdnZPWXllTUY3UWo1MVVHd2hMNGFTCjFjNFpJUUlEQVFBQm95Y3dKVEFPQmdOVkhROEJBZjhFQkFNQ0JhQXdFd1lEVlIwbEJBd3dDZ1lJS3dZQkJRVUgKQXdJd0RRWUpLb1pJaHZjTkFRRUxCUUFEZ2dFQkFJUStCYk1GVUoya3VucnBoYTBaMTNBVjF3SDMwdzFXdU12YQowR3RlUTBHdVNIdVZwcTRTREMxU2VDS0NFWE83ZXlkSnd6UXJibEJzUjVPUkdYUFE4Ly9DTjVOdEdnVk04cXZECmhEcW5rNlF6RG9LYzBvalU5Yk9ab0Q1QlRmdk5VQ0h3Nzc3SWhOWHFmYTVEUzF5MEduWk5YYmZGTDFpQldNdHIKbzhqZkZaekN2UDZ3RDdkZXFGZFJYZm1IR2I0cVhGZWNJMDZSR1dudHBmbzRoYjVYVy9Gd282bUhERjViTU51eQpoMGhMWVJCOW1QT3p6Wjh4ckVFQVk0RnJ5NVF6T2pkb3hGT0VFRk5lU2xwcVBMdjMranh3c0Jjc0RkWDI5Q2djCnh0NEZ3UXE0ZnA0MFVhcHhxdXAydWZwVVptbUtUZDNPbjNtZFN3NkF5dEdkN0U5UzFKVT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=
    client-key-data: LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFb2dJQkFBS0NBUUVBemdqMWxkUyt5dWtsSnR6RG15bTdpODBTK3ZkcFgwOE5Edk9JUlRNeVRITUdvd0ZmCm5TcjRjTDdObzRLUXRUa2RHQTVibFZlcGEyS2x5a3EzZktNZHFHelpSUitycXBnUGc1TlNZQTlSMXFGVlJUM2QKK3dENXVQQkc3cTcrSklFQ0YydWF2UTY3YktVS1BRclYzVk4rVGtNd3Z3cVBXdFBxN1Q0R3d4Q0FDcS9KbFMwWApVZ3JwTEcvQ2syZ3c2YURxa1FJOU5PRnVaS2MvSWdHQ0pKWWljcm5nZUZzT1FKTk5iMVhLdFp4RWgzMnZHT1VZCmRYbHNvRkNhS25OdDZPNjdjS3JqUTBaY1V4dHMzUEphVkxLaVY5WW5waytPU25CWVd4OGZjREJKdUlKNXc0VGEKKy8yN1pBb2I3Qk92dk9ZeWVNRjdRajUxVUd3aEw0YVMxYzRaSVFJREFRQUJBb0lCQUd6RnNCbTg2a2tua3ZTVQpZalE5Y1FUYWJHWFFUbklCd3V3Y3g5bDRzTnBKYzd5RTBoeWdmZTdQM0xLeEVJS01OMzdtdlpUM1pic0twbXBJCnpkdmdKWjB3Y2ZnYlF6N1o3bjdSUFJEM3BZWUJRSXBBb2p1TWhVb01sL1lVcnBsSS9uaXMxMUZ1UUthWDd2TFIKRUowN0loaGhRby9wSEV1Z1M0dWFUbW1YQVhJaDcyMzJUL1c1OWIzTVFocmNndmt4NkJ5ck85SGcvZ0kxWXZFUApPcFY4VXZoL1Y0bFd6cWU4eHVaVkUyYm5xSHJKN2prWUM4OGw4ZjdOWjNhTlFXVEZlQlZKa2ZiVG0reExpNityCmcxamRTZU96MmwzQUVmUEJFY3ZkV2Q0TVlFK0I2NmdVSDc3L3dJc21EMGtwSTViYko1bGxLMGREbndiNjNSTDgKMUpOYTl3MENnWUVBNGxoSG95UXcrb1ZMSWJVNEh0T0orU3BpQ0syd0M0VVZpTTdabCtPSXk4YUpGalRDcHk2agpMTjM2MVZWR3c3Q0lrOW1pV0I4UUMvbTl0VWdyMTRSWFo4Y3ZGelFQdmZ6dS81Ri84eFp4NWpFWlpxcFlTVTJ4Cnd4TDBTSzNrRVpwL1lXYUR6dHJmeVpWNlJleEJaOXpvNWZFR1lXaFRGSmZ1YmxDeEorR0M3RXNDZ1lFQTZRZDYKSGNQbHV2TTRYcXJzSzdRNUlib3VTU0kyUTFaSXZkaXJzQURoZVR3azg0dTJIZ1hGVDhJWDFDMUhzWnhuMmRiWgp4RTFRQnYyaXRETE1XMGdiRTFRNzlNZnBheWgxYlJuS1UzL3NGWXY3QkROQmZkdVU3Q0FJcEhieHBRb2sxMCtQCnhzalQ1ZTZmK2pzWmVmSEZjbzZxWGVIams3bXUzWFAvMXY1eTFNTUNnWUE4Rmw5K0tiOXU0aS9kMVBQL0N2MVgKemk2VVN6ZXU5emVPU0F0dnpSR2x0eUR4YWpRNm1hRHI2a29LbEViaThGeHhrNWNMZWNPU3lrdlljajVoU2xyQgp6Qmp1T2YzcjI5ZSt0T3VZcHQ2NTAxTUE5RHZYeWU1azhRVTB2aVVMbjA0dGx6OXFqS1JZS1h4NlQ0dlZmTW0vCk1Vc1dWTkdwWitQK0dTSE9pb2x0SFFLQmdDTmtzVldJQllLSm9vd3VaY1NWa1AvZ2FWdE9TUE9kVFZzWVo2dEoKMXZVMC8xL0dYcGpjdzRWRHM1N1VhY2srT2ovSjlEVnVrTE1mSH
<think>好的,用户现在想了解nginx ingress中的两个注解:`nginx.ingress.kubernetes.io/rewrite-target`和`nginx.ingress.kubernetes.io/configuration-snippet`的具体含义及用法。我需要根据用户提供的引用内容来整理答案,同时参考之前的回答结构,确保内容清晰准确。 首先,先看看用户提供的引用资料。引用[2]提到ingress-nginx可以通过annotations配置高级功能,比如URL重写,类似nginx的proxy_pass。引用[4]和[5]具体展示了rewrite的使用示例,比如路径的重写规则,这可能和`rewrite-target`有关。引用[3]和[5]提到了使用configuration-snippet来插入自定义的nginx配置片段。 接下来,我需要明确这两个注解的作用: 1. **rewrite-target**:主要用于路径重写,当用户请求的路径需要被重定向到后端服务不同的路径时使用。例如,把`/app/`开头的请求重写到后端服务的根路径。这在引用[2]中的例子类似,用户可能需要将带前缀的请求转发到后端的不同路径。 2. **configuration-snippet**:允许插入自定义的nginx配置,比如添加特定的头信息、设置超时等高级配置。引用[3]中的modsecurity配置和引用[5]中的重写示例都属于这一类。 需要注意的是,用户可能在使用这些注解时遇到问题,比如路径匹配是否正确,或者配置片段是否生效。需要给出具体的示例,帮助用户理解如何编写这些注解。同时,要提醒用户注意版本兼容性,比如某些注解可能在特定版本的ingress-nginx中才能使用,比如引用[3]提到nginx 0.25.0及以上版本使用modsecurity-snippet,这可能与configuration-snippet的使用类似。 另外,用户之前的回答中提到了蓝绿发布和灰度发布,虽然当前问题不直接相关,但可能需要确保回答结构清晰,分点说明,并给出实际用例。例如,在解释每个注解时,可以结合具体的使用场景,比如在灰度发布中如何利用rewrite-target来调整路径,或者在配置安全策略时使用configuration-snippet插入modsecurity规则。 还需要注意用户提供的引用中的示例,例如引用[4]中的Ingress对象示例,展示了基本的annotations配置,而引用[5]中的重写规则示例,可以整合到`rewrite-target`的解释中。同时,引用[2]提到的URL Rewrite功能,需要与`rewrite-target`关联起来,说明如何通过该注解实现类似nginx的proxy_pass功能。 可能用户在使用这些注解时,会遇到路径处理的问题,比如是否需要保留原始路径,或者如何正确使用正则表达式。因此,在回答中需要详细说明路径匹配的规则,以及如何正确编写正则表达式来捕获和替换路径部分。 此外,用户可能需要了解这两个注解的区别:`rewrite-target`是专门用于路径重写的,而`configuration-snippet`更灵活,可以插入任意nginx配置,但需要用户熟悉nginx语法。需要提醒用户在使用configuration-snippet时谨慎,避免配置错误导致服务异常。 总结回答结构: 1. 分别介绍两个注解,说明其作用和使用场景。 2. 给出具体配置示例,结合用户提供的引用内容。 3. 指出使用时的注意事项,如路径匹配、版本兼容性、配置验证等。 4. 可能的相关问题,引导用户进一步习。 需要确保回答符合用户要求的格式,使用中文,正确使用LaTeX格式,并且引用标记正确。同时,根据用户提供的引用资料,尽可能多地整合相关信息,确保回答的准确性和实用性。</think>### 关于`nginx.ingress.kubernetes.io/rewrite-target`与`nginx.ingress.kubernetes.io/configuration-snippet`的深度解析 --- #### 一、`rewrite-target`:路径重定向核心工具 ##### 1. **核心作用** 用于将客户端请求路径**动态映射到后端服务的不同路径**,实现URL路径的透明化改写。其行为等价于Nginx的`proxy_pass`与`rewrite`指令的组合功能[^2]。 ##### 2. **语法规则** - 通过正则表达式**捕获路径片段**(使用`(.*)`或命名捕获组),并在`rewrite-target`中引用(`$1`或`$2`) - 路径匹配基于`path`字段定义的正则表达式 ##### 3. **典型场景** - 前端代理统一前缀(如将`/api/v1/`重定向到后端服务的根路径`/`) - 多版本API路由(如`/v2/service`映射到后端`/service`) ##### 4. **配置示例** ```yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: nginx.ingress.kubernetes.io/rewrite-target: /$1 # 将捕获的路径段保留 spec: rules: - host: app.example.com http: paths: - path: /svc/(.*) # 匹配所有以/svc/开头的请求 pathType: Prefix backend: service: name: backend-svc port: number: 80 ``` **效果**: 请求`app.example.com/svc/user` → 实际代理到`backend-svc`的`/user`路径[^4] ##### 5. **高级用法** - **多级路径保留**: `path: /gateway/(.*)/(.*)` + `rewrite-target: /$1/$2` - **静态路径拼接**: `rewrite-target: /v2/$1`(强制添加版本前缀) --- #### 二、`configuration-snippet`:原生Nginx配置注入 ##### 1. **核心作用** 允许直接向Nginx的`location`块内**插入自定义配置片段**,实现精细化控制,适用于标准Annotation无法覆盖的场景[^3]。 ##### 2. **典型场景** - 添加自定义HTTP头(如`proxy_set_header X-Env "prod"`) - 调整超时参数(如`proxy_connect_timeout 10s`) - 注入安全策略(如ModSecurity规则) - 实现复杂重写逻辑(需结合`rewrite`指令) ##### 3. **配置示例** ```yaml metadata: annotations: nginx.ingress.kubernetes.io/configuration-snippet: | proxy_set_header X-Real-IP $remote_addr; proxy_connect_timeout 15; if ($request_uri ~* "/legacy/(.*)") { rewrite ^/legacy/(.*) /old/$1 break; } ``` **效果**: - 添加客户端真实IP头 - 设置连接超时为15秒 - 将`/legacy/`路径请求重定向到`/old/`路径[^5] ##### 4. **安全注意事项** - **谨慎使用条件判断**:`if`指令可能导致不可预期的性能损耗[^1] - **避免冲突配置**:注入内容需与Ingress生成的标准配置兼容 - **版本兼容性**:部分指令需特定Ingress版本支持(如ModSecurity需≥0.25.0)[^3] --- #### 三、联合使用案例:灰度发布中的路径适配 ```yaml # 灰度环境Ingress配置 apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: nginx.ingress.kubernetes.io/canary: "true" nginx.ingress.kubernetes.io/canary-weight: "20" nginx.ingress.kubernetes.io/rewrite-target: /experiment/$1 nginx.ingress.kubernetes.io/configuration-snippet: | proxy_set_header X-Canary true; add_header X-Test-Phase "A/B"; ``` **功能说明**: - 20%流量导向灰度环境 - 请求路径自动添加`/experiment`前缀 - 注入灰度标识头供后端识别 --- ### 关键对比表 | **特性** | `rewrite-target` | `configuration-snippet` | |-------------------------|------------------------------------------|--------------------------------------| | **主要用途** | 路径重定向 | 注入任意Nginx配置 | | **配置复杂度** | 低(声明式配置) | 高(需熟悉Nginx语法) | | **典型应用场景** | 统一入口路径、版本路由 | 自定义头、超时调整、复杂逻辑实现 | | **风险等级** | 低 | 高(可能破坏已有配置) | | **与K8s声明式兼容性** | 完全兼容 | 需人工验证配置正确性 | --- ### 注意事项 1. **路径捕获陷阱**: 使用`(.*)`时需注意贪婪匹配特性,建议非贪婪匹配`(.*?)`处理多层路径 $$ \text{贪婪匹配示例:}/app/(.*)/detail \rightarrow /service/$1 $$ 2. **配置优先级**: `configuration-snippet`注入的内容会覆盖Ingress自动生成的配置 3. **调试工具**: 通过`kubectl exec`进入Nginx Pod查看完整配置: ```bash kubectl exec -n ingress-nginx <pod-name> -- cat /etc/nginx/nginx.conf ``` --- ### 相关问题 1. 如何通过`rewrite-target`实现多级子路径的精准匹配? 2. 使用`configuration-snippet`注入ModSecurity规则时需要注意哪些安全边界? 3. 在Canary Ingress中如何协调`rewrite-target`与主Ingress的路径映射关系?
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值