第一部分:Kubernetes 基础
第一章:容器技术概述
1.1 容器技术的诞生背景
在软件开发领域,“依赖地狱” 一直是困扰开发者的难题。不同的应用程序可能需要不同版本的库、框架和运行环境,在同一台服务器上部署和管理这些应用变得异常复杂。传统的虚拟机技术虽然提供了一定程度的隔离,但也带来了资源占用高、启动速度慢等问题。
容器技术 的出现为解决这些问题提供了新的思路。容器是一种轻量级的虚拟化技术,它可以将应用程序及其所有依赖项打包在一起,形成一个独立的、可移植的运行环境。与虚拟机相比,容器共享主机操作系统内核,因此更加轻量级、启动速度更快、资源利用率更高。
容器技术的优势:
-
轻量级: 容器共享主机操作系统内核,无需为每个应用加载完整的操作系统,因此更加轻量级,资源占用更少。
-
快速启动: 容器启动速度非常快,通常只需几秒钟,而虚拟机则需要几分钟。
-
可移植性: 容器镜像包含了应用运行所需的所有依赖项,因此可以在不同的环境中轻松部署和运行。
-
隔离性: 容器之间相互隔离,一个容器的故障不会影响其他容器的运行。
-
高效性: 容器可以更高效地利用系统资源,提高服务器利用率。
1.2 Docker 简介
Docker 是目前最流行的容器技术平台,它提供了一套完整的工具链,用于构建、分发和运行容器。
Docker 的核心概念:
-
镜像 (Image): 镜像是容器运行的基础,它包含了应用运行所需的所有文件系统、库和依赖项。
-
容器 (Container): 容器是镜像的运行实例,它是一个独立的、隔离的运行环境。
-
仓库 (Registry): 仓库用于存储和分享 Docker 镜像,Docker Hub 是最常用的公共仓库。
Docker 的优势:
-
简单易用: Docker 提供了简单易用的命令行工具,用户可以轻松地构建、运行和管理容器。
-
社区活跃: Docker 拥有庞大的用户社区和丰富的生态系统,用户可以轻松找到所需的资源和支持。
-
跨平台: Docker 支持多种操作系统平台,包括 Linux、Windows 和 macOS。
1.3 容器编排的需求
随着容器技术的普及,越来越多的应用被容器化。然而,在生产环境中管理大量的容器实例面临着新的挑战:
-
如何高效地调度和部署容器?
-
如何保证容器应用的高可用性和可扩展性?
-
如何管理容器之间的网络通信和存储?
容器编排工具 应运而生,它可以帮助用户自动化地管理容器化应用的部署、扩展、网络和存储等。
常见的容器编排工具:
-
Kubernetes: 目前最流行的容器编排工具,功能强大,社区活跃。
-
Docker Swarm: Docker 官方提供的容器编排工具,简单易用。
-
Apache Mesos: 分布式系统内核,可以用于容器编排。
容器编排工具的优势:
-
自动化: 自动化容器的部署、扩展、网络和存储管理,降低运维成本。
-
高可用性: 提供容器的健康检查、故障恢复和负载均衡等功能,保证应用的高可用性。
-
可扩展性: 支持容器的水平扩展,轻松应对业务增长。
总结:
容器技术为应用开发和部署带来了革命性的变化,而容器编排工具则进一步简化了容器化应用的管理。Kubernetes 作为目前最流行的容器编排工具,已经成为云原生时代的基石。在接下来的章节中,我们将深入学习 Kubernetes 的核心概念、架构和使用方法。
第二章:Kubernetes 简介
2.1 Kubernetes 的诞生和发展
Kubernetes 的故事始于 Google,这家科技巨头在运行其庞大的搜索引擎和其他服务时,面临着管理数以百万计的容器的挑战。为了应对这一挑战,Google 开发了内部系统 Borg,用于自动化部署、扩展和管理容器化应用。Borg 的成功经验催生了 Kubernetes 项目,并于 2014 年由 Google 开源。
Kubernetes 的发展历程:
-
2014 年: Kubernetes 由 Google 开源。
-
2015 年: 云原生计算基金会 (CNCF) 成立,Kubernetes 成为其首个托管项目。
-
2016 年: Kubernetes 1.0 版本发布,标志着其生产就绪。
-
2017 年至今: Kubernetes 持续快速发展,成为容器编排领域的事实标准。
Kubernetes 的快速发展得益于以下因素:
-
强大的功能和灵活性: Kubernetes 提供了丰富的功能,可以满足各种应用场景的需求。
-
活跃的社区和生态系统: Kubernetes 拥有庞大的用户社区和丰富的生态系统,用户可以轻松找到所需的资源和支持。
-
云原生时代的到来: 云原生应用的兴起推动了 Kubernetes 的普及,Kubernetes 成为构建和管理云原生应用的首选平台。
2.2 Kubernetes 的优势和特点
Kubernetes 作为容器编排领域的领导者,拥有以下优势和特点:
-
自动化: Kubernetes 可以自动化容器的部署、扩展、网络和存储管理,降低运维成本。
-
高可用性: Kubernetes 提供容器的健康检查、故障恢复和负载均衡等功能,保证应用的高可用性。
-
可扩展性: Kubernetes 支持容器的水平扩展,轻松应对业务增长。
-
可移植性: Kubernetes 可以运行在各种基础设施上,包括公有云、私有云和混合云。
-
声明式 API: Kubernetes 使用声明式 API 来管理应用,用户只需描述应用的期望状态,Kubernetes 会自动将其调整为实际状态。
-
丰富的生态系统: Kubernetes 拥有庞大的生态系统,提供了各种工具和服务,可以满足各种应用场景的需求。
2.3 Kubernetes 的架构概述
Kubernetes 采用主从架构,主要由以下组件组成:
-
Master 节点: 负责管理整个集群,包括调度、API 服务和资源管理等。
-
API Server: 提供 Kubernetes API,是用户与集群交互的入口。
-
Scheduler: 负责将 Pod 调度到合适的 Node 上运行。
-
Controller Manager: 负责维护集群的状态,例如副本数、节点状态等。
-
etcd: 分布式键值存储,用于存储集群的所有数据。
-
-
Node 节点: 负责运行容器,每个 Node 上运行着以下组件:
-
kubelet: 负责与 Master 节点通信,并管理 Pod 的生命周期。
-
kube-proxy: 负责为 Pod 提供网络代理服务。
-
Container Runtime: 负责运行容器,例如 Docker、containerd 等。
-
Kubernetes 的工作流程:
-
用户通过 kubectl 命令行工具或 API 向 Kubernetes 提交应用部署请求。
-
API Server 接收请求并将其存储在 etcd 中。
-
Scheduler 根据资源情况和调度策略,将 Pod 调度到合适的 Node 上。
-
kubelet 接收到调度指令后,会从镜像仓库拉取镜像并启动容器。
-
kube-proxy 会为 Pod 配置网络,使其能够与其他 Pod 通信。
-
Controller Manager 会持续监控集群状态,并根据需要进行调整,例如创建新的 Pod 副本以替换故障的 Pod。
总结:
Kubernetes 是一个功能强大、灵活且可扩展的容器编排平台,它可以帮助用户轻松地管理和运行容器化应用。在接下来的章节中,我们将深入学习 Kubernetes 的核心概念、使用方法和最佳实践。
第三章:Kubernetes 核心概念
3.1 Pod
3.1.1 Pod概述
Pod是Kubernetes中最小的部署单元,它可以包含一个或多个容器。这些容器共享网络命名空间、存储卷等资源,因此它们可以像在同一台机器上运行一样进行通信和共享数据。
3.1.2 Pod的生命周期
Pod的生命周期从创建开始,经过运行、等待或终止等状态。Kubernetes通过控制器(如Deployment)来管理Pod的生命周期,确保Pod按照预期运行。
3.1.3 Pod的类型
-
静态Pod:由Kubelet管理,通常用于集群启动时运行的系统服务。
-
管理型Pod:由Kubernetes控制器管理,如Deployment、StatefulSet等。
3.1.4 Pod的配置
Pod的配置通过YAML文件定义,包括容器镜像、资源限制、环境变量等。例如:
yaml复制
apiVersion: v1 kind: Pod metadata: name: example-pod spec: containers: - name: example-container image: nginx ports: - containerPort: 80
3.2 Deployment
3.2.1 Deployment概述
Deployment是Kubernetes中用于管理无状态应用的控制器。它通过定义期望状态来管理Pod的部署、更新和扩展。
3.2.2 Deployment的功能
-
自动扩缩容:根据定义的副本数量自动创建或删除Pod。
-
滚动更新:在更新应用时,逐步替换旧版本的Pod,确保应用的可用性。
-
回滚:如果更新失败,可以回滚到之前的版本。
3.2.3 Deployment的配置
Deployment的配置通过YAML文件定义,例如:
yaml复制
apiVersion: apps/v1 kind: Deployment metadata: name: example-deployment spec: replicas: 3 selector: matchLabels: app: example template: metadata: labels: app: example spec: containers: - name: example-container image: nginx
3.3 Service
3.3.1 Service概述
Service是Kubernetes中用于定义Pod的逻辑集合和访问策略的抽象资源。它为Pod提供稳定的网络标识和负载均衡。
3.3.2 Service的类型
-
ClusterIP:默认类型,仅在集群内部可访问。
-
NodePort:在集群节点上暴露一个端口,外部可通过节点IP和端口访问。
-
LoadBalancer:在云服务提供商支持的情况下,提供外部负载均衡器。
-
ExternalName:将Service映射到外部域名。
3.3.3 Service的配置
Service的配置通过YAML文件定义,例如:
yaml复制
apiVersion: v1 kind: Service metadata: name: example-service spec: selector: app: example ports: - protocol: TCP port: 80 targetPort: 80 type: ClusterIP
3.4 Namespace
3.4.1 Namespace概述
Namespace是Kubernetes中用于隔离资源的逻辑分区。它可以帮助用户在同一个集群中创建多个虚拟环境,例如开发、测试和生产环境。
3.4.2 Namespace的作用
-
资源隔离:不同Namespace中的资源相互独立。
-
资源配额:可以为每个Namespace分配资源配额,限制资源使用。
3.4.3 Namespace的创建
Namespace的创建通过YAML文件定义,例如:
yaml复制
apiVersion: v1 kind: Namespace metadata: name: example-namespace
3.5 ConfigMap & Secret
3.5.1 ConfigMap
ConfigMap用于存储配置信息,如配置文件、环境变量等。它允许用户将配置与容器镜像分离,便于管理和更新。
3.5.2 Secret
Secret用于存储敏感信息,如密码、密钥等。它以加密的方式存储数据,确保安全性。
3.5.3 配置与使用
ConfigMap和Secret可以通过YAML文件定义,并在Pod中引用。例如:
yaml复制
apiVersion: v1 kind: ConfigMap metadata: name: example-configmap data: config.json: | { "key": "value" } --- apiVersion: v1 kind: Secret metadata: name: example-secret type: Opaque data: password: <base64-encoded-password>
在Pod中引用:
yaml复制
apiVersion: v1 kind: Pod metadata: name: example-pod spec: containers: - name: example-container image: nginx env: - name: CONFIG valueFrom: configMapKeyRef: name: example-configmap key: config.json envFrom: - secretRef: name: example-secret
3.6 Volume
3.6.1 Volume概述
Volume是Kubernetes中用于存储数据的资源,它可以挂载到Pod中,用于持久化存储或共享数据。
3.6.2 Volume的类型
-
EmptyDir:在Pod生命周期内临时存储数据。
-
HostPath:将宿主机的文件系统挂载到Pod。
-
PersistentVolume:独立于Pod的持久化存储,支持动态分配和回收。
3.6.3 Volume的配置
Volume的配置通过YAML文件定义,例如:
yaml复制
apiVersion: v1 kind: Pod metadata: name: example-pod spec: containers: - name: example-container image: nginx volumeMounts: - name: example-volume mountPath: /data volumes: - name: example-volume emptyDir: {}
3.7 其他核心概念
3.7.1 Ingress
Ingress是用于管理外部访问集群内服务的资源,通常用于HTTP和HTTPS流量。它可以根据路径或域名将流量转发到不同的Service。
3.7.2 StatefulSet
StatefulSet是用于管理有状态应用的控制器,它为每个Pod提供稳定的网络标识和存储卷。
3.7.3 Job & CronJob
Job用于运行一次性任务,CronJob用于运行定时任务。它们可以帮助用户在集群中执行批处理作业。
3.7.4 DaemonSet
DaemonSet用于在每个节点上运行一个Pod副本,通常用于运行集群监控、日志收集等系统服务。
第四章:Kubernetes 安装与配置
4.1 本地环境搭建
4.1.1 使用 Minikube 搭建 Kubernetes 集群
Minikube 是一种轻量级的 Kubernetes 环境,适合开发和测试使用。以下是搭建步骤:
-
安装 Minikube 根据操作系统选择安装方式。例如,在 Linux 上可以使用以下命令安装:
bash复制
curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 sudo install minikube-linux-amd64 /usr/local/bin/minikube
-
启动 Minikube 启动 Minikube 并指定驱动(如 VirtualBox 或 Docker):
bash复制
minikube start --driver=docker
-
验证集群状态 使用以下命令验证集群是否正常运行:
bash复制
minikube status kubectl get nodes
-
访问集群 Minikube 提供了便捷命令来访问集群:
bash复制
minikube dashboard
4.1.2 使用 Kind 搭建 Kubernetes 集群
Kind(Kubernetes in Docker)是一种使用 Docker 容器作为节点的 Kubernetes 环境,适合开发和测试。
-
安装 Kind 使用以下命令安装 Kind:
bash复制
curl -Lo kind https://kind.sigs.k8s.io/dl/v0.14.0/kind-linux-amd64 chmod +x kind sudo mv kind /usr/local/bin/
-
创建 Kubernetes 集群 使用 Kind 创建一个 Kubernetes 集群:
bash复制
kind create cluster
-
验证集群状态 检查集群状态:
bash复制
kubectl get nodes
-
删除集群 如果需要删除集群,可以使用以下命令:
bash复制
kind delete cluster
4.2 生产环境部署
4.2.1 使用 kubeadm 部署 Kubernetes 集群
kubeadm
是 Kubernetes 官方推荐的集群部署工具,适用于生产环境。以下是部署步骤:
1. 准备工作
-
关闭防火墙和 SELinux:
bash复制
sudo systemctl stop firewalld sudo systemctl disable firewalld sudo setenforce 0
-
配置主机名和 hosts 文件:
bash复制
sudo hostnamectl set-hostname master sudo vi /etc/hosts
添加以下内容:
127.0.0.1 master
2. 安装 Docker
-
安装 Docker:
bash复制
sudo yum install -y docker-ce docker-ce-cli containerd.io
-
启动并设置 Docker 开机自启:
bash复制
sudo systemctl start docker sudo systemctl enable docker
3. 安装 Kubernetes 组件
-
添加 Kubernetes YUM 源:
bash复制
cat <<EOF | sudo tee /etc/yum.repos.d/kubernetes.repo [kubernetes] name=Kubernetes baseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64 enabled=1 gpgcheck=1 repo_gpgcheck=1 gpgkey=https://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg https://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg EOF
-
安装 kubeadm、kubelet 和 kubectl:
bash复制
sudo yum install -y kubelet kubeadm kubectl sudo systemctl enable kubelet
4. 初始化 Master 节点
-
初始化 Kubernetes 集群:
bash复制
sudo kubeadm init --pod-network-cidr=10.244.0.0/16
-
配置 kubectl:
bash复制
mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config
5. 安装 Pod 网络插件
-
安装 Flannel 网络插件:
bash复制
kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
6. 将工作节点加入集群
-
在工作节点上执行以下命令:
bash复制
sudo kubeadm join <master-node-ip>:6443 --token <token> --discovery-token-ca-cert-hash sha256:<hash>
4.2.2 使用 kops 部署 Kubernetes 集群
kops
是一种用于在云环境中(如 AWS、GCP)部署 Kubernetes 集群的工具。以下是部署步骤:
1. 安装 kops
-
安装 kops:
bash复制
curl -LO https://github.com/kubernetes/kops/releases/download/$(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4)/kops-linux-amd64 chmod +x kops-linux-amd64 sudo mv kops-linux-amd64 /usr/local/bin/kops
2. 配置集群
-
创建集群配置文件:
bash复制
kops create cluster --name=<your-cluster-name> --state=s3://<your-s3-bucket> --zones=<your-zone> --node-count=2 --node-size=t2.medium --master-size=t2.medium --dns-zone=<your-dns-zone>
-
编辑集群配置:
bash复制
kops edit cluster <your-cluster-name>
3. 部署集群
-
部署集群:
bash复制
kops update cluster <your-cluster-name> --yes
4. 验证集群
-
检查集群状态:
bash复制
kops validate cluster
4.3 Kubernetes 集群配置
4.3.1 配置网络插件
Kubernetes 集群需要网络插件来支持 Pod 之间的通信。常用的网络插件包括 Flannel 和 Calico。
-
安装 Flannel:
bash复制
kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
-
安装 Calico:
bash复制
kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml
4.3.2 配置存储插件
根据需求选择合适的存储插件,如 PersistentVolume
和 PersistentVolumeClaim
。
4.3.3 配置 Ingress 控制器
Ingress 控制器用于管理外部访问集群内服务的流量。常用的 Ingress 控制器包括 NGINX 和 Traefik。
-
安装 NGINX Ingress 控制器:
bash复制
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/main/deploy/static/provider/cloud/deploy.yaml
4.3.4 配置集群监控
可以使用 Prometheus 和 Grafana 来监控 Kubernetes 集群。
-
安装 Prometheus:
bash复制
kubectl apply -f https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/master/bundle.yaml
-
安装 Grafana:
bash复制
kubectl apply -f https://raw.githubusercontent.com/grafana/helm-charts/main/charts/grafana/values.yaml
第五章:Kubernetes 命令行工具 (kubectl)
5.1 kubectl 的安装与配置
5.1.1 kubectl 的安装
kubectl
是 Kubernetes 的命令行工具,用于与集群进行交互。以下是不同操作系统上的安装方法:
1.在 Linux 上安装 kubectl
bash复制
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl" sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl
2.在 macOS 上安装 kubectl
bash复制
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl" chmod +x kubectl sudo mv kubectl /usr/local/bin/
3.在 Windows 上安装 kubectl
-
下载最新版本的
kubectl
:Kubernetes Releases -
将下载的文件解压到系统路径中,例如
C:\Program Files\kubectl
。 -
将
kubectl.exe
添加到系统的 PATH 环境变量中。
5.1.2 配置 kubectl
kubectl
使用配置文件(默认为 ~/.kube/config
)来连接 Kubernetes 集群。以下是配置方法:
1.使用 kubeadm 初始化集群时自动生成配置
如果你使用 kubeadm
初始化集群,kubectl
的配置文件会自动生成:
bash复制
mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config
2.手动配置 kubectl
如果需要手动配置,可以使用以下命令:
bash复制
kubectl config set-cluster <cluster-name> --server=<cluster-endpoint> kubectl config set-credentials <user-name> --username=<username> --password=<password> kubectl config set-context <context-name> --cluster=<cluster-name> --user=<user-name> kubectl config use-context <context-name>
5.1.3 验证 kubectl 安装
安装完成后,可以通过以下命令验证 kubectl
是否正常工作:
bash复制
kubectl version --client
5.2 kubectl 常用命令
5.2.1 获取资源信息
-
获取节点信息:
bash复制
kubectl get nodes
-
获取 Pod 列表:
bash复制
kubectl get pods
-
获取 Deployment 列表:
bash复制
kubectl get deployments
-
获取 Service 列表:
bash复制
kubectl get services
5.2.2 创建和删除资源
-
创建资源:
bash复制
kubectl create -f <file.yaml>
-
删除资源:
bash复制
kubectl delete -f <file.yaml>
5.2.3 更新资源
-
更新资源:
bash复制
kubectl apply -f <file.yaml>
-
编辑资源:
bash复制
kubectl edit <resource-type> <resource-name>
5.2.4 查看资源详细信息
-
查看 Pod 的详细信息:
bash复制
kubectl describe pod <pod-name>
-
查看 Deployment 的详细信息:
bash复制
kubectl describe deployment <deployment-name>
5.2.5 进入 Pod
-
进入 Pod 的容器:
bash复制
kubectl exec -it <pod-name> -- /bin/sh
5.2.6 端口转发
-
将本地端口转发到 Pod 的端口:
bash复制
kubectl port-forward <pod-name> <local-port>:<pod-port>
5.2.7 日志查看
-
查看 Pod 的日志:
bash复制
kubectl logs <pod-name>
5.2.8 资源缩放
-
缩放 Deployment 的副本数量:
bash复制
kubectl scale deployment <deployment-name> --replicas=<number>
5.2.9 命名空间操作
-
创建命名空间:
bash复制
kubectl create namespace <namespace-name>
-
切换命名空间:
bash复制
kubectl config set-context --current --namespace=<namespace-name>
5.3 kubectl 插件
5.3.1 kubectl 插件简介
kubectl
支持插件机制,允许用户扩展其功能。插件通常以可执行文件的形式存在,文件名以 kubectl-
开头。插件可以通过以下方式安装和使用:
1.安装插件
-
下载插件:
bash复制
curl -LO <plugin-url>
-
设置可执行权限:
bash复制
chmod +x kubectl-<plugin-name>
-
将插件移动到系统路径:
bash复制
sudo mv kubectl-<plugin-name> /usr/local/bin/
2.使用插件
插件可以通过以下命令使用:
bash复制
kubectl <plugin-name> <args>
5.3.2 常用 kubectl 插件
1.kubectl-ctx 和 kubectl-ns
这两个插件用于快速切换集群上下文(kubectl-ctx
)和命名空间(kubectl-ns
):
bash复制
kubectl ctx <context-name> kubectl ns <namespace-name>
2.kubectl-diff
kubectl-diff
插件用于比较当前集群状态与 YAML 文件的差异:
bash复制
kubectl diff -f <file.yaml>
3.kubectl-neat
kubectl-neat
插件用于清理 YAML 文件中的冗余字段,使文件更简洁:
bash复制
kubectl neat <file.yaml>
4.kubectl-whoami
kubectl-whoami
插件用于显示当前用户的身份信息:
bash复制
kubectl whoami
5.3.3 插件管理
-
查找插件: 可以在 Kubernetes 插件目录 中查找可用插件。
-
安装插件管理工具 krew:
krew
是一个插件管理工具,用于安装、更新和管理 kubectl 插件:bash复制
( set -x; cd "$(mktemp -d)" && OS="$(uname | tr '[:upper:]' '[:lower:]')" && ARCH="$(uname -m | sed -e 's/x86_64/amd64/' -e 's/\(arm\)\(64\)\?.*/\1\2/' -e 's/aarch64$/arm64/')" && KREW="krew-${OS}_${ARCH}" && curl -fsSLO "https://github.com/kubernetes-sigs/krew/releases/latest/download/${KREW}.tar.gz" && tar zxvf "${KREW}.tar.gz" && ./"${KREW}" install krew )
-
使用 krew 安装插件:
bash复制
kubectl krew install <plugin-name>
第二部分:Kubernetes 进阶
第六章:Kubernetes 工作负载管理
6.1 Deployment 的滚动更新和回滚
6.1.1 滚动更新
滚动更新是 Deployment 的一种更新策略,通过逐步替换 Pod 来完成版本升级。以下是滚动更新的步骤:
-
创建初始 Deployment 创建一个 Deployment 来部署应用程序的初始版本:
yaml复制
apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80
-
发起升级 更新 Deployment 中的镜像版本来触发滚动更新:
bash复制
kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1
或者直接编辑 YAML 文件并重新应用:
bash复制
kubectl edit deployment nginx-deployment
-
监控升级过程 使用以下命令监控升级进度:
bash复制
kubectl rollout status deployment/nginx-deployment
6.1.2 回滚
如果滚动更新出现问题,可以回滚到之前的版本:
bash复制
kubectl rollout undo deployment/nginx-deployment --to-revision=<版本号>
可以通过以下命令查看历史版本信息:
bash复制
kubectl rollout history deployment/nginx-deployment
6.2 StatefulSet 的使用
6.2.1 StatefulSet 的特点
StatefulSet 是用于管理有状态应用的工作负载 API 对象,具有以下特点:
-
稳定的、唯一的网络标识符。
-
稳定的、持久的存储。
-
有序的、优雅的部署和扩缩。
-
有序的、自动的滚动更新。
6.2.2 StatefulSet 的滚动更新
StatefulSet 的滚动更新可以通过以下方式实现:
-
分段更新 通过设置
partition
字段,可以分阶段更新 StatefulSet:bash复制
kubectl patch statefulset <statefulset-name> -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":<分区号}}}}}'
-
金丝雀发布 通过减少
partition
的值,可以实现金丝雀发布:bash复制
kubectl patch statefulset <statefulset-name> -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":<分区号}}}}}'
-
更新 Pod 更新 StatefulSet 的 Pod 模板后,可以手动删除 Pod,触发新 Pod 的创建:
bash复制
kubectl delete pod <pod-name>
6.3 DaemonSet 的使用
6.3.1 DaemonSet 的特点
DaemonSet 是一种工作负载 API 对象,用于在每个节点上运行一个 Pod 副本。它常用于运行集群监控、日志收集等系统服务。
6.3.2 DaemonSet 的配置
以下是一个 DaemonSet 的示例配置:
yaml复制
apiVersion: apps/v1 kind: DaemonSet metadata: name: myds spec: selector: matchLabels: app: ds-httpd template: metadata: labels: app: ds-httpd spec: containers: - name: web image: myos:httpd imagePullPolicy: Always
6.3.3 DaemonSet 的应用场景
DaemonSet 适用于以下场景:
-
在每个节点上运行日志收集器(如 Fluentd)。
-
在每个节点上运行监控代理(如 Prometheus Node Exporter)。
6.4 Job 和 CronJob 的使用
6.4.1 Job 的使用
Job 是一种用于执行一次性任务的工作负载 API 对象。它保证任务在一个或多个 Pod 上成功执行。
1.Job 的配置示例
yaml复制
apiVersion: batch/v1 kind: Job metadata: name: myjob spec: template: spec: containers: - name: myjob image: myos:8.5 command: ["/bin/sh"] args: ["-c", "sleep 3; exit $((RANDOM%2))"] restartPolicy: OnFailure
6.4.2 CronJob 的使用
CronJob 是一种用于执行定时任务的工作负载 API 对象。它根据预设的时间表创建 Job 和 Pod。
1.CronJob 的配置示例
yaml复制
apiVersion: batch/v1 kind: CronJob metadata: name: mycj spec: schedule: "*/5 * * * *" # 每 5 分钟执行一次 jobTemplate: spec: template: spec: containers: - name: myjob image: myos:8.5 command: ["/bin/sh"] args: ["-c", "sleep 3; exit $((RANDOM%2))"] restartPolicy: OnFailure
6.4.3 Job 和 CronJob 的应用场景
-
Job:用于执行一次性任务,如数据库迁移、批处理作业。
-
CronJob:用于执行定时任务,如定期备份、日志清理。
第七章:Kubernetes 网络
7.1 Kubernetes 网络模型
7.1.1 核心设计原则
Kubernetes 网络模型的设计基于以下原则:
-
扁平化网络:所有 Pod 无论运行在哪个节点上,都处于同一逻辑网络平面,可以直接通过 IP 地址通信,无需 NAT 转换。
-
每个 Pod 独立 IP:每个 Pod 都拥有一个独立的 IP 地址,Pod 内的容器共享该 IP。
-
解耦网络实现:Kubernetes 不直接实现网络功能,而是通过 CNI(Container Network Interface)规范对接第三方插件(如 Calico、Cilium、Flannel)。
7.1.2 关键网络组件
Pod 网络
-
实现方式:通过 CNI 插件管理 Pod 的 IP 分配和网络配置。
-
通信方式:
-
同节点 Pod:通过本地网桥直接通信。
-
跨节点 Pod:通过 Overlay 网络(如 VXLAN)或路由模式(如 BGP)实现通信。
-
Service 网络
Service 是 Kubernetes 中用于暴露应用的抽象层,提供了稳定的访问接口。
7.2 Service 的类型和实现原理
7.2.1 Service 类型
Service 提供了多种类型以满足不同的需求:
-
ClusterIP(默认类型):
-
仅在集群内部暴露服务,通过虚拟 IP 和 kube-proxy 实现负载均衡。
-
-
NodePort:
-
在每个节点的固定端口上暴露服务,外部可通过节点 IP 和端口访问。
-
-
LoadBalancer:
-
使用云提供商的负载均衡器将外部流量路由到服务。
-
-
ExternalName:
-
将服务映射到外部 DNS 名称。
-
7.2.2 实现原理
-
kube-proxy:运行在每个节点上,通过 iptables 或 IPVS 规则拦截到达 Service 的流量,并转发到后端 Pod。
-
CoreDNS:为 Service 提供 DNS 解析,Pod 可通过
<服务名>.<命名空间>.svc.cluster.local
访问服务。
7.3 Ingress 的使用
7.3.1 Ingress 概念
Ingress 是一种用于管理外部 HTTP/HTTPS 流量的 Kubernetes 资源对象,它提供了基于路径和域名的路由、SSL 终止等功能。
7.3.2 Ingress 配置示例
yaml复制
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-app spec: rules: - host: app.example.com http: paths: - path: / pathType: Prefix backend: service: name: frontend port: number: 80
-
Ingress 控制器:负责解析 Ingress 资源并处理外部流量。
-
生产技巧:使用
cert-manager
自动为 Ingress 签发 Let's Encrypt 免费证书。
7.4 网络策略
7.4.1 网络策略概述
网络策略(NetworkPolicy)用于控制 Pod 之间的通信权限,提升安全性。
7.4.2 网络策略示例
以下是一个限制 Pod 通信的网络策略示例:
yaml复制
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: db-isolation spec: podSelector: matchLabels: role: database policyTypes: - Ingress ingress: - from: - podSelector: matchLabels: role: api-server ports: - protocol: TCP port: 5432 # PostgreSQL 默认端口
-
支持网络策略的 CNI 插件:如 Calico 和 Cilium。
-
默认策略:默认拒绝所有流量,按需开放最小权限。
第八章:Kubernetes 存储
8.1 Volume 的类型和使用
8.1.1 Volume 概述
Kubernetes 提供了多种类型的 Volume,每种类型都有其特定的应用场景。Volume 的生命周期独立于 Pod,即使 Pod 被删除,Volume 中的数据仍然可以被其他 Pod 使用。
8.1.2 常见 Volume 类型
8.1.2.1 emptyDir
emptyDir
是一种简单的 Volume 类型,它在 Pod 被分配到节点时创建,并在 Pod 被删除时销毁。它适用于临时存储或中间结果的存储需求。
yaml复制
volumes: - name: storage emptyDir: {}
8.1.2.2 hostPath
hostPath
允许将宿主机文件系统上的文件或目录挂载到 Pod 中。它适用于需要访问宿主机特定文件或目录的场景,但在生产环境中应谨慎使用。
yaml复制
volumes: - name: config-volume hostPath: path: /etc/config
8.1.2.3 PersistentVolume (PV) 和 PersistentVolumeClaim (PVC)
PV 和 PVC 是 Kubernetes 中用于持久化存储的资源。PV 是集群中的存储资源,由管理员创建或动态供给,而 PVC 是用户对存储资源的请求。
8.1.3 使用 PV 和 PVC
PV 和 PVC 的使用流程如下:
-
创建 PV:由集群管理员创建或通过 StorageClass 动态供给。
yaml复制
apiVersion: v1 kind: PersistentVolume metadata: name: pv-nfs spec: capacity: storage: 5Gi accessModes: - ReadWriteMany nfs: server: nfs-server.example.com path: "/"
-
创建 PVC:用户提交 PVC 请求特定大小和访问模式的存储。
yaml复制
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: myclaim spec: accessModes: - ReadWriteMany resources: requests: storage: 5Gi
-
在 Pod 中使用 PVC:Pod 通过挂载 PVC 来使用存储资源。
yaml复制
apiVersion: v1 kind: Pod metadata: name: mypod spec: containers: - name: myfrontend image: nginx volumeMounts: - mountPath: "/var/www/html" name: mypd volumes: - name: mypd persistentVolumeClaim: claimName: myclaim
8.2 PersistentVolume 和 PersistentVolumeClaim
8.2.1 PersistentVolume (PV)
PV 是集群中的存储资源,独立于 Pod 的生命周期。PV 可以由管理员预先创建,也可以通过 StorageClass 动态供给。
8.2.2 PersistentVolumeClaim (PVC)
PVC 是用户对存储资源的请求。用户通过 PVC 申请特定大小和访问模式的存储资源,Kubernetes 会自动匹配合适的 PV 并绑定。
8.2.3 PV 和 PVC 的生命周期
-
创建:PV 由管理员创建或动态供给,PVC 由用户创建。
-
绑定:Kubernetes 控制平面会将 PVC 与合适的 PV 绑定。
-
使用:Pod 通过 PVC 挂载 PV 来使用存储资源。
-
回收:PV 的回收策略可以是保留(Retain)、删除(Delete)或回收(Recycle)。
8.2.4 动态供给
动态供给允许根据用户的 PVC 请求自动创建 PV,这需要配置 StorageClass。
8.3 StorageClass
8.3.1 StorageClass 概述
StorageClass 提供了一种动态供给存储资源的方式,允许用户根据不同的存储需求选择合适的存储类型。
8.3.2 StorageClass 配置
StorageClass 定义了存储的供给方式和参数,例如存储类型、性能级别等。
yaml复制
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: example-vol-default provisioner: vendor-name.example/magicstorage parameters: resturl: "http://192.168.10.100:8080" restuser: "" allowVolumeExpansion: true
8.3.3 动态供给的实现
当 PVC 请求一个 StorageClass 时,Kubernetes 会根据 StorageClass 的配置动态创建 PV。
第九章:Kubernetes 安全
9.1 Kubernetes 安全模型
9.1.1 安全模型概述
Kubernetes 的安全模型围绕保护 API Server 设计,所有请求需通过 认证(Authentication)、授权(Authorization) 和 准入控制(Admission Control) 三关才能创建资源。此外,Kubernetes 安全还遵循 4Cs 模型,即 代码安全(Code)、容器安全(Container)、集群安全(Cluster) 和 云安全(Cloud)。
9.1.2 4Cs 模型
-
代码安全 代码是容器运行的应用程序,是 Kubernetes 环境中的主要攻击面之一。为确保代码安全,应实施安全编码实践,定期扫描漏洞,并遵循 OWASP 编码指南。
-
容器安全 容器由镜像组成,包含操作系统、配置、依赖项和运行时。容器安全的关键是使用可信的镜像仓库,最小化代码库,扫描镜像漏洞,并通过网络策略限制 Pod 之间的通信。
-
集群安全 集群安全涉及保护容器和应用程序、控制平面(API、调度器、数据存储和控制器)以及集群运行的网络。
-
云安全 云安全涉及物理数据中心或运行 Kubernetes 的云基础设施。云提供商提供了实施适当访问控制的指南和最佳实践。
9.2 认证和授权
9.2.1 认证(Authentication)
认证是确认请求方身份的第一步,Kubernetes 支持以下认证方式:
-
令牌(Token):常用于服务账户。
-
X.509 客户端证书:适合通过
kubectl
访问集群。 -
OpenID Connect(OIDC):集成第三方身份提供商(如 Google 或 Keycloak)。
-
Webhook:自定义认证逻辑。
9.2.2 授权(Authorization)
授权决定用户是否有权访问特定资源,Kubernetes 提供以下授权方式:
-
RBAC(基于角色的访问控制):通过角色(Role/ClusterRole)和绑定(RoleBinding/ClusterRoleBinding)管理权限,支持精细化管理。
-
ABAC(基于属性的访问控制):通过 JSON 文件定义权限,配置繁琐,不推荐使用。
-
Webhook 授权:调用外部服务实现复杂权限检查。
-
Node 授权:限制节点访问与自身相关的资源。
9.2.3 准入控制(Admission Control)
准入控制是最后一道防线,通过插件检查或修改请求,决定是否允许操作。常见的准入控制插件包括:
-
ResourceQuota:限制命名空间内的资源总量。
-
PodSecurityPolicy:控制 Pod 的安全配置(已被 Pod 安全性标准替代)。
-
MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook:支持自定义规则。
9.3 网络安全
9.3.1 网络策略
网络策略(NetworkPolicy)用于控制 Pod 之间的通信权限,提升安全性。通过配置网络策略,可以限制 Pod 之间的通信,仅允许必要的流量通过。
9.3.2 安全最佳实践
-
限制节点暴露:仅安装必要的应用程序和库,限制对管理员账户的访问,并部署实时监控工具。
-
启用审计日志:审计日志记录集群活动,帮助快速检测异常行为。Kubernetes 提供了审计日志功能,但默认未启用。
-
加密敏感信息:Kubernetes Secret 用于存储敏感信息(如密码、SSH 密钥等),应确保 Secret 在静止状态下加密,并限制访问。
9.4 安全最佳实践
9.4.1 保护控制平面
控制平面是 Kubernetes 的核心,负责管理集群状态和配置数据。保护控制平面的关键措施包括:
-
保护 etcd 数据库:启用加密,限制与 API Server 的通信,并使用证书认证。
-
保护 API Server:限制外部访问,实施强认证机制,并使用 TLS 加密。
9.4.2 镜像安全扫描
容器镜像是集群和 Pod 的基础,必须定期扫描漏洞,确保容器不会继承镜像的安全缺陷。
9.4.3 限制容器权限
容器应使用最小权限运行,避免运行特权容器,以减少攻击面。
9.4.4 持续扫描漏洞
持续监控和扫描 Kubernetes 环境中的漏洞,包括配置错误、未打补丁的软件和容器漏洞。
第十章:Kubernetes 监控与日志
10.1 Kubernetes 监控指标
10.1.1 监控指标分类
Kubernetes 的监控指标可以分为以下几个层次:
-
节点层:监控宿主机的资源使用情况,如 CPU、内存、磁盘和网络。
-
Kubernetes 组件层:监控控制平面(如
kube-apiserver
、etcd
)和工作节点的健康状态。 -
资源层:监控 Kubernetes 资源对象(如 Pod、Deployment)的状态。
-
容器层:监控容器的资源使用情况,如 CPU、内存、网络带宽。
-
业务应用层:监控业务相关的指标,如订单数、用户数等。
10.1.2 常见监控指标
-
节点指标:CPU 使用率、内存利用率、磁盘 I/O、网络带宽。
-
Kubernetes 组件指标:
kube-apiserver
请求延迟、etcd
磁盘 I/O。 -
容器指标:容器 CPU 使用率、内存使用量、网络流量。
-
资源状态指标:Pod 状态、Deployment 副本数。
10.2 常用监控工具 (Prometheus, Grafana)
10.2.1 Prometheus
Prometheus 是一个开源的监控和警报工具,广泛用于 Kubernetes 集群的监控。
-
核心组件:
-
Prometheus Server:负责抓取和存储指标。
-
Exporters:如
node-exporter
、kube-state-metrics
,用于暴露指标。 -
Alertmanager:处理告警并发送通知。
-
-
部署方式:
-
使用 Helm 部署 Prometheus,推荐使用
kube-prometheus-stack
Helm Chart。
-
-
监控目标:
-
节点监控:通过
node-exporter
获取 CPU、内存等指标。 -
Pod 和容器监控:通过
cAdvisor
获取资源使用情况。 -
Kubernetes 资源状态监控:通过
kube-state-metrics
获取资源状态。
-
10.2.2 Grafana
Grafana 是一个可视化工具,常与 Prometheus 结合使用,提供直观的仪表盘。
-
功能:
-
查询 Prometheus 数据源并展示指标。
-
支持自定义仪表盘,用于实时监控和告警。
-
10.3 Kubernetes 日志收集
10.3.1 日志收集架构
Kubernetes 日志收集通常采用以下架构:
Node (Operating Sys) --> Filebeat (Container Logs) --> Fluent-bit (Log Processing) --> Elasticsearch (Log Storage) --> Kibana (Log Analysis)
10.3.2 日志收集工具
-
Filebeat:用于从容器中收集日志。
-
配置示例:
yaml复制
filebeat.inputs: - type: log enabled: true paths: - /var/log/containers/*.log tags: [k8s] fields: k8s_container_id: "{{container.id}}" k8s_pod_name: "{{pod.name}}" k8s_namespace: "{{pod.namespace}}" k8s_deployment_name: "{{deployment.name}}" output.elasticsearch: hosts: ["localhost:9200"] setup.kibana: host: "localhost:5601"
-
-
Fluent-bit:用于处理和转发日志。
-
配置示例:
conf复制
[Input] @type tail Path /var/log/containers/*.log Posix RefreshInterval 10 [Filter] @type kubernetes kubernetes.logtag_prefix k8s [Output] @type elasticsearch hosts ["localhost:9200"] index_name k8s-logs-%{+YYYY.MM.dd} flush_interval 10s retry.on_failure true retry.max_retries 5 retry.backoff_factor 2
-
-
Elasticsearch:用于存储日志数据。
-
配置示例:
yaml复制
cluster.name: k8s-logs node.name: elasticsearch network.host: 0.0.0.0 http.port: 9200
-
-
Kibana:用于日志分析和可视化。
-
配置示例:
yaml复制
server.host: "0.0.0.0" server.port: 5601 elasticsearch.hosts: ["localhost:9200"]
-
10.4 常用日志工具 (EFK)
10.4.1 EFK 堆栈
EFK 堆栈(Elasticsearch、Fluentd、Kibana)是 Kubernetes 日志管理的常用解决方案。
-
Elasticsearch:存储和索引日志数据。
-
Fluentd:日志收集和处理工具。
-
Kibana:日志分析和可视化工具。
10.4.2 部署 EFK
-
部署 Elasticsearch:用于存储日志。
-
部署 Fluentd:从容器中收集日志并转发到 Elasticsearch。
-
部署 Kibana:用于日志分析和可视化。
10.4.3 日志分析
在 Kibana 中,可以使用内置的分析工具对日志数据进行可视化分析和查询。
10.4.4 最佳实践
-
日志规范:建议使用 JSON 格式记录日志,便于解析和分析。
-
日志清理和归档:定期清理旧日志,避免存储压力过大。
-
监控和告警:使用 Prometheus 和 Grafana 监控日志平台的性能,并设置告警规则。
第三部分:Kubernetes 实战
第十一章:Kubernetes 应用部署
11.1 容器镜像构建与推送
11.1.1 容器镜像构建
容器镜像是 Kubernetes 部署的基础,以下是构建镜像的步骤:
-
编写 Dockerfile:定义应用的运行环境和依赖。
dockerfile复制
FROM golang:1.20 WORKDIR /app COPY . . RUN go build -o app CMD ["./app"]
-
构建镜像:使用
docker build
命令构建镜像。bash复制
docker build -t your-app:latest .
-
测试镜像:运行镜像以确保其正常工作。
11.1.2 镜像推送
将镜像推送到 Docker Hub 或私有镜像仓库:
-
登录镜像仓库:
bash复制
docker login
-
推送镜像:
bash复制
docker push your-app:latest
镜像推送完成后,可以在 Kubernetes 中使用该镜像部署应用。
11.2 Helm Chart 的使用
11.2.1 Helm Chart 概述
Helm 是 Kubernetes 的包管理工具,通过 Helm Chart 可以快速部署和管理 Kubernetes 应用。
11.2.2 创建 Helm Chart
-
初始化 Chart:
bash复制
helm create my-app
-
编辑 Chart 文件:在
templates
目录中定义 Kubernetes 资源。yaml复制
# my-app/templates/deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: {{ .Values.name }} spec: replicas: {{ .Values.replicas }} selector: matchLabels: app: {{ .Values.name }} template: metadata: labels: app: {{ .Values.name }} spec: containers: - name: {{ .Values.name }} image: {{ .Values.image }} ports: - containerPort: 80
-
配置 Chart 参数:在
values.yaml
中定义默认参数。
11.2.3 部署 Helm Chart
-
安装 Chart:
bash复制
helm install my-app ./my-app
-
更新或回滚 Chart:
bash复制
helm upgrade my-app ./my-app helm rollback my-app
Helm 支持版本管理,可以方便地回滚到之前的版本。
11.3 CI/CD 与 Kubernetes 集成
11.3.1 CI/CD 工具选择
常见的 CI/CD 工具包括 Jenkins、GitLab CI 和 Travis CI。选择工具时需考虑易用性、扩展性和社区支持。
11.3.2 Jenkins 与 Kubernetes 集成
-
安装 Jenkins:在 Kubernetes 集群中部署 Jenkins。
yaml复制
apiVersion: apps/v1 kind: Deployment metadata: name: jenkins spec: replicas: 1 selector: matchLabels: app: jenkins template: metadata: labels: app: jenkins spec: containers: - name: jenkins image: jenkins/jenkins:lts ports: - containerPort: 8080
-
配置 Jenkins Pipeline:使用
Jenkinsfile
定义 CI/CD 流程。groovy复制
pipeline { agent any stages { stage('Build') { steps { sh 'docker build -t your-app:latest .' sh 'docker push your-app:latest' } } stage('Deploy') { steps { script { helm("upgrade --install your-app ./my-app") } } } } }
11.3.3 GitLab CI 与 Kubernetes 集成
-
配置 GitLab CI Runner:使其能够访问 Kubernetes 集群。
-
编写
.gitlab-ci.yml
文件:yaml复制
deploy_to_kubernetes: stage: deploy script: - kubectl apply -f deployment.yaml only: - master
11.3.4 安全性与权限管理
在 CI/CD 流程中,建议采用最小权限原则,并使用 Kubernetes Secrets 管理敏感信息。
第十二章:Kubernetes 生产环境实践
12.1 高可用 Kubernetes 集群搭建
12.1.1 高可用集群概述
高可用 Kubernetes 集群通过冗余设计消除单点故障,确保系统在部分组件或节点故障时仍能正常运行。实现高可用的关键包括:
-
多主架构:至少部署三个 Master 节点。
-
负载均衡器:用于分发 API Server 请求。
-
Etcd 高可用:作为 Kubernetes 的分布式键值存储,配置为高可用模式。
12.1.2 高可用集群搭建步骤
-
环境准备
-
操作系统:CentOS 7.6。
-
硬件配置:每个节点至少 4GB 内存、6vCPU。
-
网络设置:配置静态 IP 和主机名,关闭
firewalld
和selinux
。
-
-
初始化第一个 Master 节点 使用
kubeadm init
初始化第一个 Master 节点,并指定负载均衡器地址:bash复制
sudo kubeadm init --control-plane-endpoint "<LOAD_BALANCER_DNS>:<PORT>" --upload-certs
-
加入其他 Master 节点 使用
kubeadm join
命令将其他 Master 节点加入集群:bash复制
sudo kubeadm join <LOAD_BALANCER_DNS>:<PORT> --token <TOKEN> --discovery-token-ca-cert-hash sha256:<HASH> --control-plane --certificate-key <CERTIFICATE_KEY>
-
配置 Etcd 集群
-
可以通过
kubeadm
自动化配置 Etcd 集群。 -
手动配置时,需要生成 TLS 证书并备份 Etcd 数据。
-
-
加入 Worker 节点 将 Worker 节点加入集群:
bash复制
sudo kubeadm join <LOAD_BALANCER_DNS>:<PORT> --token <TOKEN> --discovery-token-ca-cert-hash sha256:<HASH>
12.2 资源配额和限制
12.2.1 资源配额(Resource Quotas)
资源配额用于限制命名空间内的资源使用量,确保资源公平分配。
配置资源配额
yaml复制
apiVersion: v1 kind: ResourceQuota metadata: name: example-quota namespace: mynamespace spec: hard: pods: "10" requests.cpu: "4" requests.memory: 1Gi limits.cpu: "10" limits.memory: 2Gi
-
限制命名空间内 Pod 的数量和资源使用。
12.2.2 资源限制(Resource Limits)
资源限制用于限制单个 Pod 或容器的资源使用。
配置资源限制
yaml复制
apiVersion: v1 kind: Pod metadata: name: example-pod spec: containers: - name: example-container image: example-image resources: limits: cpu: "1000m" memory: "500Mi" requests: cpu: "500m" memory: "250Mi"
-
防止 Pod 过度使用资源。
12.2.3 限制范围(LimitRange)
限制范围用于控制命名空间内每个 Pod 或容器的资源分配。
配置限制范围
yaml复制
apiVersion: v1 kind: LimitRange metadata: name: example-limitrange namespace: mynamespace spec: limits: - type: Container max: cpu: "1000m" memory: "500Mi" min: cpu: "500m" memory: "250Mi"
-
设置 Pod 的默认资源请求和限制。
12.3 应用性能优化
12.3.1 调度策略优化
-
默认调度器(kube-scheduler)
-
过滤阶段:筛选满足资源请求的节点。
-
打分阶段:选择得分最高的节点。
-
-
自定义调度策略
-
使用节点标签(Labels)和污点(Taints)优化节点选择:
yaml复制
affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: disktype operator: In values: - ssd tolerations: - key: "key1" operator: "Equal" value: "value1" effect: "NoSchedule"
-
-
资源优化
-
合理设置资源请求和限制,避免资源浪费。
-
12.4 故障排查和问题解决
12.4.1 常见问题及解决方法
-
Etcd 数据丢失
-
定期备份 Etcd 数据:
bash复制
etcdctl --endpoints https://127.0.0.1:3379 \ --cert /tmp/etcd-certs/certs/127.0.0.1.pem \ --key /tmp/etcd-certs/certs/127.0.0.1-key.pem \ --cacert /tmp/etcd-certs/certs/ca.pem snapshot save snapshot.db
-
-
资源不足
-
检查资源配额和限制,合理调整资源分配。
-
-
Pod 调度失败
-
检查节点资源是否充足,调整节点标签或污点。
-
-
网络问题
-
检查网络策略和 CNI 插件配置。
-
12.4.2 监控与日志
-
使用 Prometheus 和 Grafana 监控集群状态。
-
使用 EFK 堆栈(Elasticsearch、Fluentd、Kibana)收集和分析日志。
第十三章:Kubernetes 生态与未来
13.1 Kubernetes 生态系统
13.1.1 主要生态项目
Kubernetes 的生态系统不断发展,涵盖了从服务网格到无服务器计算的多个领域:
-
Istio Istio 是一个服务网格(Service Mesh)解决方案,与 Kubernetes 深度集成,提供细粒度的流量控制、安全性和可观测性。它通过为微服务架构提供流量管理、服务发现和安全功能,弥补了 Kubernetes 在这些方面的不足。
-
Knative Knative 是一个用于构建和管理无服务器(Serverless)应用的框架。它支持函数即服务(FaaS),简化了事件驱动应用的部署。
-
Kubeflow Kubeflow 是一个开源项目,致力于简化机器学习(ML)工作流在 Kubernetes 上的部署。它通过集成 TensorFlow 和 NVIDIA GPU Operator 等工具,支持分布式机器学习应用。
-
Prometheus 和 Grafana Prometheus 是 Kubernetes 生态系统中的标准监控工具,广泛用于集群监控和报警。Grafana 则提供了强大的可视化能力,帮助用户分析监控数据。
13.1.2 生态系统的发展趋势
-
多云与混合云支持 Kubernetes 在多云环境中的应用将更加广泛,支持企业在不同云服务提供商之间灵活部署和管理应用。
-
边缘计算融合 随着物联网(IoT)和 5G 技术的发展,Kubernetes 将在边缘计算领域发挥重要作用,支持低延迟和高可靠性的服务。
-
安全与合规 随着 Kubernetes 的广泛应用,安全和合规问题将越来越受到重视。未来,Kubernetes 将集成更多安全功能和合规工具。
13.2 Kubernetes 未来发展趋势
13.2.1 技术演进
-
服务网格集成化 服务网格(如 Istio)将成为 Kubernetes 生态系统的重要组成部分,提供更完善的服务治理能力。
-
人工智能与机器学习集成 Kubernetes 将逐渐成为 AI 和机器学习应用的核心平台,支持大规模分布式训练和推理。
-
边缘计算与物联网融合 Kubernetes 将在边缘计算和物联网领域发挥更大作用,支持更高效的数据处理和更低的延迟。
-
绿色与可持续计算 Kubernetes 将优化资源使用和能源管理,推动绿色计算和可持续发展。
13.2.2 应用场景拓展
-
Serverless 与 Kubernetes Serverless 架构通过 Kubernetes 提供的编排能力,实现了无服务器计算的灵活性和可扩展性。Knative 等框架使得在 Kubernetes 上运行 Serverless 应用变得更加简单。
-
多集群管理与跨云部署 Kubernetes 的多集群管理工具和跨云解决方案将不断优化,支持企业更高效地管理跨云资源。
-
智能化运维 Kubernetes 将引入更多智能化运维工具,如自动配置优化、故障预测和自恢复机制。
13.3 Serverless 与 Kubernetes
13.3.1 Serverless 架构
Serverless 架构是一种云计算模型,开发者无需管理底层服务器,专注于编写代码。它通过事件驱动的方式,按需分配资源,降低了运维成本。
13.3.2 Kubernetes 与 Serverless 的结合
Kubernetes 提供了强大的编排能力,支持 Serverless 架构的运行。通过框架如 Knative 和 OpenFaaS,用户可以在 Kubernetes 上部署无服务器应用。这种结合不仅提升了应用的灵活性和可扩展性,还利用了 Kubernetes 的资源管理和调度能力。
13.3.3 未来展望
Serverless 与 Kubernetes 的结合将推动无服务器计算的进一步发展。未来,Serverless 架构将在 Kubernetes 的支持下,广泛应用于更多行业,如制造业、汽车业和娱乐业。