01-Kubernetes基本操作

官网： https://kubernetes.io/zh-cn/

前言：遇到不会的多百度，要自己具备解决问题的能力。

前置环境准备

1：linux机器配置：最低至少 2 个 CPU 核心，2 GB RAM 配置

2：关闭机器的防火墙并禁止开机自启动

sudo systemctl stop firewalld
sudo systemctl disable firewalld

这些一定要做，不然会报错

3：关闭 selinux：

sed -i 's/enforcing/disabled/' /etc/selinux/config
setenforce 0

4：关闭 swap

swapoff -a  
sed -ri 's/.*swap.*/#&/' /etc/fstab

5：配置桥接流量 允许 iptables 检查桥接流量 ipv6流量桥接到ipv4上，不然统计数据不准确

cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
br_netfilter
EOF
------------------
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
EOF
----------------------
sudo sysctl --system

6: 这里我已经准备好三台虚拟机，并配置好hosts

172.16.31.21 master
172.16.31.22 server01
172.16.31.23 server02

7: centos设置阿里源

#原有文件备份
mv /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.bak 
#下载centos7阿里镜像源
curl -o /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo
#清除Yum缓存
yum clean all
#更新Yum缓存
yum makecache
#验证
yum repolist

容器优势：

• 敏捷性：敏捷应用程序的创建和部署：与使用 VM 镜像相比，提高了容器镜像创建的简便性和效率。
• 及时性：持续开发、集成和部署：通过快速简单的回滚（由于镜像不可变性），支持可靠且频繁的 容器镜像构建和部署。
• 解耦性：关注开发与运维的分离：在构建/发布时创建应用程序容器镜像，而不是在部署时。 从而将应用程序与基础架构分离。
• 可观测性：可观察性不仅可以显示操作系统级别的信息和指标，还可以显示应用程序的运行状况和其他指标信号。
• 跨平台：跨开发、测试和生产的环境一致性：在便携式计算机上与在云中相同地运行。
• 可移植：跨云和操作系统发行版本的可移植性：可在 Ubuntu、RHEL、CoreOS、本地、 Google Kubernetes Engine 和其他任何地方运行。
• 简易性：以应用程序为中心的管理：提高抽象级别，从在虚拟硬件上运行 OS 到使用逻辑资源在 OS 上运行应用程序。
• 大分布式：松散耦合、分布式、弹性、解放的微服务：应用程序被分解成较小的独立部分， 并且可以动态部署和管理 - 而不是在一台大型单机上整体运行。
• 隔离性：资源隔离：可预测的应用程序性能。
• 高效性：资源利用：高效率和高密度

Kubernetes 会满足你的扩展要求、故障转移、部署模式等。 例如，Kubernetes 可以轻松管理系统的 Canary 部署。

Kubernetes 为你提供：

• 服务发现和负载均衡

Kubernetes 可以使用 DNS 名称或自己的 IP 地址公开容器，如果进入容器的流量很大， Kubernetes 可以负载均衡并分配网络流量，从而使部署稳定。

• 存储编排

Kubernetes 允许你自动挂载你选择的存储系统，例如本地存储、公共云提供商等。

• 自动部署和回滚

你可以使用 Kubernetes 描述已部署容器的所需状态，它可以以受控的速率将实际状态 更改为期望状态。例如，你可以自动化 Kubernetes 来为你的部署创建新容器， 删除现有容器并将它们的所有资源用于新容器。

• 自动完成装箱计算

Kubernetes 允许你指定每个容器所需 CPU 和内存（RAM）。 当容器指定了资源请求时，Kubernetes 可以做出更好的决策来管理容器的资源。

• 自我修复

Kubernetes 重新启动失败的容器、替换容器、杀死不响应用户定义的 运行状况检查的容器，并且在准备好服务之前不将其通告给客户端。

• 密钥与配置管理

Kubernetes 允许你存储和管理敏感信息，例如密码、OAuth 令牌和 ssh 密钥。 你可以在不重建容器镜像的情况下部署和更新密钥和应用程序配置，也无需在堆栈配置中暴露密钥

• .......

为了生产环境的容器化大规模应用编排，必须有一个自动化的框架。系统

0：Kubernetes 简介

内容来自官网

https://kubernetes.io/zh-cn/

Kubernetes 也称为 K8s，是用于自动部署、扩缩和管理容器化应用程序的开源系统。

1：时光回溯

🏆让我们回顾一下为何 Kubernetes 能够裨益四方。

传统部署时代：

早期，各个组织是在物理服务器上运行应用程序。 由于无法限制在物理服务器中运行的应用程序资源使用，因此会导致资源分配问题。 例如，如果在同一台物理服务器上运行多个应用程序， 则可能会出现一个应用程序占用大部分资源的情况，而导致其他应用程序的性能下降。 一种解决方案是将每个应用程序都运行在不同的物理服务器上， 但是当某个应用程序资源利用率不高时，剩余资源无法被分配给其他应用程序， 而且维护许多物理服务器的成本很高。

虚拟化部署时代：

因此，虚拟化技术被引入了。虚拟化技术允许你在单个物理服务器的 CPU 上运行多台虚拟机（VM）。 虚拟化能使应用程序在不同 VM 之间被彼此隔离，且能提供一定程度的安全性， 因为一个应用程序的信息不能被另一应用程序随意访问。

虚拟化技术能够更好地利用物理服务器的资源，并且因为可轻松地添加或更新应用程序， 而因此可以具有更高的可扩缩性，以及降低硬件成本等等的好处。 通过虚拟化，你可以将一组物理资源呈现为可丢弃的虚拟机集群。

每个 VM 是一台完整的计算机，在虚拟化硬件之上运行所有组件，包括其自己的操作系统。

容器部署时代：

容器类似于 VM，但是更宽松的隔离特性，使容器之间可以共享操作系统（OS）。 因此，容器比起 VM 被认为是更轻量级的。且与 VM 类似，每个容器都具有自己的文件系统、CPU、内存、进程空间等。 由于它们与基础架构分离，因此可以跨云和 OS 发行版本进行移植。

容器因具有许多优势而变得流行起来，例如：

