Kubernetes其他运维经验

IT那活儿发布于2023-01-11 13:19 / 1881人阅读

Kubernetes其他运维经验

点击上方“IT那活儿”公众号，关注后了解更多内容，不管IT什么活儿，干就完了！！！

PART1

Kubernetes核心技术Pod

1.1 Pod概述

Pod 是 k8s 系统中可以创建和管理的最小单元，是资源对象模型中由用户创建或部署的最小资源对象模型，也是在 k8s 上运行容器化应用的资源对象，其他的资源对象都是用来支撑或者扩展 Pod 对象功能的，比如控制器对象是用来管控 Pod 对象的，Service 或者Ingress 资源对象是用来暴露 Pod 引用对象的，PersistentVolume 资源对象是用来为 Pod提供存储等等，k8s 不会直接处理容器，而是 Pod，Pod 是由一个或多个 container 组成Pod 是 Kubernetes 的最重要概念，每一个 Pod 都有一个特殊的被称为”根容器“的 Pause容器。

Pause 容器对应的镜像属于 Kubernetes 平台的一部分，除了 Pause 容器，每个 Pod还包含一个或多个紧密相关的用户业务容器。

1）Pod vs 应用

每个 Pod 都是应用的一个实例，有专用的 IP。

2）Pod vs 容器

一个 Pod 可以有多个容器，彼此间共享网络和存储资源，每个 Pod 中有一个 Pause 容器保存所有的容器状态，通过管理 pause 容器，达到管理 pod 中所有容器的效果。

3）Pod vs 节点

同一个 Pod 中的容器总会被调度到相同 Node 节点，不同节点间 Pod 的通信基于虚拟二层网络技术实现。

4）Pod vs Pod

普通的 Pod 和静态 Pod。

1.2 Pod 特性

1）资源共享

一个 Pod 里的多个容器可以共享存储和网络，可以看作一个逻辑的主机。共享的如namespace,cgroups 或者其他的隔离资源。

多个容器共享同一 network namespace，由此在一个 Pod 里的多个容器共享 Pod 的 IP和端口 namespace，所以一个 Pod 内的多个容器之间可以通过 localhost 来进行通信,所需要注意的是不同容器要注意不要有端口冲突即可。不同的 Pod 有不同的 IP,不同 Pod 内的多个容器之前通信，不可以使用 IPC（如果没有特殊指定的话）通信，通常情况下使用 Pod的 IP 进行通信。一个 Pod 里的多个容器可以共享存储卷，这个存储卷会被定义为 Pod 的一部分，并且可以挂载到该 Pod 里的所有容器的文件系统上。

2）生命周期短暂

Pod 属于生命周期比较短暂的组件，比如，当 Pod 所在节点发生故障，那么该节点上的 Pod会被调度到其他节点，但需要注意的是，被重新调度的 Pod 是一个全新的 Pod,跟之前的Pod 没有半毛钱关系。

3）平坦的网络

K8s 集群中的所有 Pod 都在同一个共享网络地址空间中，也就是说每个 Pod 都可以通过其他Pod的IP地址来实现访问。

1.3 Pod 定义

下面是 yaml 文件定义的 Pod 的完整内容：

