导图社区 Kubernetes思维导图
- 111
- 1
- 举报
Kubernetes思维导图
k8s基础知识，k8s运维常见命令，Kubernetes是一个功能强大的容器编排系统，它使得部署、管理和扩展容器化应用变得更加简单和高效。
编辑于2024-03-01 16:58:47- 运维
- docker
- 云原生
- k8s
- 相似推荐
- 大纲
K8s
1.kubernetes 概述
k8s基本介绍
是一个开源 的，用于管理云平台中多个主机上的容器化的应用 Kubernetes 的目标是让部署容器化的 应用简单并且高效（powerful）,Kubernetes 提供了应用部署，规划，更新，维护的一种机制。 传统的应用部署方式是通过插件或脚本来安装应用。这样做的缺点是应用的运行、配 置、管理、所有生存周期将与当前操作系统绑定，这样做并不利于应用的升级更新/回滚等 操作，当然也可以通过创建虚拟机的方式来实现某些功能，但是虚拟机非常重，并不利于可移植性。 新的方式是通过部署容器方式实现，每个容器之间互相隔离，每个容器有自己的文件系统 ，容器之间进程不会相互影响，能区分计算资源。相对于虚拟机，容器能快速部署， 由于容器与底层设施、机器文件系统解耦的，所以它能在不同云、不同版本操作系统间进行迁移。 容器占用资源少、部署快，每个应用可以被打包成一个容器镜像，每个应用与容器间 成一对一关系也使容器有更大优势，使用容器可以在 build 或 release 的阶段，为应用创 建容器镜像，因为每个应用不需要与其余的应用堆栈组合，也不依赖于生产环境基础结构， 这使得从研发到测试、生产能提供一致环境。类似地，容器比虚拟机轻量、更“透明”， 这更便于监控和管理。 Kubernetes 是 Google 开源的一个容器编排引擎，它支持自动化部署、大规模可伸缩、 应用容器化管理。在生产环境中部署一个应用程序时，通常要部署该应用的多个实例以便 对应用请求进行负载均衡。 在 Kubernetes 中，我们可以创建多个容器，每个容器里面运行一个应用实例，然后通 过内置的负载均衡策略，实现对这一组应用实例的管理、发现、访问，而这些细节都不需 要运维人员去进行复杂的手工配置和处理。
k8s功能和架构
2.1 概述
Kubernetes 是一个轻便的和可扩展的开源平台，用于管理容器化应用和服务。通过 Kubernetes 能够进行应用的自动化部署和扩缩容。在 Kubernetes 中，会将组成应用的容 器组合成一个逻辑单元以更易管理和发现。Kubernetes 积累了作为 Google 生产环境运行 工作负载 15 年的经验，并吸收了来自于社区的最佳想法和实践
2.2 K8s 功能
自动装箱
基于容器对应用运行环境的资源配置要求自动部署应用容器
自我修复
当容器失败时，会对容器进行重启 当所部署的 Node 节点有问题时，会对容器进行重新部署和重新调度 当容器未通过监控检查时，会关闭此容器直到容器正常运行时，才会对外提供服务 原理很简单： 在容器哪里暴露接口 然后每隔一段时间调用一次 如果调用不到，就是挂了，就重新构建
水平扩展
通过简单的命令、用户 UI 界面或基于 CPU 等资源使用情况，对应用容器进行规模扩大 或规模剪裁
服务发现
用户不需使用额外的服务发现机制，就能够基于 Kubernetes 自身能力实现服务发现和 负载均衡
滚动更新
可以根据应用的变化，对应用容器运行的应用，进行一次性或批量式更新
版本回退
可以根据应用部署情况，对应用容器运行的应用，进行历史版本即时回退
密钥和配置管理
在不需要重新构建镜像的情况下，可以部署和更新密钥和应用配置，类似热部署
存储编排
自动实现存储系统挂载及应用，特别对有状态应用实现数据持久化非常重要 存储系统可以来自于本地目录、网络存储(NFS、Gluster、Ceph 等)、公共云存储服务
批处理
提供一次性任务，定时任务；满足批量数据处理和分析的场景
2.3 应用部署架构分类
无中心节点架构
GlusterFS
有中心节点架构
HDFS K8S
2.4 k8s 集群架构