• 敏捷应用程序的创建和部署：与使用 VM 镜像相比，提高了容器镜像创建的简便性和效率。
• 持续开发、集成和部署：通过快速简单的回滚（由于镜像不可变性）， 提供可靠且频繁的容器镜像构建和部署。
• 关注开发与运维的分离：在构建、发布时创建应用程序容器镜像，而不是在部署时， 从而将应用程序与基础架构分离。
• 可观察性：不仅可以显示 OS 级别的信息和指标，还可以显示应用程序的运行状况和其他指标信号。
• 跨开发、测试和生产的环境一致性：在笔记本计算机上也可以和在云中运行一样的应用程序。
• 跨云和操作系统发行版本的可移植性：可在 Ubuntu、RHEL、CoreOS、本地、 Google Kubernetes Engine 和其他任何地方运行。
• 以应用程序为中心的管理：提高抽象级别，从在虚拟硬件上运行 OS 到使用逻辑资源在 OS 上运行应用程序。
• 松散耦合、分布式、弹性、解放的微服务：应用程序被分解成较小的独立部分， 并且可以动态部署和管理 - 而不是在一台大型单机上整体运行。
• 资源隔离：可预测的应用程序性能。
• 资源利用：高效率和高密度。
• 容器编排：Kubernetes 允许你定义、部署和管理容器化应用程序，使得容器的生命周期管理变得更加简单和高效。
• 自动扩展：Kubernetes 可以根据需求自动扩展应用程序的副本数量，无论是水平扩展还是垂直扩展，从而确保应用程序始终以最佳状态运行。
• 高可用性：通过自动重启失败的容器、替换不健康的节点，Kubernetes 确保应用程序始终可用。
• 负载均衡：Kubernetes 内置了服务发现和负载均衡机制，可以有效地分配进入应用程序的流量，提高应用程序的响应速度和可靠性。
• 滚动更新：Kubernetes 支持无缝的滚动更新，可以在不中断服务的情况下逐步替换应用程序的实例，减少更新过程中的停机时间。
• 自我修复：Kubernetes 具有自我修复能力，能够监控应用程序的状态，并在发现问题时自动采取措施进行修复。
• 可扩展性：Kubernetes 的架构设计使得它非常容易扩展，可以从小规模的单节点集群扩展到大规模的多节点集群。
• 多环境支持：Kubernetes 支持多种环境，包括公有云、私有云和混合云，使得应用程序可以在不同的基础设施上运行。
• 社区支持：作为一个开源项目，Kubernetes 拥有一个活跃的社区，不断有新的功能和改进被加入，同时也有大量的文档和教程可供参考。
• 安全性：Kubernetes 提供了多种安全机制，包括网络策略、访问控制、密钥管理等，帮助保护应用程序和数据的安全。
• 灵活性：Kubernetes 支持多种容器运行时，允许开发者选择最适合他们应用程序的容器技术。
• 企业级应用：许多大型企业和组织都在使用 Kubernetes 来管理他们的应用程序，这证明了 Kubernetes 在企业级应用中的可靠性和有效性。

2： 正常运行的 Kubernetes 集群所需的各种组件

口述一下整体流程：

部署一个mysql他底层操作的所有流程，所有的操作都会和apiserver进行交互

1：命令行告诉master，我需要部署mysql数据库

2：接着请求交给master的apiserver网关，网关上报此次信息到etcd数据库

3：接着由apiserver网关，交给controller-mannager进行控制

4：controller-mannager进行部署

5：controller-mannager生成部署信息 mysql --image:mysql8 --port 3060.. 却不进行部署应用

6：之后controller-mannager把部署信息再次存入etcd数据库

7：scheduler调度器从etcd数据库拿到要部署的信息，开始进行调度，寻找合适的节点，

8：最后完成后，把信息存再次存回etcd数据库

9：每个节点node的监控者kubelet（就是节点的监工），随时和master保持联系，一直和apiserver 发送请求，获取最新数据。

10：假如node2上的kubelet 收到了信息，需要他来部署这个应用。

11：kubelet就会自己run一个pod在自己的机器上，随时汇报最新信息给master并分配ip。

---

node和master都是通过apiserver进行联系的。
所有机器上的kube-proxy 可以知道所有的网络，不管是node访问别人，还是别人来访问node,所有的流量转发都是通过kube-proxy 来进行代理。

控制平面组件（Control Plane Components）
控制平面组件会为集群做出全局决策，比如资源的调度。 以及检测和响应集群事件，例如当不满足部署的 replicas 字段时，要启动新的 Pod）。
控制平面组件可以在集群中的任何节点上运行。 然而，为了简单起见，设置脚本通常会在同一个计算机上启动所有控制平面组件， 并且不会在此计算机上运行用户容器。 请参阅 使用 kubeadm 构建高可用性集群 中关于跨多机器控制平面设置的示例。
kube-apiserver
API 服务器是 Kubernetes 控制平面的组件， 该组件负责公开了 Kubernetes API，负责处理接受请求的工作。 API 服务器是 Kubernetes 控制平面的前端。
Kubernetes API 服务器的主要实现是 kube-apiserver。 kube-apiserver 设计上考虑了水平扩缩，也就是说，它可通过部署多个实例来进行扩缩。 你可以运行 kube-apiserver 的多个实例，并在这些实例之间平衡流量。
etcd
一致且高可用的键值存储，用作 Kubernetes 所有集群数据的后台数据库。
如果你的 Kubernetes 集群使用 etcd 作为其后台数据库， 请确保你针对这些数据有一份 备份计划。
你可以在官方 文档中找到有关 etcd 的深入知识。
kube-scheduler
kube-scheduler 是 控制平面的组件， 负责监视新创建的、未指定运行 节点（node）的 Pods， 并选择节点来让 Pod 在上面运行。
调度决策考虑的因素包括单个 Pod 及 Pods 集合的资源需求、软硬件及策略约束、 亲和性及反亲和性规范、数据位置、工作负载间的干扰及最后时限。
kube-controller-manager
kube-controller-manager 是 控制平面的组件， 负责运行 控制器进程。
从逻辑上讲， 每个 控制器都是一个单独的进程， 但是为了降低复杂性，它们都被编译到同一个可执行文件，并在同一个进程中运行。
有许多不同类型的控制器。以下是一些例子：
节点控制器（Node Controller）：负责在节点出现故障时进行通知和响应
任务控制器（Job Controller）：监测代表一次性任务的 Job 对象，然后创建 Pod 来运行这些任务直至完成
端点分片控制器（EndpointSlice controller）：填充端点分片（EndpointSlice）对象（以提供 Service 和 Pod 之间的链接）。
服务账号控制器（ServiceAccount controller）：为新的命名空间创建默认的服务账号（ServiceAccount）。
以上并不是一个详尽的列表。
cloud-controller-manager
一个 Kubernetes 控制平面组件， 嵌入了特定于云平台的控制逻辑。 云控制器管理器（Cloud Controller Manager）允许将你的集群连接到云提供商的 API 之上， 并将与该云平台交互的组件同与你的集群交互的组件分离开来。
cloud-controller-manager 仅运行特定于云平台的控制器。 因此如果你在自己的环境中运行 Kubernetes，或者在本地计算机中运行学习环境， 所部署的集群不需要有云控制器管理器。
与 kube-controller-manager 类似， cloud-controller-manager 将若干逻辑上独立的控制回路组合到同一个可执行文件中， 供你以同一进程的方式运行。 你可以对其执行水平扩容（运行不止一个副本）以提升性能或者增强容错能力。
下面的控制器都包含对云平台驱动的依赖：
节点控制器（Node Controller）：用于在节点终止响应后检查云提供商以确定节点是否已被删除
路由控制器（Route Controller）：用于在底层云基础架构中设置路由
服务控制器（Service Controller）：用于创建、更新和删除云提供商负载均衡器
Node 组件
节点组件会在每个节点上运行，负责维护运行的 Pod 并提供 Kubernetes 运行环境。
kubelet
kubelet 会在集群中每个 节点（node）上运行。 它保证 容器（containers）都运行在 Pod 中。
kubelet 接收一组通过各类机制提供给它的 PodSpec，确保这些 PodSpec 中描述的容器处于运行状态且健康。 kubelet 不会管理不是由 Kubernetes 创建的容器。
kube-proxy
kube-proxy 是集群中每个 节点（node）上所运行的网络代理， 实现 Kubernetes 服务（Service） 概念的一部分。
kube-proxy 维护节点上的一些网络规则， 这些网络规则会允许从集群内部或外部的网络会话与 Pod 进行网络通信。
如果操作系统提供了可用的数据包过滤层，则 kube-proxy 会通过它来实现网络规则。 否则，kube-proxy 仅做流量转发。
容器运行时（Container Runtime）
这个基础组件使 Kubernetes 能够有效运行容器。 它负责管理 Kubernetes 环境中容器的执行和生命周期。
Kubernetes 支持许多容器运行环境，例如 containerd、 CRI-O 以及 Kubernetes CRI (容器运行环境接口) 的其他任何实现。
插件（Addons）
插件使用 Kubernetes 资源（ DaemonSet、 Deployment 等）实现集群功能。 因为这些插件提供集群级别的功能，插件中命名空间域的资源属于 kube-system 命名空间。
下面描述众多插件中的几种。有关可用插件的完整列表，请参见 插件（Addons）。
DNS
尽管其他插件都并非严格意义上的必需组件，但几乎所有 Kubernetes 集群都应该有 集群 DNS， 因为很多示例都需要 DNS 服务。
集群 DNS 是一个 DNS 服务器，和环境中的其他 DNS 服务器一起工作，它为 Kubernetes 服务提供 DNS 记录。
Kubernetes 启动的容器自动将此 DNS 服务器包含在其 DNS 搜索列表中。
Web 界面（仪表盘）
Dashboard 是 Kubernetes 集群的通用的、基于 Web 的用户界面。 它使用户可以管理集群中运行的应用程序以及集群本身， 并进行故障排除。
容器资源监控
容器资源监控 将关于容器的一些常见的时间序列度量值保存到一个集中的数据库中， 并提供浏览这些数据的界面。
集群层面日志
集群层面日志机制负责将容器的日志数据保存到一个集中的日志存储中， 这种集中日志存储提供搜索和浏览接口。
网络插件
网络插件 是实现容器网络接口（CNI）规范的软件组件。它们负责为 Pod 分配 IP 地址，并使这些 Pod 能在集群内部相互通信。