apiVersion: v1
kind: Pod
metadata:
//元数据
name: string
namespace: string
labels:
-name: string
annotations:
-name: string
spec:
containers:
//pod 中的容器列表，可以有多个容器
- name: string
//容器的名称
image: string //容器中的镜像
imagesPullPolicy: [Always|Never|IfNotPresent]//获取镜像的策略，默认值为Always，每次都尝试重新下载镜像
command: [string]
//容器的启动命令列表（不配置的话使用镜像内部的命令） args:
[string]
//启动参数列表
workingDir: string
//容器的工作目录 volumeMounts:
//挂载到到容器内部的存储卷设置
-name: string
mountPath: string
//存储卷在容器内部 Mount 的绝对路径 readOnly: boolean
//
默认值为读写
ports: //容器需要暴露的端口号列表
-name: string
containerPort: int //容器要暴露的端口
hostPort: int //容器所在主机监听的端口（容器暴露端口映射到宿主机的端口，设置hostPort 时同一台宿主机将不能再启动该容器的第 2 份副本）
protocol: string
//TCP 和 UDP，默认值为 TCP env:
//容器运行前要设置的环境列表
-name: string value: string
resources:
limits:
//资源限制，容器的最大可用资源数量 cpu: Srting
memory: string
requeste:
//资源限制，容器启动的初始可用资源数量 cpu: string
memory: string
livenessProbe:
//pod 内容器健康检查的设置 exec:
command: [string] //exec 方式需要指定的命令或脚本 httpGet:
//通过 httpget 检查健康
path: string port: number host: string scheme: Srtring httpHeaders:
- name: Stirng value: string
tcpSocket:
//通过 tcpSocket 检查健康
port: number initialDelaySeconds: 0//首次检查时间 timeoutSeconds: 0
//检查超时时间
periodSeconds: 0
//检查间隔时间
successThreshold: 0
failureThreshold: 0 securityContext:
//安全配置
privileged: falae
restartPolicy: [Always|Never|OnFailure]//重启策略，默认值为 Always
nodeSelector: object //节点选择，表示将该 Pod 调度到包含这些 label 的 Node 上，以key:value 格式指定
imagePullSecrets:
-name: string
hostNetwork: false
//是否使用主机网络模式，弃用 Docker 网桥，默认否
volumes: //在该 pod 上定义共享存储卷列表
-name: string emptyDir: {} hostPath:
path: string secret:
secretName: string item:
-key: string path: string
configMap: name: string items:
-key: string
path: string

1.4 Pod 的基本使用方法

在 kubernetes 中对运行容器的要求为：容器的主程序需要一直在前台运行，而不是后台运行。应用需要改造成前台运行的方式。如果我们创建的 Docker 镜像的启动命令是后台执行程序，则在 kubelet 创建包含这个容器的 pod 之后运行完该命令，即认为 Pod 已经结束，将立刻销毁该 Pod。如果为该 Pod 定义了 RC，则创建、销毁会陷入一个无限循环的过程中。

Pod 可以由 1 个或多个容器组合而成。

1）一个容器组成的 Pod 的 yaml 示例

# 一个容器组成的 Pod：

apiVersion: v1 kind: Pod metadata:
name: mytomcat labels:
name: mytomcat spec:
containers:
- name: mytomcat image: tomcat ports:
- containerPort: 8000

2）多个容器组成的 Pod 的 yaml 示例

#两个紧密耦合的容器：

apiVersion: v1 kind: Pod metadata:
name: myweb labels:
name: tomcat-redis
spec:
containers:
-name: tomcat image: tomcat ports:
-containerPort: 8080
-name: redis image: redis ports:
-containerPort: 6379

3）创建

4）查看

5）删除

1.5 Pod 的分类

Pod 有两种类型：

1）普通 Pod

普通 Pod 一旦被创建，就会被放入到 etcd 中存储，随后会被 Kubernetes Master 调度到某个具体的 Node 上并进行绑定，随后该 Pod 对应的 Node 上的 kubelet 进程实例化成一组相关的 Docker 容器并启动起来。在默认情况下，当 Pod 里某个容器停止时，Kubernetes会自动检测到这个问题并且重新启动这个 Pod 里某所有容器，如果 Pod 所在的 Node 宕机，则会将这个 Node 上的所有 Pod 重新调度到其它节点上。

2）静态 Pod

静态 Pod 是由 kubelet 进行管理的仅存在于特定 Node 上的 Pod,它们不能通过 API Server进行管理，无法与 ReplicationController、Deployment 或 DaemonSet 进行关联，并且kubelet 也无法对它们进行健康检查。

1.6 Pod 生命周期和重启策略

1）Pod 的状态

2）Pod 重启策略

Pod 的重启策略包括 Always、OnFailure 和 Never，默认值是 Always

3）常见状态转换

PART2

Kubernetes部署性能监控平台

2.1 概述

开源软件 cAdvisor（Container Advisor）用于监控所在节点的容器运行状态，当前已经被默认集成到 kubelet 组件内，默认使用 tcp 4194 端口。

在大规模容器集群，一般使用Heapster+Influxdb+Grafana 平台实现集群性能数据的采集，存储与展示。

2.2 环境准备

2.2.1 基础环境

Kubernetes + heapster + Influxdb + grafana

2.2.2 原理