2.5 k8s 集群架构节点角色功能

MasterNode
k8s集群控制节点，对集群进行调度管理，接受集群外用户去集群操作请求
WorkerNode
集群工作节点，运行用户业务应用容器
核心概念
节点
从上面的图可以看出来，k8s 集群的节点有两个角色，分别为 Master 节点和 Node 节点，整个 K8s 集群Master 和 Node 节点关系如下图所示： 
Master 节点
Master 节点也称为控制节点，每个 k8s 集群都有一个 Master 节点负责整个集群的管理控制，我们上面介绍的 k8s 三大能力都是经过 Master 节点发起的，Master 节点包含了以下几个组件：  API Server：提供了 HTTP Rest 接口的服务进程，所有资源对象的增、删、改、查等操作的唯一入口； Controller Manager：k8s 集群所有资源对象的自动化控制中心； Scheduler：k8s 集群所有资源对象自动化调度控制中心； ETCD：k8s 集群注册服务发现中心，可以保存 k8s 集群中所有资源对象的数据
Node
Node 节点的作用是承接 Master 分配的工作负载，它主要有以下几个关键组件： kubelet：负责 Pod 对应容器的创建、启停等操作，与 Master 节点紧密协作； kube-porxy：实现 k8s 集群通信与负载均衡的组件。 
Pod
从以上 Pod 的结构图可以看出，它其实是容器的一个上层包装结构，这也就是为什么 K8s 可以支持多种容器类型的原因，基于这方面， k8s 的定位就是一个编排与调度工具，而容器只是它调度的一个资源对象而已。 Pod 可包含多个容器在里面，每个 Pod 至少会有一个 Pause 容器，其它用户定义的容器都共享该 Pause 容器，Pause 容器的主要作用是用于定义 Pod 的 ip 和 volume。 
Label
Label 在 k8s 中是一个非常核心的概念，我们可以将 Label 指定到对应的资源对象中 例如 Node、Pod、Replica Set、Service 等，一个资源可以绑定任意个 Label，k8s 通过 Label 可实现多维度的资源分组管理，后续可通过 Label Selector 查询和筛选拥有某些 Label 的资源对象，例如创建一个 Pod，给定一个 Label，workerid=123，后续可通过 workerid=123 删除拥有该标签的 Pod 资源。
Replica Set
Replica Set 目的是为了定义一个期望的场景，比如定义某种 Pod 的副本数量在任意时刻都处于 Peplica Set 期望的值 假设 Replica Set 定义 Pod 的副本数目为：replicas=2，当该 Replica Set 提交给 Master 后，Master 会定期巡检该 Pod 在集群中的数目，如果发现该 Pod 挂掉了一个，Master 就会尝试依据 Replica Set 设置的 Pod 模版创建 Pod，以维持 Pod 的数量与 Replica Set 预期的 Pod 数量相同。 通过 Replica Set，k8s 集群实现了用户应用的高可用性，而且大大减少了运维工作量。因此生产环境一般用 Deployment 或者 Replica Set 去控制 Pod 的生命周期和期望值，而不是直接单独创建 Pod。  类似 Replica Set 的还有 Deployment，它的内部实现也是通过 Replica Set 实现的，可以说 Deployment 是 Replica Set 的升级版，它们之间的 yaml 配置文件格式大部分都相同。
Service
Service 是 k8s 能够实现微服务集群的一个非常重要的概念 顾名思义，k8s 的 Service 就是我们平时所提及的微服务架构中的“微服务”，本文上面提及的 Pod、Replica Set 等都是为 Service 服务的资源， 如下图表示 Service、Pod、Replica Set 的关系：  从上图可看出，Service 定义了一个服务访问的入口，客户端通过这个入口即可访问服务背后的应用集群实例，而 Service 则是通过 Label Selector 实现关联与对接的，Replica Set 保证服务集群资源始终处于期望值。 以上只是一个微服务，通常来说一个应用项目会由多个不同业务能力而又彼此独立的微服务组成，多个微服务间组成了一个强大而又高可用的应用服务集群。 
Namespace
Namespace 顾名思义是命名空间的意思，在 k8s 中主要用于实现资源隔离的目的 用户可根据不同项目创建不同的 Namespace，通过 k8s 将资源分配到不同 Namespace 中，即可实现不同项目的资源隔离： 
部署
部署性能监控平台
高可用集群搭建
部署项目
部署踩坑
要使用新版本的系统内核要高于4.4
网络插件可能没有要安装flannel
2.K8s集群
搭建
kubernetes 集群搭建(kubeadm 方式)
kubernetes 集群搭建(二进制方式)
YAML 文件详解
命令行工具 kubectl
kubernetes 核心技术
pod
Pod是kubernetes中你可以创建和部署的最小也是最简的单位，一个Pod代表着集群中运行的一个进程。 Pod中封装着应用的容器（有的情况下是好几个容器），存储、独立的网络IP，管理容器如何运行的策略选项，Pod代表着部署的一个单位：kubernetes中应用的一个实例，可能由一个或者多个容器组合在一起共享资源。
4.1 Pod 特点
4.1.1 网络
4.1.2 存储
4.2 使用方式
4.2.1 自主式Pod
4.2.2 控制器管理的Pod
4.3 自主运行Pod
4.3.1 创建资源清单
4.3.1.1 参数描述
pod控制器
Pod控制器就是帮助我们自动的调度管理Pod，并满足期望的Pod数量。 Pod控制器是用于实现管理pod的中间层，确保pod资源符合预期的状态，pod的资源出现故障时，会尝试进行重启，当根据重启策略无效，则会重新新建pod的资源。 创建为具体的控制器对象之后，每个控制器均通过API Server提供的接口持续监控相关资源对象的当前状态，并在因故障、更新或其他原因导致系统状态发生变化时，尝试让资源的当前状态想期望状态迁移和逼近。
控制器的必要性
常见的控制器
ReplicaSet
代用户创建指定数量的pod副本数量，确保pod副本数量符合预期状态，并且支持滚动式自动扩容和缩容功能
概述
ReplicaSet是取代早期版本中的ReplicationController控制器，其功能基本上与ReplicationController相同 ReplicaSet（简称RS）是Pod控制器类型的一种实现，用于确保由其管控的Pod对象副本数在任意时刻都能精确满足期望的数量，ReplicaSet控制器资源启动后会查找集群中匹配器标签选择器的Pod资源对象，当前活动对象的数量与期望的数量不吻合时，多则删除，少则通过Pod模板创建以补足。
功能
精确反应期望值 确保Pod资源对象的数量精确反映期望值：ReplicaSet需要确保由其控制运行的Pod副本数量精确吻合配置中定义的期望值，否则就会自动补足所缺或终止所余。 保证高可用 确保Pod健康运行：探测到由其管控的Pod对象因其所在的工作节点故障而不可用时，自动请求由调度器于其他工作节点创建缺失的Pod副本。 弹性伸缩 弹性伸缩：可通过ReplicaSet控制器动态扩容或者缩容Pod资源对象的数量，必要时还可以通过HPA控制器实现Pod资源规模的自动伸缩。
创建ReplicaSet
核心属性