3：pod是啥

所谓pod就是容器的再次封装，是k8s的基本单位

Pod（容器组）是 k8s 集群上的最基本的单元。当我们在 k8s 上创建 Deployment 时，会在集群上创建包含容器的 Pod (而不是直接创建容器)。每个Pod都与运行它的 worker 节点（Node）绑定，并保持在那里直到终止或被删除。如果节点（Node）发生故障，则会在群集中的其他可用节点（Node）上运行相同的 Pod（从同样的镜像创建 Container，使用同样的配置，IP 地址不同，Pod 名字不同）。

举例：开发了一个代码实现重写了log4j的代码，如果log4代码变了，我的应用也要变，哪我就在里面加个中间人pod,两边都按照规则去进行，这样就不会造成别的代码修改，影响其他的代码。

java应用=pod（中间人） = 框架

假设你开发了一个应用程序，最初使用了 log4j 作为日志实现。随着时间的推移，可能需要切换到另一个日志框架，比如 logback。为了避免每次更换日志框架时都要修改大量的业务逻辑代码，你可以在你的代码中使用 slf4j 作为日志 API。这意味着所有的日志调用都将通过 slf4j 的 API 进行，而不是直接调用 log4j，当你需要更换日志框架时，只需更改依赖和配置文件，而无需修改业务逻辑代码。

4：Node

Pod（容器组）总是在 Node（节点） 上运行。Node（节点）是 kubernetes 集群中的计算机，可以是虚拟机或物理机。每个 Node（节点）都由 master 管理。一个 Node（节点）可以有多个Pod（容器组），kubernetes master 会根据每个 Node（节点）上可用资源的情况，自动调度 Pod（容器组）到最佳的 Node（节点）上。

每个 Kubernetes Node（节点）至少运行：

• Kubelet，负责 master 节点和 worker 节点之间通信的进程；管理 Pod（容器组）和 Pod（容器组）内运行的 Container（容器）。
• kube-proxy，负责进行流量转发
• 容器运行环境（如Docker）负责下载镜像、创建和运行容器等

Kubernetes安装

💡

docker每个机器都要安装

1.1：移除旧版本Docker

sudo yum remove docker*

1.2：设置docker yum源 设置aliyun比较快

sudo yum install -y yum-utils   --安装一些必要的工具，防止安装出错
sudo yum-config-manager --add-repo https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo

1.3：安装最新docker engine 新版本跟k8s不是很兼容，容易报错

#这里安装指定版本的
yum install -y docker-ce-3:19.03.9-3.el7.x86_64  docker-ce-cli-3:19.03.9-3.el7.x86_64 containerd.io

1.4：也可以指定版本docker engine

#找到所有可用docker版本列表
yum list docker-ce --showduplicates | sort -r
-----------
docker-ce.x86_64            3:23.0.1-1.el7                     docker-ce-stable 
docker-ce.x86_64            3:23.0.0-1.el7                     docker-ce-stable 
docker-ce.x86_64            3:20.10.9-3.el7                    docker-ce-stable 
docker-ce.x86_64            3:20.10.8-3.el7                    docker-ce-stable 
docker-ce.x86_64            3:20.10.7-3.el7                    docker-ce-stable 
docker-ce.x86_64            3:20.10.6-3.el7                    docker-ce-stable 
docker-ce.x86_64     >>>    3:20.10.5-3.el7                    docker-ce-stable 
docker-ce.x86_64            3:20.10.4-3.el7                    docker-ce-stable 
docker-ce.x86_64            3:20.10.3-3.el7                    docker-ce-stable 
docker-ce.x86_64            3:20.10.24-3.el7                   docker-ce-stable 
docker-ce.x86_64            3:20.10.2-3.el7                    docker-ce-stable 
docker-ce.x86_64            3:20.10.23-3.el7                   docker-ce-stable 
docker-ce.x86_64            3:20.10.22-3.el7                   docker-ce-stable
-----
# 安装指定版本，用上面的版本号替换<VERSION_STRING>  3:20.10.5-3.el7
sudo yum install docker-ce-<VERSION_STRING>.x86_64 docker-ce-cli-
<VERSION_STRING>.x86_64 containerd.io
#例如：
#yum install docker-ce-3:20.10.5-3.el7.x86_64 docker-ce-cli-3:20.10.5-
3.el7.x86_64 containerd.io
#注意加上 .x86_64 大版本号