Heapster：集群中各 node 节点的 cAdvisor 的数据采集汇聚系统，通过调用 node 上 kubelet 的 api，再通过 kubelet 调用 cAdvisor 的 api 来采集所在节点上所有容器的性能数据。Heapster 对性能数据进行聚合，并将结果保存到后端存储系统，heapster 支持多种后端存储系统，如 memory，Influxdb 等。
Influxdb：分布式时序数据库（每条记录有带有时间戳属性），主要用于实时数据采集，时间跟踪记录，存储时间图表，原始数据等。Influxdb 提供 rest api 用于数据的存储与查询。
Grafana：通过 dashboard 将 Influxdb 中的时序数据展现成图表或曲线等形式，便于查看集群运行状态。

Heapster，Influxdb，Grafana 均以 Pod 的形式启动与运行。

2.2.3 部署 Kubernetes 集群性能监控

2.2.3.1 准备 images

kubernetes 部署服务时，为避免部署时发生 pull 镜像超时的问题，建议提前将相关镜像pull 到相关所有节点（以下以 kubenode1 为例），或搭建本地镜像系统。需要从 gcr.io pull 的镜像，已利用 Docker Hub 的"CreateAuto-Build GitHub"功能（Docker Hub 利用 GitHub 上的 Dockerfile 文件 build 镜像），在个人的 Docker Hubbuild 成功，可直接 pull 到本地使用。

2.2.3.2 下载 yaml 范本

2.2.3.3 heapster-rbac.yaml

2.2.3.4 heapster.yaml

hepster.yaml 由 3 个模块组成：ServiceAccout，Deployment，Service。

1）ServiceAccount

默认不需要修改 ServiceAccount 部分，设置 ServiceAccount 资源，获取 rbac 中定义的权限。

2）Deployment

3）Service

默认不需要修改 Service 部分。

4）Service

默认不需要修改 Service 部分，注意 Service 名字的对应即可。

2.2.3.5 grafana.yaml

grafana.yaml 由 2 个模块组成：Deployment，Service。

1）Deployment

# 修改处：第 16 行，变更镜像名；

# 修改处：第 43 行，取消注释；“GF_SERVER_ROOT_URL”的 value 值设定后，只能通过API Server proxy 访问 grafana；

# 修改处：第 44 行，注释本行；

# INFLUXDB_HOST 的 value 值设定为 influxdb 的 service 名，依赖于集群 dns，或者直接使用 ClusterIP。