ReplicaSet示例
vi nginx-rs.yml apiVersion: apps/v1 #api版本定义 kind: ReplicaSet #定义资源类型为ReplicaSet metadata: #元数据定义 name: nginx-rs namespace: default spec: #ReplicaSet的规格定义 replicas: 2 #定义副本数量为2个 selector: #标签选择器，定义匹配Pod的标签 matchLabels: app: nginx template: #Pod的模板定义 metadata: #Pod的元数据定义 name: nginx-pod #自定义Pod的名称 labels: #定义Pod的标签，需要和上面的标签选择器内匹配规则中定义的标签一致，可以多出其他标签 app: nginx spec: #Pod的规格定义 containers: #容器定义 - name: nginx #容器名称 image: nginx:1.12 #容器镜像 imagePullPolicy: IfNotPresent #拉取镜像的规则 ports: #暴露端口 - name: http #端口名称 containerPort: 80
Deployment
工作在ReplicaSet之上，用于管理无状态应用，目前来说最好的控制器。支持滚动更新和回滚功能，还提供声明式配置。
例子
apiVersion: apps/v1 kind: Deployment metadata: labels: app: ngx-dep name: ngx-dep spec: replicas: 2 selector: matchLabels: app: ngx-dep template: metadata: labels: app: ngx-dep spec: containers: - image: nginx:alpine name: nginx
DaemonSet
用于确保集群中的每一个节点只运行特定的pod副本，常用于实现系统级后台任务，比如ELK服务
Pod和Pod控制器
Pod控制器资源通过持续性地监控集群中运行着的Pod资源对象来确保受其管控的资源严格符合用户期望的状态，例如资源副本的数量要精确符合期望等。 通常，一个Pod控制器资源至少应该包含三个基本的组成部分： 标签选择器：匹配并关联Pod资源对象，并据此完成受其管控的Pod资源计数。 期望的副本数：期望在集群中精确运行着的Pod资源的对象数量。 Pod模板：用于新建Pod资源对象的Pod模板资源。
配置
ConfigMap
一类是明文配置，也就是不保密，可以任意查询修改，比如服务端口、运行参数、文件路径等等。
创建样板文件
export out="--dry-run=client -o yaml" # 定义Shell变量 kubectl create cm info $out
查看 ConfigMap 的状态
kubectl get cm kubectl describe cm info
创建ConfigMap对象
apiVersion: v1 kind: ConfigMap metadata: name: info data: count: '10' debug: 'on' path: '/etc/systemd' greeting: | say hello to kubernetes. kubectl apply -f cm.yml
Secret
另一类则是机密配置，由于涉及敏感信息需要保密，不能随便查看，比如密码、密钥、证书等等。
创建样板文件
kubectl create secret generic user --from-literal=name=root $out
查看 Secret 的状态
kubectl apply -f secret.yml kubectl get secret kubectl describe secret user
存储
Volume
PersistentVolume
Kubernetes 就顺着 Volume 的概念，延伸出了 PersistentVolume 对象，它专门用来表示持久存储设备，但隐藏了存储的底层实现，我们只需要知道它能安全可靠地保管数据就可以了（由于 PersistentVolume 这个词很长，一般都把它简称为 PV）。 作为存储的抽象，PV 实际上就是一些存储设备、文件系统，比如 Ceph、GlusterFS、NFS，甚至是本地磁盘，管理它们已经超出了 Kubernetes 的能力范围，所以，一般会由系统管理员单独维护，然后再在 Kubernetes 里创建对应的 PV。 V 属于集群的系统资源，是和 Node 平级的一种对象，Pod 对它没有管理权，只有使用权。
PersistentVolumeClaim
从名字上看比较好理解，就是用来向 Kubernetes 申请存储资源的。PVC 是给 Pod 使用的对象，它相当于是 Pod 的代理，代表 Pod 向系统申请 PV。一旦资源申请成功，Kubernetes 就会把 PV 和 PVC 关联在一起，这个动作叫做“绑定”（bind）
StorageClass
StorageClass 的作用有点像IngressClass，它抽象了特定类型的存储系统（比如 Ceph、NFS），在 PVC 和 PV 之间充当“协调人”的角色，帮助 PVC 找到合适的 PV。也就是说它可以简化 Pod 挂载“虚拟盘”的过程，让 Pod 看不到 PV 的实现细节。 
如何为 Pod 挂载 PersistentVolume