1.5： 启动服务

systemctl start docker
systemctl enable docker

1.6： 配置镜像加速 这样拉取镜像会快一些

/etc/docker/daemon.json 是Docker的核心配置文件。sudo mkdir -p /etc/docker
sudo tee /etc/docker/daemon.json <<-'EOF'
{"registry-mirrors": ["https://hz0oi0rk.mirror.aliyuncs.com"]
}
EOF添加多种
sudo tee /etc/docker/daemon.json <<-EOF
{"registry-mirrors": ["https://hz0oi0rk.mirror.aliyuncs.com","https://docker.mirrors.ustc.edu.cn","https://registry.docker-cn.com","https://docker.mirrors.aliyun.com","https://docker.1panel.live","https://docker.211678.top","https://docker.m.daocloud.io","https://do.nark.eu.org","https://dockerpull.com","https://dockerproxy.cn","https://docker.awsl9527.cn","https://hub.rat.dev"]
}
EOFsudo systemctl daemon-reload    重启后台进程
sudo systemctl restart docker   重启docker

安装k8s核心组件（每台机器必备）

2.1 配置k8syum源

cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=http://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=0
repo_gpgcheck=0
gpgkey=http://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpghttp://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg
EOF

2.2 如果之前有安装过，就移除一下

yum remove -y kubelet kubeadm kubectl

2.3 查看当前可以安装的k8s版本

yum list kubelet --showduplicates | sort -r

2.4 安装kubelet、kubeadm、kubectl 指定版本

 yum install -y kubelet-1.21.0 kubeadm-1.21.0 kubectl-1.21.0

2.5 开机启动kubelet

systemctl enable kubelet && systemctl start kubelet

2.6 查看核心所需镜像 可以弄到自己仓库，国外镜像有些无法下载

kubeadm config images list 

2.7 脚本快速操作 每次机器都下载一遍

sudo tee ./images.sh <<-'EOF'
#!/bin/bash
images=(kube-apiserver:v1.21.0kube-proxy:v1.21.0kube-controller-manager:v1.21.0kube-scheduler:v1.21.0coredns:v1.8.0etcd:3.4.13-0pause:3.4.1
)
for imageName in ${images[@]} ; do
docker pull registry.cn-hangzhou.aliyuncs.com/lfy_k8s_images/$imageName
done
EOF

2.8 赋予执行权限，并启动脚本批量下载镜像

chmod +x ./images.sh && ./images.sh

2.9 k8s coredns镜像比较特殊（是一个多级目录的镜像），结合阿里云需要特殊处理，重新打标签，多目录标签

docker tag registry.cn-hangzhou.aliyuncs.com/lfy_k8s_images/coredns:v1.8.0 registry.cn-hangzhou.aliyuncs.com/lfy_k8s_images/coredns/coredns:v1.8.0

📌初始化 这一步在master执行

3.0 master初始化

# 注意根据自己ip需进行更改172.16.31.21
kubeadm init \
--apiserver-advertise-address=172.16.31.21 \
--image-repository registry.cn-hangzhou.aliyuncs.com/lfy_k8s_images \
--kubernetes-version v1.21.0 \
--service-cidr=10.96.0.0/16 \
--pod-network-cidr=192.168.0.0/16 --v=5    # pod的ip范围## --apiserver-advertise-address：用于控制平面内部通信，确保集群中的其他组件能够找到并连接到 kube-apiserver。
## --service-cidr：用于 Kubernetes 服务的虚拟 IP 地址，这些服务通常由 kube-proxy 管理，用于服务发现和负载均衡。
## --pod-network-cidr：用于 Pod 之间的通信，确保 Pod 可以在整个集群中自由通信，无论它们位于哪个节点上。#要求所有网络范围不重叠 --pod-network-cidr  --service-cidr --apiserver-advertise-address 都不能重叠#初始化失败执行这个，重新初始化
sudo kubeadm reset
sudo kubeadm init
#重新初始化报错，如下根据报错灵活选择
sudo rm -f /etc/kubernetes/manifests/kube-apiserver.yaml
sudo rm -f /etc/kubernetes/manifests/kube-controller-manager.yaml
sudo rm -f /etc/kubernetes/manifests/kube-scheduler.yaml
sudo rm -f /etc/kubernetes/manifests/etcd.yaml
sudo kubeadm reset
sudo systemctl restart kubelet
sudo systemctl restart containerd
sudo lsof -i :10250

3.1 master 初始化日志

