k8s相关知识整理

查看某个pod的信息
kubectl -n ${namespace} describe pod ${podName}
查看pods详细信息
kubectl get pods -n namespace -o wide
#kubectl patch:使用补丁修改、更新某个资源的字段,比如更新某个node
kubectl patch node/node-0 -p ‘{“spec”:{“unschedulable”:true}}’
kubectl logs查最后10条最新日志命令
kubectl logs --tail=10 kube-proxy-2dfdf5 -n kube-system
kubectl logs -f kube-proxy-2dfdf5 -n kube-system
进入POD内部
kubectl exec -it change-1124521512-pmnls /bin/bash
查看集群健康状态

kubectl get cs
kubectl cluster-info 查看集群信息
kubectl version 显示命令行和kube服务端的版本
kubectl api-versions 显示支持的api版本集合
kubectl config view 显示当前kubectl的配置信息

k8s 组件
组成:
Master节点:
kubectl:客户端命令行工具,作为整个系统的操作入口。
kube-apiserver:以 REST API 服务形式提供接口,作为整个系统的控制入口。接收命令并保存etcd
kube-controller-manager:控制器,包括deployment、sts控制器等。负责维护集群的状态并执行整个系统的后台任务
kube-scheduler:负责资源的调度,接收来自 kube-apiserver 创建 Pods 任务,并分配到某个节点。
etcd:负责节点间的服务发现和配置共享。
Node节点:
kube-proxy:运行在每个计算节点上,负责 Pod 网络代理。定时从 etcd 获取到 service 信息来做相应的策略。
kubelet:运行在每个计算节点上,作为 node上的代理agent,接收分配该节点的 Pods 任务及管理容器,周期性获取容器状态,反馈给 kube-apiserver。
dns:负责为整个集群提供dns服务
ingress dashboard flannel(集群间的网络)
创建pod过程
k8s网络
Pod 到 Pod(同一节点)
通信流程:
Pod A(10.244.1.2)要发送数据包给同节点的 Pod B(10.244.1.3)。
数据包从 Pod A 的 eth0 出来,通过虚拟以太网线(网线 一头连接pod一头连接网桥)到达网桥

网桥发现目标 Pod B 也连接在自己身上,于是直接将数据包转发给 Pod B 对应的虚拟网络设备。

数据包到达 Pod B 的 eth0。

不同节点的pod通信:
1.Pod A 的 eth0 网卡将数据包发送给其默认网关,通过网络插件cni(如 Flannel Calico)建立隧道或者路由转发到目标节点

docker
网络:
安装Docker时,它会自动创建三个网络,bridge(创建容器默认连接到此网络)、 none 、host

1.Host 使用宿主机的网络
如果启动容器的时候使用host模式,那么这个容器将不会获得一个独立的Network Namespace,而是和宿主机共用一个Network Namespace。容器将不会虚拟出自己的网卡,配置自己的IP等,而是使用宿主机的IP和端口。(网络好,但隔离性差)

2.Bridge 此模式会为每一个容器分配、设置IP等,并将容器连接到一个docker0虚拟网桥,通过docker0网桥以及Iptables nat表配置与宿主机通信。(类似交换机)
容器使用独立network Namespace,并连接到docker0虚拟网卡(默认模式)。通过docker0网桥以及Iptables nat表配置与宿主机通信;bridge模式是Docker默认的网络设置,此模式会为每一个容器分配Network Namespace、设置IP等,并将一个主机上的Docker容器连接到一个虚拟网桥上。

3.None 该模式关闭了容器的网络功能。

4.Container 创建的容器不会创建自己的网卡,配置自己的IP,而是和一个指定的容器共享IP、端口范围。
新创建的容器和已经存在的一个容器共享一个Network Namespace,使用该容器的网络

Docker使用了Linux的Namespaces技术来进行资源隔离,如PID Namespace隔离进程,Mount Namespace隔离文件系统,Network Namespace隔离网络

如何规划一个k8s集群

  1. 与业务确认需求,明确资源归属;
  2. 资源规划,高可用,后续按需扩容
  3. 网络、存储
  4. 安全加固,权限、防火墙、组件安全配置等
  5. 运维组件:监控、日志、cicd。
    主体:根据业务需求出发,明确业务需要跑什么业务,体量多少。再依次落地资源、架构、网络、存储、安全、配套的监控、日志cicd等,然后需要自行跑通demo,验证可行性,再交付给业务。

ai在运维领域能做什么

  1. 异常检测与预警,基于监控指标、提前预测运维风险
  2. 知识图谱关联指标、日志、拓扑数据,快速定位故障源头。
  3. 资源系统,根据问题快速解决,比如扩缩容、清理日志&重启等
  4. 智能运维助手(很多开源工具,通过自然语言转换为运维操作,chatops,协助研发&运维作为知识库查询)