NameSpace
它可以把集群切分成一个个彼此独立的区域，然后我们把对象放到这些区域里，就实现了类似容器技术里 namespace 的隔离效果 优点：防止命名冲突
例子
apiVersion: v1 kind: Pod metadata: name: ngx namespace: test-ns spec: containers: - image: nginx:alpine name: ngx
探针
Kubernetes 支持 3 种：Shell、TCP Socket、HTTP GET，它们也需要在探针里配置：exec，执行一个 Linux 命令，比如 ps、cat 等等，和 container 的 command 字段很类似。tcpSocket，使用 TCP 协议尝试连接容器的指定端口。httpGet，连接端口并发送 HTTP GET 请求。
类型
Startup
启动探针，用来检查应用是否已经启动成功，适合那些有大量初始化工作要做，启动很慢的应用
Liveness
存活探针，用来检查应用是否正常运行，是否存在死锁、死循环
Readiness
就绪探针，用来检查应用是否可以接收流量，是否能够对外提供服务
例子
apiVersion: v1 kind: Pod metadata: name: ngx-pod-probe spec: volumes: - name: ngx-conf-vol configMap: name: ngx-conf containers: - image: nginx:alpine name: ngx ports: - containerPort: 80 volumeMounts: - mountPath: /etc/nginx/conf.d name: ngx-conf-vol startupProbe: periodSeconds: 1 exec: command: ["cat", "/var/run/nginx.pid"] livenessProbe: periodSeconds: 10 tcpSocket: port: 80 readinessProbe: periodSeconds: 5 httpGet: path: /ready port: 80
调度器
集群安全机制RBAC
Helm
Controller
反向代理
service
Service 的工作原理和 LVS、Nginx 差不多，Kubernetes 会给它分配一个静态 IP 地址，然后它再去自动管理、维护后面动态变化的 Pod 集合，当客户端访问 Service，它就根据某种策略，把流量转发给后面的某个 Pod。
工作原理
这里 Service 使用了 iptables 技术，每个节点上的 kube-proxy 组件自动维护 iptables 规则，客户不再关心 Pod 的具体地址，只要访问 Service 的固定 IP 地址，Service 就会根据 iptables 规则转发请求给它管理的多个 Pod，是典型的负载均衡架构。 
创建样板文件
kubectl expose deploy ngx-dep --port=80 --target-port=80 $out apiVersion: v1 kind: Service metadata: name: ngx-svc spec: selector: app: ngx-dep ports: - port: 80 targetPort: 80 protocol: TCP Service 的定义非常简单，在“spec”里只有两个关键字段，selector 和 ports。selector 和 Deployment/DaemonSet 里的作用是一样的，用来过滤出要代理的那些 Pod。因为我们指定要代理 Deployment，所以 Kubernetes 就为我们自动填上了 ngx-dep 的标签，会选择这个 Deployment 对象部署的所有 Pod。
Service和Pod的关系