I0716 23:16:09.034852    6166 initconfiguration.go:104] detected and using CRI socket: /var/run/dockershim.sock
[init] Using Kubernetes version: v1.21.0
[preflight] Running pre-flight checks
I0716 23:16:09.147485    6166 checks.go:577] validating Kubernetes and kubeadm version[WARNING KubernetesVersion]: Kubernetes version is greater than kubeadm version. Please consider to upgrade kubeadm. Kubernetes version: 1.21.0. Kubeadm version: 1.20.x
I0716 23:16:09.147595    6166 checks.go:166] validating if the firewall is enabled and active
I0716 23:16:09.154919    6166 checks.go:201] validating availability of port 6443
I0716 23:16:09.155021    6166 checks.go:201] validating availability of port 10259
I0716 23:16:09.155032    6166 checks.go:201] validating availability of port 10257
I0716 23:16:09.155046    6166 checks.go:286] validating the existence of file /etc/kubernetes/manifests/kube-apiserver.yaml
I0716 23:16:09.155053    6166 checks.go:286] validating the existence of file /etc/kubernetes/manifests/kube-controller-manager.yaml
I0716 23:16:09.155057    6166 checks.go:286] validating the existence of file /etc/kubernetes/manifests/kube-scheduler.yaml
I0716 23:16:09.155060    6166 checks.go:286] validating the existence of file /etc/kubernetes/manifests/etcd.yaml
I0716 23:16:09.155066    6166 checks.go:432] validating if the connectivity type is via proxy or direct
I0716 23:16:09.155106    6166 checks.go:471] validating http connectivity to first IP address in the CIDR
I0716 23:16:09.155119    6166 checks.go:471] validating http connectivity to first IP address in the CIDR
I0716 23:16:09.155125    6166 checks.go:102] validating the container runtime
I0716 23:16:09.227451    6166 checks.go:128] validating if the "docker" service is enabled and active[WARNING IsDockerSystemdCheck]: detected "cgroupfs" as the Docker cgroup driver. The recommended driver is "systemd". Please follow the guide at https://kubernetes.io/docs/setup/cri/
I0716 23:16:09.336219    6166 checks.go:335] validating the contents of file /proc/sys/net/bridge/bridge-nf-call-iptables
I0716 23:16:09.336306    6166 checks.go:335] validating the contents of file /proc/sys/net/ipv4/ip_forward
I0716 23:16:09.336330    6166 checks.go:649] validating whether swap is enabled or not
I0716 23:16:09.336345    6166 checks.go:376] validating the presence of executable conntrack
I0716 23:16:09.336363    6166 checks.go:376] validating the presence of executable ip
I0716 23:16:09.336369    6166 checks.go:376] validating the presence of executable iptables
I0716 23:16:09.336377    6166 checks.go:376] validating the presence of executable mount
I0716 23:16:09.336384    6166 checks.go:376] validating the presence of executable nsenter
I0716 23:16:09.336391    6166 checks.go:376] validating the presence of executable ebtables
I0716 23:16:09.336396    6166 checks.go:376] validating the presence of executable ethtool
I0716 23:16:09.336401    6166 checks.go:376] validating the presence of executable socat
I0716 23:16:09.336407    6166 checks.go:376] validating the presence of executable tc
I0716 23:16:09.336411    6166 checks.go:376] validating the presence of executable touch
I0716 23:16:09.336419    6166 checks.go:520] running all checks
I0716 23:16:09.417428    6166 checks.go:406] checking whether the given node name is reachable using net.LookupHost
I0716 23:16:09.417790    6166 checks.go:618] validating kubelet version
I0716 23:16:09.501007    6166 checks.go:128] validating if the "kubelet" service is enabled and active
I0716 23:16:09.506921    6166 checks.go:201] validating availability of port 10250
I0716 23:16:09.506963    6166 checks.go:201] validating availability of port 2379
I0716 23:16:09.506972    6166 checks.go:201] validating availability of port 2380
I0716 23:16:09.506987    6166 checks.go:249] validating the existence and emptiness of directory /var/lib/etcd
[preflight] Pulling images required for setting up a Kubernetes cluster
[preflight] This might take a minute or two, depending on the speed of your internet connection
[preflight] You can also perform this action in beforehand using 'kubeadm config images pull'
I0716 23:16:09.540280    6166 checks.go:839] image exists: registry.cn-hangzhou.aliyuncs.com/lfy_k8s_images/kube-apiserver:v1.21.0
I0716 23:16:09.579551    6166 checks.go:839] image exists: registry.cn-hangzhou.aliyuncs.com/lfy_k8s_images/kube-controller-manager:v1.21.0
I0716 23:16:09.615551    6166 checks.go:839] image exists: registry.cn-hangzhou.aliyuncs.com/lfy_k8s_images/kube-scheduler:v1.21.0
I0716 23:16:09.651421    6166 checks.go:839] image exists: registry.cn-hangzhou.aliyuncs.com/lfy_k8s_images/kube-proxy:v1.21.0
I0716 23:16:09.692049    6166 checks.go:839] image exists: registry.cn-hangzhou.aliyuncs.com/lfy_k8s_images/pause:3.2
I0716 23:16:09.734836    6166 checks.go:839] image exists: registry.cn-hangzhou.aliyuncs.com/lfy_k8s_images/etcd:3.4.13-0
I0716 23:16:09.779173    6166 checks.go:839] image exists: registry.cn-hangzhou.aliyuncs.com/lfy_k8s_images/coredns:1.7.0
[certs] Using certificateDir folder "/etc/kubernetes/pki"
I0716 23:16:09.779231    6166 certs.go:110] creating a new certificate authority for ca
[certs] Generating "ca" certificate and key
I0716 23:16:09.936554    6166 certs.go:474] validating certificate period for ca certificate
[certs] Generating "apiserver" certificate and key
[certs] apiserver serving cert is signed for DNS names [kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local master] and IPs [10.96.0.1 172.16.31.21]
[certs] Generating "apiserver-kubelet-client" certificate and key
I0716 23:16:10.049704    6166 certs.go:110] creating a new certificate authority for front-proxy-ca
[certs] Generating "front-proxy-ca" certificate and key
I0716 23:16:10.221141    6166 certs.go:474] validating certificate period for front-proxy-ca certificate
[certs] Generating "front-proxy-client" certificate and key
I0716 23:16:10.262809    6166 certs.go:110] creating a new certificate authority for etcd-ca
[certs] Generating "etcd/ca" certificate and key
I0716 23:16:10.324995    6166 certs.go:474] validating certificate period for etcd/ca certificate
[certs] Generating "etcd/server" certificate and key
[certs] etcd/server serving cert is signed for DNS names [localhost master] and IPs [172.16.31.21 127.0.0.1 ::1]
[certs] Generating "etcd/peer" certificate and key
[certs] etcd/peer serving cert is signed for DNS names [localhost master] and IPs [172.16.31.21 127.0.0.1 ::1]
[certs] Generating "etcd/healthcheck-client" certificate and key
[certs] Generating "apiserver-etcd-client" certificate and key
I0716 23:16:11.016517    6166 certs.go:76] creating new public/private key files for signing service account users
[certs] Generating "sa" key and public key
[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
I0716 23:16:11.133874    6166 kubeconfig.go:101] creating kubeconfig file for admin.conf
[kubeconfig] Writing "admin.conf" kubeconfig file
I0716 23:16:11.345718    6166 kubeconfig.go:101] creating kubeconfig file for kubelet.conf
[kubeconfig] Writing "kubelet.conf" kubeconfig file
I0716 23:16:11.504030    6166 kubeconfig.go:101] creating kubeconfig file for controller-manager.conf
[kubeconfig] Writing "controller-manager.conf" kubeconfig file
I0716 23:16:11.594761    6166 kubeconfig.go:101] creating kubeconfig file for scheduler.conf
[kubeconfig] Writing "scheduler.conf" kubeconfig file
I0716 23:16:11.837787    6166 kubelet.go:63] Stopping the kubelet
[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet-start] Starting the kubelet
[control-plane] Using manifest folder "/etc/kubernetes/manifests"
[control-plane] Creating static Pod manifest for "kube-apiserver"
I0716 23:16:11.899153    6166 manifests.go:96] [control-plane] getting StaticPodSpecs
I0716 23:16:11.899421    6166 certs.go:474] validating certificate period for CA certificate
I0716 23:16:11.899476    6166 manifests.go:109] [control-plane] adding volume "ca-certs" for component "kube-apiserver"
I0716 23:16:11.899481    6166 manifests.go:109] [control-plane] adding volume "etc-pki" for component "kube-apiserver"
I0716 23:16:11.899484    6166 manifests.go:109] [control-plane] adding volume "k8s-certs" for component "kube-apiserver"
I0716 23:16:11.907571    6166 manifests.go:126] [control-plane] wrote static Pod manifest for component "kube-apiserver" to "/etc/kubernetes/manifests/kube-apiserver.yaml"
[control-plane] Creating static Pod manifest for "kube-controller-manager"
I0716 23:16:11.907594    6166 manifests.go:96] [control-plane] getting StaticPodSpecs
I0716 23:16:11.907969    6166 manifests.go:109] [control-plane] adding volume "ca-certs" for component "kube-controller-manager"
I0716 23:16:11.907982    6166 manifests.go:109] [control-plane] adding volume "etc-pki" for component "kube-controller-manager"
I0716 23:16:11.907985    6166 manifests.go:109] [control-plane] adding volume "flexvolume-dir" for component "kube-controller-manager"
I0716 23:16:11.907988    6166 manifests.go:109] [control-plane] adding volume "k8s-certs" for component "kube-controller-manager"
I0716 23:16:11.907990    6166 manifests.go:109] [control-plane] adding volume "kubeconfig" for component "kube-controller-manager"
I0716 23:16:11.909522    6166 manifests.go:126] [control-plane] wrote static Pod manifest for component "kube-controller-manager" to "/etc/kubernetes/manifests/kube-controller-manager.yaml"
[control-plane] Creating static Pod manifest for "kube-scheduler"
I0716 23:16:11.909541    6166 manifests.go:96] [control-plane] getting StaticPodSpecs
I0716 23:16:11.909781    6166 manifests.go:109] [control-plane] adding volume "kubeconfig" for component "kube-scheduler"
I0716 23:16:11.910495    6166 manifests.go:126] [control-plane] wrote static Pod manifest for component "kube-scheduler" to "/etc/kubernetes/manifests/kube-scheduler.yaml"
[etcd] Creating static Pod manifest for local etcd in "/etc/kubernetes/manifests"
I0716 23:16:11.910988    6166 local.go:74] [etcd] wrote Static Pod manifest for a local etcd member to "/etc/kubernetes/manifests/etcd.yaml"
I0716 23:16:11.910999    6166 waitcontrolplane.go:87] [wait-control-plane] Waiting for the API server to be healthy
[wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests". This can take up to 4m0s
[apiclient] All control plane components are healthy after 6.502556 seconds
I0716 23:16:18.414773    6166 uploadconfig.go:108] [upload-config] Uploading the kubeadm ClusterConfiguration to a ConfigMap
[upload-config] Storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
I0716 23:16:18.434288    6166 uploadconfig.go:122] [upload-config] Uploading the kubelet component config to a ConfigMap
[kubelet] Creating a ConfigMap "kubelet-config-1.21" in namespace kube-system with the configuration for the kubelets in the cluster
I0716 23:16:18.443537    6166 uploadconfig.go:127] [upload-config] Preserving the CRISocket information for the control-plane node
I0716 23:16:18.443554    6166 patchnode.go:30] [patchnode] Uploading the CRI Socket information "/var/run/dockershim.sock" to the Node API object "master" as an annotation
[upload-certs] Skipping phase. Please see --upload-certs
[mark-control-plane] Marking the node master as control-plane by adding the labels "node-role.kubernetes.io/master=''" and "node-role.kubernetes.io/control-plane='' (deprecated)"
[mark-control-plane] Marking the node master as control-plane by adding the taints [node-role.kubernetes.io/master:NoSchedule]
[bootstrap-token] Using token: nohjt3.812p870l8p88xbwi
[bootstrap-token] Configuring bootstrap tokens, cluster-info ConfigMap, RBAC Roles
[bootstrap-token] configured RBAC rules to allow Node Bootstrap tokens to get nodes
[bootstrap-token] configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
[bootstrap-token] configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
[bootstrap-token] configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
[bootstrap-token] Creating the "cluster-info" ConfigMap in the "kube-public" namespace
I0716 23:16:19.481680    6166 clusterinfo.go:45] [bootstrap-token] loading admin kubeconfig
I0716 23:16:19.481895    6166 clusterinfo.go:53] [bootstrap-token] copying the cluster from admin.conf to the bootstrap kubeconfig
I0716 23:16:19.482072    6166 clusterinfo.go:65] [bootstrap-token] creating/updating ConfigMap in kube-public namespace
I0716 23:16:19.485123    6166 clusterinfo.go:79] creating the RBAC rules for exposing the cluster-info ConfigMap in the kube-public namespace
I0716 23:16:19.488357    6166 kubeletfinalize.go:88] [kubelet-finalize] Assuming that kubelet client certificate rotation is enabled: found "/var/lib/kubelet/pki/kubelet-client-current.pem"
[kubelet-finalize] Updating "/etc/kubernetes/kubelet.conf" to point to a rotatable kubelet client certificate and key
I0716 23:16:19.488912    6166 kubeletfinalize.go:132] [kubelet-finalize] Restarting the kubelet to enable client certificate rotation
[addons] Applied essential addon: CoreDNS
I0716 23:16:19.852418    6166 request.go:591] Throttling request took 196.767727ms, request: POST:https://172.16.31.21:6443/api/v1/namespaces/kube-system/configmaps?timeout=10s
[addons] Applied essential addon: kube-proxyYour Kubernetes control-plane has initialized successfully!To start using your cluster, you need to run the following as a regular user:mkdir -p $HOME/.kubesudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/configsudo chown $(id -u):$(id -g) $HOME/.kube/configAlternatively, if you are the root user, you can run:export KUBECONFIG=/etc/kubernetes/admin.confYou should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:https://kubernetes.io/docs/concepts/cluster-administration/addons/Then you can join any number of worker nodes by running the following on each as root:kubeadm join 172.16.31.21:6443 --token nohjt3.812p870l8p88xbwi \--discovery-token-ca-cert-hash sha256:642a40feae03609775fa79444ed73dc83684caca1400bb4ceaaba4d55b45b383