<think>好的,用户之前问了Kubernetes的八大资源,现在想深入了解Service的相关知识点。首先,我需要根据用户提供的引用内容来整理Service的核心概念和使用方法。引用[1]提到Service提供稳定的访问地址和负载均衡,引用[2]涉及kube-proxy的三种模式,引用[3]和[4]是关于创建Service的示例,包括Headless Service。 用户可能已经了解Deployment和Pod,现在需要更详细地了解Service如何与这些资源协同工作。要注意用户可能想知道Service的类型、工作原理以及实际应用场景,比如如何暴露应用、服务发现机制等。此外,用户可能对Headless Service感兴趣,因为引用[4]提到了无头服务的配置。 需要确保回答结构清晰,分点解释核心概念、类型、工作原理、使用场景以及示例配置。同时,结合之前的回答,保持一致性,比如提到Service与Deployment和Pod的关系。还要注意用户可能关心如何在实际中使用YAML定义Service,以及不同Service类型的选择依据。 需要检查是否有遗漏的关键点,比如ClusterIP、NodePort、LoadBalancer和ExternalName的区别,以及kube-proxy的iptables和ipvs模式。此外,服务发现部分要提到DNS和环境变量两种方式,以及Headless Service的适用场景,如StatefulSet。 最后,生成相关问题时要覆盖用户可能进一步询问的方向,比如选择Service类型的考虑因素、Headless Service的应用、kube-proxy模式比较,以及Ingress与Service的关系等。确保回答准确,引用正确,并且语言简洁明了,符合用户需求。</think>### Kubernetes Service 核心概念与使用详解 Service 是 Kubernetes 实现微服务架构的核心组件,用于为 Pod 提供稳定的网络访问入口和负载均衡功能。以下是其核心知识点与使用场景的详细解析: --- #### 一、Service 核心功能 1. **稳定网络访问** - 通过虚拟 IP(ClusterIP)或 DNS 名称暴露服务,屏蔽后端 Pod 的 IP 变化[^1]。 - 示例:客户端通过 `web-svc.default.svc.cluster.local` 域名访问 Service。 2. **负载均衡** - 自动将流量分发到多个 Pod 副本,支持基于 `iptables` 或 `ipvs` 的流量转发[^2]。 - 权重分配方式取决于 kube-proxy 的代理模式。 3. **服务发现** - 通过标签选择器(`selector`)动态关联后端 Pod。 - 自动更新 Endpoints 列表,确保流量仅路由到健康的 Pod。 --- #### 二、Service 四种类型对比 | 类型 | 作用场景 | 特点 | |-----------------|-----------------------------|----------------------------------------------------------------------| | **ClusterIP** | 集群内部通信(默认类型) | 分配虚拟 IP,仅集群内可访问,适用于微服务间调用[^1]。 | | **NodePort** | 对外暴露服务(开发测试环境) | 在节点上开放静态端口(30000-32767),通过 `<NodeIP>:<NodePort>` 访问。 | | **LoadBalancer**| 云环境对外暴露服务 | 自动创建云厂商的负载均衡器(如 AWS ELB),直接分配公网 IP。 | | **ExternalName**| 代理外部服务 | 通过 CNAME 记录映射到外部 DNS(如数据库服务)。 | ##### 示例:NodePort 类型定义 ```yaml apiVersion: v1 kind: Service metadata: name: web-nodeport spec: type: NodePort selector: app: web ports: - port: 80 # Service 端口 targetPort: 80 # Pod 端口 nodePort: 30080 # 节点端口(可选,范围 30000-32767) ``` --- #### 三、核心实现原理 1. **kube-proxy 代理模式** - **iptables 模式**(默认) - 通过 iptables 规则转发流量,性能较高但规则数量随 Pod 增长而增加[^2]。 - **ipvs 模式**(推荐生产环境) - 基于内核级负载均衡,支持更多调度算法(如轮询、最少连接)。 - **Userspace 模式**(已弃用) 2. **Endpoint 动态更新** - Service 通过 `Endpoints` 对象维护后端 Pod 的 IP 列表。 - 示例:查看 Service 关联的 Endpoints: ```bash kubectl get endpoints <service-name> ``` --- #### 四、进阶使用场景 1. **Headless Service(无头服务)** - **定义**:设置 `clusterIP: None`,不分配 ClusterIP,直接返回 Pod IP 列表[^4]。 - **作用**:适用于有状态应用(如 StatefulSet),支持直接访问特定 Pod。 - 示例: ```yaml apiVersion: v1 kind: Service metadata: name: headless-svc spec: clusterIP: None selector: app: stateful-app ports: - port: 80 targetPort: 80 ``` 2. **服务发现机制** - **DNS 解析**:Pod 可通过 `<service-name>.<namespace>.svc.cluster.local` 访问 Service。 - **环境变量注入**:Pod 启动时自动注入 `SERVICE_HOST` 和 `SERVICE_PORT` 变量。 --- #### 五、典型实践场景 1. **微服务间通信** - 前端服务通过 `ClusterIP` 访问后端 API 服务。 2. **灰度发布** - 结合 Deployment 的多个版本 Pod,通过 Service 流量切换实现滚动更新。 3. **混合云部署** - 使用 `ExternalName` 类型代理外部遗留系统,逐步迁移至 Kubernetes。 --- ### 常见问题解答 **Q1:Service 与 Ingress 的区别?** - **Service**:提供 L4 层(TCP/UDP)负载均衡,聚焦于 Pod 访问入口。 - **Ingress**:提供 L7 层(HTTP/HTTPS)路由,支持域名、路径等高级路由规则。 **Q2:如何调试 Service 无法访问的问题?** 1. 检查 Service 的 `selector` 是否与 Pod 标签匹配。 2. 验证 Endpoints 是否包含预期 Pod IP: ```bash kubectl describe svc <service-name> ``` 3. 检查 kube-proxy 是否正常运: ```bash kubectl get pods -n kube-system -l k8s-app=kube-proxy ``` ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值