ingress
因为Service 的功能和运行机制，它本质上就是一个由 kube-proxy 控制的四层负载均衡，在 TCP/IP 协议栈上转发流量 但在四层上的负载均衡功能还是太有限了，只能够依据 IP 地址和端口号做一些简单的判断和组合，而我们现在的绝大多数应用都是跑在七层的 HTTP/HTTPS 协议上的，有更多的高级路由条件，比如主机名、URI、请求头、证书等等，而这些在 TCP/IP 网络栈里是根本看不见的。 Service 还有一个缺点，它比较适合代理集群内部的服务。如果想要把服务暴露到集群外部，就只能使用 NodePort 或者 LoadBalancer 这两种方式，而它们都缺乏足够的灵活性，难以管控，这就导致了一种很无奈的局面：我们的服务空有一身本领，却没有合适的机会走出去大展拳脚
ingress如何解决Service的问题？
使用七层负载均衡解决只使用四层的问题 ingress还应该承担更多的职责，也就是作为流量的总入口，统管集群的进出口数据，
Ingress Controller
例子
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: ngx-ing spec: ingressClassName: ngx-ink rules: - host: ngx.test http: paths: - path: / pathType: Exact backend: service: name: ngx-svc port: number: 80
Ingress 和 Service、Ingress Class 的关系

Geteway
k8s 组件介绍
整体架构
Master 架构
Node 架构
k8s部署组件介绍