3.2 执行下面日志提示命令

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
#设置环境变量
export KUBECONFIG=/etc/kubernetes/admin.conf

3.3 安装calico（网络插件） （也是master执行）

curl https://calico-v3-25.netlify.app/archive/v3.25/manifests/calico.yaml -O

kubectl apply -f ./calico.yaml

3.4 获取集群所有的pod

kubectl get pod -A

3.5 查看集群机器的状态

kubectl get nodes

至此，大工告成。

3.6 把server01和server02加入集群

kubeadm join 172.16.31.21:6443 --token nohjt3.812p870l8p88xbwi \--discovery-token-ca-cert-hash sha256:642a40feae03609775fa79444ed73dc83684caca1400bb4ceaaba4d55b45b383

kubeadm token create --print-join-command

重新获取加入join

#k8s集群重启后，机器会自己加入到集群。
sudo systemctl stop kubelet
sudo systemctl stop kube-apiserver
sudo systemctl stop kube-controller-manager
sudo systemctl stop kube-scheduler
sudo systemctl stop etcd

3： kubernetes 基本操作

0 ：打标签

查看标签

kubectl get pod --show-labels

其他查看方式同理

给其他2台机器打上节点打标签

kubectl label node server01 node-role.kubernetes.io/worker='abc01'
kubectl label node server02 node-role.kubernetes.io/worker='abc02'
# -号是删除标签
kubectl label node server01 node-role.kubernetes.io/worker- 

pod打标签

修改前

修改后

#打标签
kubectl label pod nginx01-67fdf8d7c7-6dkl9 abc=123
#修改标签
kubectl label pod nginx01-67fdf8d7c7-6dkl9 --overwrite abc=1234
deployment 修改标签同理

1 ：设置ipvs模式