[root@kubenode1 influxdb]# sed -i s|gcr.io/google_containers/heapster-grafana-
amd64:v4.4.3|netonline/heapster-grafana-amd64:v4.4.3|g grafana.yaml
[root@kubenode1 influxdb]# sed -i 43s|# value:|value:|g grafana.yaml
[root@kubenode1 influxdb]# sed -i 44s|value:|# value:|g grafana.yaml
[root@kubenode1 influxdb]# cat grafana.yaml
……
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: monitoring-grafananamespace: kube-system
spec:
replicas: 1
template:
metadata:
labels:
task: monitoring
k8s-app: grafana
spec:
containers:
- name: grafana
image: netonline/heapster-grafana-amd64:v4.4.3
ports:
- containerPort: 3000
protocol: TCP
volumeMounts:
- mountPath: /etc/ssl/certs
name: ca-certificates
readOnly: true
- mountPath: /var
name: grafana-storage
env:
- name: INFLUXDB_HOST
value: monitoring-influxdb
- name: GF_SERVER_HTTP_PORT
value: "3000"
# The following env variables are required to make Grafana accessible
via
# the kubernetes api-server proxy. On production clusters, we
recommend
# removing these env variables, setup auth for grafana, and expose
the grafana
# service using a LoadBalancer or a public IP.
- name: GF_AUTH_BASIC_ENABLED
value: "false"
- name: GF_AUTH_ANONYMOUS_ENABLED
value: "true"
- name: GF_AUTH_ANONYMOUS_ORG_ROLE
value: Admin
- name: GF_SERVER_ROOT_URL
# If youre only using the API Server proxy, set this value instead:
value: /api/v1/namespaces/kube-system/services/monitoring-
grafana/proxy
# value: /
volumes:
- name: ca-certificates
hostPath:
path: /etc/ssl/certs
- name: grafana-storage
emptyDir: {

2.2.4 验证

2.2.4.1 启动监控相关服务

2.2.4.2 查看相关服务

2.2.4.3 访问 dashboard

浏览器访问访问 dashboard：https://ip:6443/api/v1/namespaces/kube-

system/services/https:kubernetes-dashboard:/proxy

注意：Dasheboard 没有配置 hepster 监控平台时，不能展示 node，Pod 资源的 CPU 与内存等 metric 图形Node 资源 CPU/内存 metric 图形：

Pod 资源 CPU/内存 metric 图形：

2.2.4.4 访问 grafana

END

本文作者：熊静波

本文来源：IT那活儿（上海新炬王翦团队）

云服务器 GPU云服务器运维经验运维管理经验运维项目经验 it运维经验

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/129488.html

《Kubernetes从上手到实践》正式上线

摘要：有很大一部分的休息时间都用来完成了我的第一本掘金小册从上手到实践小册已经正式上线，特意送上各位小伙伴一份礼物，小册折优惠。时间飞逝，转眼今年又要结束了。感谢还在关注的小伙伴，今年确实更新很少，能不取关的都是真爱... 今年发生了很多事情，留着过几天年终总结的时候再说。有很大一部分的休息时间都用来完成了我的第一本掘金小册《Kubernetes 从上手到实践》 showImg(http...

CarterLi 2019-06-28 16:56 评论0 收藏0
《Kubernetes从上手到实践》正式上线

摘要：有很大一部分的休息时间都用来完成了我的第一本掘金小册从上手到实践小册已经正式上线，特意送上各位小伙伴一份礼物，小册折优惠。时间飞逝，转眼今年又要结束了。感谢还在关注的小伙伴，今年确实更新很少，能不取关的都是真爱... 今年发生了很多事情，留着过几天年终总结的时候再说。有很大一部分的休息时间都用来完成了我的第一本掘金小册《Kubernetes 从上手到实践》 showImg(http...

andot 2019-07-01 16:58 评论0 收藏0
《Kubernetes从上手到实践》正式上线

摘要：有很大一部分的休息时间都用来完成了我的第一本掘金小册从上手到实践小册已经正式上线，特意送上各位小伙伴一份礼物，小册折优惠。时间飞逝，转眼今年又要结束了。感谢还在关注的小伙伴，今年确实更新很少，能不取关的都是真爱... 今年发生了很多事情，留着过几天年终总结的时候再说。有很大一部分的休息时间都用来完成了我的第一本掘金小册《Kubernetes 从上手到实践》 showImg(http...

leon 2019-07-30 18:41 评论0 收藏0
才云科技CTO邓德源：不可不知的谷歌集群管理经验

摘要：曾为美国谷歌集群管理组核心成员，主要参与开发集群管理系统。保证系统升级软硬件错误等均能及时被发现并处理，谷歌集群能小时不间断工作。关于集群管理经验，首先一定要专注于持久的运维自动化工具开发。本文仅用于学习和交流目的，不得用于商业目的。非商业转载请注明作译者、出处，并保留本文的原始链接：http://www.ituring.com.cn/art... 访谈嘉宾：邓德源，才云科技CT...

callmewhy 2019-07-01 16:30 评论0 收藏0
才云科技CTO邓德源：不可不知的谷歌集群管理经验

摘要：曾为美国谷歌集群管理组核心成员，主要参与开发集群管理系统。保证系统升级软硬件错误等均能及时被发现并处理，谷歌集群能小时不间断工作。关于集群管理经验，首先一定要专注于持久的运维自动化工具开发。本文仅用于学习和交流目的，不得用于商业目的。非商业转载请注明作译者、出处，并保留本文的原始链接：http://www.ituring.com.cn/art... 访谈嘉宾：邓德源，才云科技CT...

Pines_Cheng 2019-06-28 15:36 评论0 收藏0
TOP100summit分享实录 | JFrog高欣：Kubernetes is hard!JFro

摘要：本文内容节选自由主办的第七届，架构师高欣分享的的实践实录。当然，在部署完成后，我们要做一个监测以便掌握它的运行状况。规划配置运行环境在正式部署前，还要考虑如何规划并配置好运行环境。在使用部署时，可以利用这些命令做验证，检验部署是否正常。 showImg(https://segmentfault.com/img/bVblRHj?w=2880&h=1920); 本文内容节选自由msup主办...

邹强 2019-07-01 16:58 评论0 收藏0