k8s控制组件
3.2.2.1 控制平面
K8s 集群的神经中枢 让我们从 Kubernetes 集群的神经中枢（即控制平面）开始说起。在这里，我们可以找到用于控制集群的 Kubernetes 组件以及一些有关集群状态和配置的数据，这些核心 Kubernetes 组件负责处理重要的工作，以确保容器以足够的数量和所需的资源运行。 控制平面会一直与您的计算机保持联系。集群已被配置为以特定的方式运行，而控制平面要做的就是确保万无一失。
3.2.2.2 kube-apiserver
K8s 集群API，如果需要与您的 Kubernetes 集群进行交互，就要通过 API Kubernetes API 是 Kubernetes 控制平面的前端，用于处理内部和外部请求。API 服务器会确定请求是否有效，如果有效，则对其进行处理，您可以通过 REST 调用、kubectl 命令行界面或其他命令行工具（例如 kubeadm）来访问 API。
3.2.2.3 kube-scheduler
K8s 调度程序，您的集群是否状况良好？如果需要新的容器，要将它们放在哪里？这些是 Kubernetes 调度程序所要关注的问题 调度程序会考虑容器集的资源需求（例如 CPU 或内存）以及集群的运行状况。随后，它会将容器集安排到适当的计算节点。
3.2.2.4 kube-controller-manager
K8s 控制器，控制器负责实际运行集群，而 Kubernetes 控制器管理器则是将多个控制器功能合而为一 控制器用于查询调度程序，并确保有正确数量的容器集在运行。如果有容器集停止运行，另一个控制器会发现并做出响应。控制器会将服务连接至容器集，以便让请求前往正确的端点。还有一些控制器用于创建帐户和 API 访问令牌。
3.2.2.5 etcd
键值存储数据库 配置数据以及有关集群状态的信息位于 etcd（一个键值存储数据库）中。etcd 采用分布式、容错设计，被视为集群的最终事实来源。
k8s运行组件
3.2.3.1 k8s节点
Kubernetes 集群中至少需要一个计算节点，但通常会有多个计算节点。 容器集经过调度和编排后，就会在节点上运行。如果需要扩展集群的容量，那就要添加更多的节点。
3.2.3.2 容器集
容器集是 Kubernetes 对象模型中最小、最简单的单元。 它代表了应用的单个实例。每个容器集都由一个容器（或一系列紧密耦合的容器）以及若干控制容器运行方式的选件组成。容器集可以连接至持久存储，以运行有状态应用。
3.2.3.3 容器运行时引擎
为了运行容器，每个计算节点都有一个容器运行时引擎。 比如 Docker，但 Kubernetes 也支持其他符合开源容器运动（OCI）标准的运行时，例如 rkt 和 CRI-O。
3.2.3.4 kubelet
每个计算节点中都包含一个 kubelet，这是一个与控制平面通信的微型应用。 kublet 可确保容器在容器集内运行，当控制平面需要在节点中执行某个操作时，kubelet 就会执行该操作。
3.2.3.5 kube-proxy
每个计算节点中还包含 kube-proxy，这是一个用于优化 Kubernetes 网络服务的网络代理。 kube-proxy 负责处理集群内部或外部的网络通信——靠操作系统的数据包过滤层，或者自行转发流量。
k8s 存储组件
持久存储
除了管理运行应用的容器外，Kubernetes 还可以管理附加在集群上的应用数据。 Kubernetes 允许用户请求存储资源，而无需了解底层存储基础架构的详细信息。持久卷是集群（而非容器集）所特有的，因此其寿命可以超过容器集
容器镜像仓库
Kubernetes 所依赖的容器镜像存储于容器镜像仓库中。 这个镜像仓库可以由您自己配置的，也可以由第三方提供。
底层基础架构
您可以自己决定具体在哪里运行 Kubernetes。 答案可以是裸机服务器、虚拟机、公共云提供商、私有云和混合云环境。Kubernetes 的一大优势就是它可以在许多不同类型的基础架构上运行。
常用命令
nodes
查看在运行中服务
kubectl get ing -A
查看所有node节点
kubectl get nodes
namespace(命名空间)
查看所有namespace(命名空间)
kubectl get namesapce kubectl get ns
查看指定namespace(命名空间)
kubectl get ns nacos
查看ns详情
kubectl describe ns ns名称 kubectl describe ns default
创建namespace
kubectl create ns dev-test
删除namespace
kubectl delete ns dev-test
根据配置文件创建、删除
kubectl create -f dev-test.yaml apiVersion: v1 kind: Namespace metadata: name: dev-test
pod
Pod是kubernetes集群进行管理的最小单元，程序要运行必须部署在容器中，而容器必须存在于Pod中。 Pod可以认为是容器的封装，一个Pod中可以存在一个或者多个容器。 kubernetes在集群启动之后，集群中的各个组件也都是以Pod方式运行的
删除
删除指定pod(过会会自动重启)
kubectl delete pod nginx-64777cd554-zgfqj -n dev
通过控制器删除pod
kubectl get deploy -n dev # 删除pod控制器 kubectl delete deploy nginx -n dev # 稍等片刻，再查询Pod，发现Pod被删除了 kubectl get pod -n dev
通过yaml删除pod
kubectl delete -f ngx-pod.yml
查看
查看系统pod
kubectl get pod -n kube-system
查看所有pod
kubectl get pod
查看pod(namespace=dev)
kubectl get pods -n dev
查询日志log
kubectl logs ngx-pod
查看某个pod
kubectl get pod pod_name
查看pod详细信息
kubectl describe pod nginx-5ff7956ff6-fg2db -n dev
查看某个pod,以yaml格式展示结果
kubectl get pod pod_name -o yaml
查看pod所在IP(集群内IP)
kubectl get pods -n dev -o wide # 用来curl curl http://10.244.1.23:80
操作
进入容器
kubectl exec -it ngx-pod -- sh
Label
给pod打标签(version=1.0)
kubectl label pod nginx version=1.0 -n dev
更新pod标签(version=2.0)
kubectl label pod nginx version=2.0 -n dev --overwrite
筛选指定label 标签(-l)
kubectl get pod -n dev -l version=2.0 --show-labels
删除label
kubectl label pod nginx version- -n dev
通过配置更新label
kubectl apply -f pod-nginx.yaml apiVersion: v1 kind: Pod metadata: name: nginx namespace: dev labels: version: "3.0" env: "test" spec: containers: - image: nginx:1.17.1 name: pod ports: - name: nginx-port containerPort: 80 protocol: TCP
控制器(deployment)
创建pod(3个)
# 命令格式: kubectl run deployment名称 [参数] # --image 指定pod的镜像 # --port 指定端口 # --replicas 指定创建pod数量 # --namespace 指定namespace kubectl run nginx --image=nginx:1.17.1 --port=80 --replicas=3 -n dev
查看创建的Pod
kubectl get pods -n dev
创建样板文件
export out="--dry-run=client -o yaml"
nginx的pod样板文件
kubectl run ngx --image=nginx:alpine $out > pod.yml 创建后删除不需要的字段 kubectl apply -f ngx-pod.yml kubectl get pod
Job/CronJob
查看日志
journalctl -xefu kubelet
案例
滚动升降级
系统监控
搭建wordPress
mariadb
apiVersion: v1 kind: ConfigMap metadata: name: maria-cm namespace: ns-wp data: DATABASE: 'db' USER: 'wp' PASSWORD: '123' ROOT_PASSWORD: '123' --- apiVersion: apps/v1 kind: Deployment metadata: labels: app: maria-dep name: maria-dep namespace: ns-wp spec: replicas: 1 selector: matchLabels: app: maria-dep template: metadata: labels: app: maria-dep spec: containers: - image: mariadb:10 name: mariadb ports: - containerPort: 3306 envFrom: - prefix: 'MARIADB_' configMapRef: name: maria-cm --- apiVersion: v1 kind: Service metadata: labels: app: maria-dep name: maria-svc namespace: ns-wp spec: ports: - port: 3306 protocol: TCP targetPort: 3306 selector: app: maria-dep
wp
apiVersion: v1 kind: ConfigMap metadata: name: wp-cm namespace: ns-wp data: WORDPRESS_DB_HOST: 'maria-svc' WORDPRESS_DB_USER: 'wp' WORDPRESS_DB_PASSWORD: '123' WORDPRESS_DB_NAME: 'db' --- apiVersion: apps/v1 kind: Deployment metadata: labels: app: wp-dep name: wp-dep namespace: ns-wp spec: replicas: 2 selector: matchLabels: app: wp-dep template: metadata: labels: app: wp-dep spec: containers: - image: wordpress:5 name: wordpress ports: - containerPort: 80 envFrom: - configMapRef: name: wp-cm --- apiVersion: v1 kind: Service metadata: labels: app: wp-dep name: wp-svc namespace: ns-wp spec: ports: - name: http80 port: 80 protocol: TCP targetPort: 80 nodePort: 30088 selector: app: wp-dep type: NodePort