k8s默认用的iptables，性能不好 （kube-proxy在集群之间同步iptables的内容）

kubectl get all -A

编辑 修改ipvs模式 cm 即是configmap 记得重启生效

#修改ipvs
kubectl edit cm kube-proxy -n kube-system

杀死pod，新的pod就会自动启动

-n 命名空间

kubectl delete pod kube-proxy-b6cgd -n kube-system
kubectl delete pod kube-proxy-n9th6 -n kube-system
kubectl delete pod kube-proxy-tf9qh -n kube-system

如图：已生成新的pod

2：获取所有pod资源详细信息

-o wide 获取详细信息

-A 获取所有

kubectl get pod -A -o wide
也可以简写
kubectl get pod -A -owide

3： 部署简单的应用

部署一个简单的nginx

deployment 部署

kubectl create deployment nginx01 --image=nginx

查看部署

kubectl get deploy

部署的pod

kubectl get pod

我们创建了一个nginx01部署，起了一个nginx01-67fdf8d7c7-sgm5k pod

4： kubernetes 进阶操作

Kubelet启动的Pod每个都有Ip，全集群任意位置均可访问

前面我们集群master初始化的时间就指定过pod的ip范围

kubeadm init \
--apiserver-advertise-address=172.16.31.21 \
--image-repository registry.cn-hangzhou.aliyuncs.com/lfy_k8s_images \
--kubernetes-version v1.21.0 \
--service-cidr=10.96.0.0/16 \
--pod-network-cidr=192.168.0.0/16 --v=5    # pod的ip范围

4.0：kubectl create deployment 命令

deployment 将指示 k8s 如何创建和更新应用程序的实例

如果运行实例的 worker 节点关机或被删除，则 Kubernetes Deployment Controller 将在群集中资源最优的另一个 worker 节点上重新创建一个新的实例。这提供了一种自我修复机制来解决机器故障或维护问题。

#启动一个Pod，以及记录这次部署信息。
所以，这个pod即使挂了，这次部署信息有，就会强制同步到这次部署信息期望的最终结果，
kubectl create deployment nginx01 --image=nginx
#创建3个pod
kubectl create deployment nginx01 --image=nginx  --replicas=3

pod其实就是在docker上的容器

可以看到刚刚起的pod运行在server01节点上，我们去看看

docker ps 

看这个就是我们部署的哪个nginx01

拆分组成部分

拆分组成部分  
k8s_镜像名（nginx）_pod名字（nginx01-67fdf8d7c7-sgm5k）_容器名（default_b733c010-d7b2-4353-adf4-dce47f30a9bf_2）
几部分组成了一个完整的容器名字
k8s_nginx_nginx01-67fdf8d7c7-sgm5k_default_b733c010-d7b2-4353-adf4-dce47f30a9bf_2

4.1：显示资源列表

获取类型为Deployment的资源列表

kubectl get deployments

4.2： 获取类型为Pod的资源列表

kubectl get pods

4.3：获取类型为Node的资源列表

kubectl get nodes

4.4： 查看所有名称空间的 Deployment

kubectl get deployments -A
kubectl get deployments --all-namespaces

4.5： 查看指定名称空间的 Deployment

-n 指定命名空间

4.6： 查看在命名空间的对象

kubectl api-resources --namespaced=true

4.7：查看不在命名空间的对象

kubectl api-resources --namespaced=false

4.8： 显示资源的详细信息

#查看nginx01-67fdf8d7c7-sgm5k    此pod的详细信息
#可以看到各种详细信息
kubectl describe pod nginx01-67fdf8d7c7-sgm5k

获取deployment的应用，然后查看deployment应用的详情

kubectl get deploy
kubectl describe deployment nginx01

4.9： 查看pod的日志

kubectl get podkubectl logs  nginx01-67fdf8d7c7-sgm5k
#-f 实时监控最新日志
kubectl logs  -f nginx01-67fdf8d7c7-sgm5k  
#查看后4行日志
kubectl logs  --tail 4 nginx01-67fdf8d7c7-sgm5k

4.10：进入pod的命令行终端

kubectl exec -it  nginx01-67fdf8d7c7-sgm5k -- /bin/bash

4.11： run命令

这种运行起来不会产生一次部署信息，pod挂了不会自愈

kubectl run nginx02 --image=ingex

4.12： 组合命令 查看deploy和pod信息

kubectl get deploy,pod

4.13： kubectl delete 操作

如果有命名空间  -n指定
#删除deploy部署信息
kubectl delete deploy nginx01
#删除一个pod -n指定命名空间同理
kubectl delete pod nginx01-67fdf8d7c7-sgm5k
#删除多个 pod同理
kubectl delete  deploy nginx04 nginx05

4.14：持续监控

watch -n 1 kubectl get pods

5： 服务外部可见

Kubernetes Pod 是转瞬即逝的。 Pod 拥有 生命周期。 当一个工作节点挂掉后, 在节点上运行的 Pod 也会消亡。 ReplicaSet 会自动地通过创建新的 Pod 驱动集群回到目标状态，以保证应用正常运行。 换一个例子，考虑一个具有 3 个副本的用作图像处理的后端程序。 这些副本是可替换的。前端系统不应该关心后端副本，即使某个 Pod 丢失或被重新创建。

此外，Kubernetes 集群中的每个 Pod 都有一个唯一的 IP 地址，即使是在同一个 Node 上的 Pod 也是如此， 因此需要一种方法来自动协调 Pod 之间的变化，以便应用保持运行。

Kubernetes 中的服务（Service）是一种抽象概念，它定义了 Pod 的逻辑集和访问 Pod 的协议。 Service 使从属 Pod 之间的松耦合成为可能。 和所有 Kubernetes 对象清单一样, Service 用 YAML 或者 JSON 来定义。 Service 下的一组 Pod 通常由一个 标签选择算符 来标记 （请参阅下面的说明为什么你可能想要一个 spec 中不包含 selector 的 Service）。

尽管每个 Pod 都有一个唯一的 IP 地址，但是如果没有 Service，这些 IP 不会被公开到集群外部。 Service 允许你的应用接收流量。 通过设置 Service 的 spec 中的 type，你可以用不同的方式公开 Service：

#查看当前集群的service 简称svc
kubectl get svc
同
kubectl get services

我们在初始化集群的时候已经指定了svc的ip范围

5.1: 服务类型

• ClusterIP（默认）- 在集群的内部 IP 上公开 Service。这种类型使得 Service 只能从集群内访问。
• NodePort - 使用 NAT 在集群中每个选定 Node 的相同端口上公开 Service 。使用<NodeIP>:<NodePort> 从集群外部访问 Service。是 ClusterIP 的超集。
• LoadBalancer - 在当前云中创建一个外部负载均衡器（如果支持的话），并为 Service 分配一个固定的外部IP。是 NodePort 的超集。
• ExternalName - 将 Service 映射到 externalName 字段的内容（例如 foo.bar.example.com），通过返回带有该名称的 CNAME 记录实现。不设置任何类型的代理。这种类型需要 kube-dns 的 v1.7 或更高版本，或者 CoreDNS 的 0.8 或更高版本。

5.2：Service 和 Label

Service 为一组 Pod 提供流量路由。Service 是一种抽象，允许 Kubernetes 中的 Pod 死亡和复制，而不会影响应用。 在依赖的 Pod（如应用中的前端和后端组件）之间进行发现和路由是由 Kubernetes Service 处理的。

Service 通过标签和选择算符来匹配一组 Pod， 它们是允许对 Kubernetes 中的对象进行逻辑操作的一种分组原语。 标签是附加在对象上的键/值对，可以以多种方式使用：

• 指定用于开发、测试和生产的对象
• 嵌入版本标记
• 使用标记将对象分类

标签可以在对象创建时或之后附加到对象上。它们可以随时被修改。现在使用 Service 发布为我们的应用并添加一些标签。

5.3 ：kubectl expose

查看pod的默认标签

这里我们创建一个nginx01的service

 kubectl expose deployment nginx01 --port=8081 --target-port=80 --type=NodePort

--target-port： pod容器的端口 80
--port：集群内访问service的端口 8081--nodePort： 每个机器开发的端口 31275

5.3.1：这里启动了3个pod,并修改了默认的nginx访问页，用来区分，请求在那台机器上

5.4：删除service

5.5：查看服务

kubectl get svc

10.96.67.167:8081 为 ClusterIP

172.16.31.21:31275 为 NodePort

已经负载均衡了

6：扩缩容deployment

6.1:手动扩容

kubectl scale --replicas=3 deploy/nginx01

6.2:手动缩容

kubectl scale --replicas=1 deploy/nginx01

7： 在线滚动升级

滚动更新 允许通过使用新的实例逐步更新 Pod 实例，实现零停机的 Deployment 更新。 新的 Pod 将被调度到具有可用资源的节点上。

7.1：查看pod容器名字

kubectl get pod nginx01-67fdf8d7c7-6dkl9 -o yaml | grep name

7.2：查看镜像

kubectl get pod nginx01-67fdf8d7c7-6dkl9 -o yaml | grep image

7.3： 执行镜像更新

#--record 可以记录变更信息部署名   容器名   镜像名
kubectl set image deploy nginx01 nginx=nginx1.9.1 --record

会启动一个新的，然后启动成功，移除旧的，依次重复，更新掉所有pod

7.4： 查看历史记录

kubectl rollout history deploy nginx01

7.5：回滚到指定版本

kubectl rollout undo deploy nginx01 --to-revision=3

7.6： 配置文件形式部署应用

apiVersion: apps/v1#与k8s集群版本有关，使用 kubectl api-versions 即可查看当前集群支持的版本
kind: Deployment#该配置的类型，我们使用的是 Deployment
metadata:        #译名为元数据，即 Deployment 的一些基本属性和信息name: nginx-的mo#Deployment 的名称labels:    #标签，可以灵活定位一个或多个资源，其中key和value均可自定义，可以定义多组，目前不需要理解app: nginx#为该Deployment设置key为app，value为nginx的标签
spec:        #这是关于该Deployment的描述，可以理解为你期待该Deployment在k8s中如何使用replicas: 8 #使用该Deployment创建一个应用程序实例selector:    #标签选择器，与上面的标签共同作用，目前不需要理解matchLabels: #选择包含标签app:nginx的资源app: nginxtemplate:    #这是选择或创建的Pod的模板metadata:#Pod的元数据labels:#Pod的标签，上面的selector即选择包含标签app:nginx的Podapp: nginxspec:    #期望Pod实现的功能（即在pod中部署）containers:#生成container，与docker中的container是同一种- name: nginx#container的名称image: nginx:1.7.9#使用镜像nginx:1.7.9创建container，该container默认80端口可访问

7.5.1：应用文件

kubectl apply -f ./deploy.yaml

查看部署的应用和pod

如果需要增加pod和更新进行镜像只需要更改yaml文件，之后重新应用即可

7.5.2：移除这个文件部署的所有东西

kubectl delete -f deploy.yaml

8： 安装官方 Dashboard

Dashboard 是基于网页的 Kubernetes 用户界面。 你可以使用 Dashboard 将容器应用部署到 Kubernetes 集群中，也可以对容器应用排错，还能管理集群资源。 你可以使用 Dashboard 获取运行在集群中的应用的概览信息，也可以创建或者修改 Kubernetes 资源 （如 Deployment、Job、DaemonSet 等等）。 例如，你可以对 Deployment 实现弹性伸缩、发起滚动升级、重启 Pod 或者使用向导创建新的应用。

Dashboard 同时展示了 Kubernetes 集群中的资源状态信息和所有报错信息。

8.1：下载yaml文件

wget https://raw.githubusercontent.com/kubernetes/dashboard/v2.2.0/aio/deploy/recommended.yaml

8.2：下载文件修改这个，暴露外部ip

8.3：应用yaml文件

kubectl apply -f ./recommended.yaml

8.4 查看pod的状态

kubectl get pod -A

8.5：查看网络服务，主机ip加端口访问

8.6：创建示例用户

#创建服务帐号 我们首先admin-user在命名空间中创建具有名称的服务帐户。kubernetes-dashboard
vi admin-user.yaml

apiVersion: v1
kind: ServiceAccount
metadata:name: admin-usernamespace: kubernetes-dashboard

kubectl apply  -f ./admin-user.yaml

#创建 ClusterRoleBinding 在大多数情况下，使用kops或kubeadm任何其他流行工具配置集群后，ClusterRole cluster-admin集群中已经存在。我们可以使用它并仅为ClusterRoleBinding我们的创建ServiceAccount。如果它不存在，那么您需要先创建此角色并手动授予所需的权限。vi dashboard-adminuser.yaml

apiVersion: v1
kind: ServiceAccount
metadata:name: admin-usernamespace: kubernetes-dashboard
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:name: admin-user
roleRef:apiGroup: rbac.authorization.k8s.iokind: ClusterRolename: cluster-admin
subjects:
- kind: ServiceAccountname: admin-usernamespace: kubernetes-dashboard

8.4：执行创建资源

kubectl create --save-config -f ./dashboard-adminuser.yaml

8.5： 获取令牌

kubectl -n kubernetes-dashboard describe secret $(kubectl -n kubernetes-dashboard get secret | grep admin-user | awk '{print $1}')
#也可以直接获取想要的
kubectl -n kubernetes-dashboard get secret $(kubectl -n kubernetes-dashboard get sa/admin-user -o jsonpath="{.secrets[0].name}") -o go-template="{{.data.token | base64decode}}"

8.6：输入后成功进入

https://172.16.31.21:30353/

8.7：删除管理员ServiceAccount和ClusterRoleBinding

kubectl -n kubernetes-dashboard delete serviceaccount admin-user
kubectl -n kubernetes-dashboard delete clusterrolebinding admin-user