diff --git a/kubenets/02.安装.md b/kubenets/02.安装.md index fa5d22b0..844ead61 100644 --- a/kubenets/02.安装.md +++ b/kubenets/02.安装.md @@ -3,7 +3,6 @@ ## minikube 1. 安装步骤https://minikube.sigs.k8s.io/docs/start/ - 2. 启动k8s集群 ``` @@ -73,21 +72,21 @@ minikube addons disable metrics-server minikube stop ``` - 5. 删除虚拟机 ``` minikube delete ``` + ## 单机安装 -关于单机安装`k8s`，我使用的相关环境如下（于2022-08-13更新）： +关于单机安装 `k8s`，我使用的相关环境如下（于2022-08-13更新）： - macOS：Monterey 12.4 - Docker Desktop Vesion：4.11.1 - Kubernetes：v1.24.2 -由于镜像的下载涉及到网络原因，因此这里使用了开源项目[k8s-docker-desktop-for-mac](https://github.com/gotok8s/k8s-docker-desktop-for-mac)来解决这个问题，需要注意的是要修改`images`的相关镜像的版本，要和此时`Kubernetes`配对上才行，比如我设置的是： +由于镜像的下载涉及到网络原因，因此这里使用了开源项目[k8s-docker-desktop-for-mac](https://github.com/gotok8s/k8s-docker-desktop-for-mac)来解决这个问题，需要注意的是要修改 `images`的相关镜像的版本，要和此时 `Kubernetes`配对上才行，比如我设置的是： ```txt k8s.gcr.io/kube-proxy:v1.24.2=gotok8s/kube-proxy:v1.24.2 @@ -99,10 +98,10 @@ k8s.gcr.io/coredns/coredns:v1.8.6=gotok8s/coredns:v1.8.6 k8s.gcr.io/etcd:3.5.3-0=gotok8s/etcd:3.5.3-0 ``` -然后执行`./load_images.sh `即可下载k8s依赖的镜像，随后打开`Docker`，进入设置界面，勾选`Enable Kubernetes`即可： +然后执行 `./load_images.sh `即可下载k8s依赖的镜像，随后打开 `Docker`，进入设置界面，勾选 `Enable Kubernetes`即可： ![](image/2023-08-09-14-11-04.png) -不出意外，界面左下角会出现`Kubernetes running`的提示，这样就安装成功了。 +不出意外，界面左下角会出现 `Kubernetes running`的提示，这样就安装成功了。 每个人的 `Docker` 版本都有差别，不同版本如何查找各个依赖容器对应的版本呢？参考一下命令： @@ -160,26 +159,26 @@ NAME STATUS ROLES AGE VERSION docker-desktop Ready control-plane 11m v1.24.2 ``` -单机版本的`k8s`安装成功！接下来介绍集群安装。 +单机版本的 `k8s`安装成功！接下来介绍集群安装。 -### 集群安装 +## 集群安装 #### 准备 - 准备三台机器，比如（使用的配置是4核8G，IP换成你自己的）： + - 192.168.5.91：Master： - 执行： - - `hostnamectl set-hostname master` + - `hostnamectl set-hostname master` - `echo "127.0.0.1 $(hostname)" >> /etc/hosts` - 192.168.5.92：Node01 - 执行： - - `hostnamectl set-hostname node01` + - `hostnamectl set-hostname node01` - `echo "127.0.0.1 $(hostname)" >> /etc/hosts` - 192.168.5.93：Node02 - 执行： - - `hostnamectl set-hostname node02` + - `hostnamectl set-hostname node02` - `echo "127.0.0.1 $(hostname)" >> /etc/hosts` - - Kubernetes版本：v1.19.3 - Docker版本：19.03.12 @@ -214,8 +213,6 @@ systemctl enable kubelet.service && systemctl start kubelet.service systemctl status kubelet.service ``` - - #### 初始化Master 在主节点（`192.168.5.91`）执行以下命令： @@ -227,7 +224,7 @@ export POD_SUBNET=10.100.0.1/16 echo "${MASTER_IP} ${APISERVER_NAME}" >> /etc/hosts ``` -新建脚本`init_master.sh`: +新建脚本 `init_master.sh`: ```shell vim init_master.sh @@ -294,9 +291,7 @@ echo 1 > /proc/sys/net/bridge/bridge-nf-call-iptables echo 1 > /proc/sys/net/bridge/bridge-nf-call-ip6tables ``` - - -检查`master`初始化结果： +检查 `master`初始化结果： ```shell # 直到所有的容器组处于 Running 状态 @@ -311,7 +306,7 @@ kubectl get nodes -o wide #### 获得join命令参数 -直接在`master`执行： +直接在 `master`执行： ```shell kubeadm token create --print-join-command @@ -326,7 +321,7 @@ kubeadm join apiserver.demo:6443 --token vh5hl9.9fccw1mzfsmsp4gh --discovery #### 初始化Node -在所有`node`执行： +在所有 `node`执行： ```shell export MASTER_IP=192.168.5.91 @@ -339,7 +334,7 @@ kubeadm join apiserver.demo:6443 --token vh5hl9.9fccw1mzfsmsp4gh --discovery #### 检查初始化结果 -在`master`节点执行： +在 `master`节点执行： ```shell kubectl get nodes -o wide @@ -349,7 +344,7 @@ kubectl get nodes -o wide ![image-20201221181016264](https://images-1252557999.file.myqcloud.com/uPic/image-20201221181016264.png) -### sealos 快速安装 +## sealos 快速安装 经过上面的流程，相信你也能体会到集群部署的麻烦，为了简化这个流程，`Github`上诞生了不少优秀的项目来简化安装流程，接下来以[sealos](https://github.com/fanux/sealos)为例进行命令行一键安装。 @@ -374,7 +369,7 @@ rm /etc/containerd/config.toml #### 安装 -选一台服务器，我选择安装`v1.22.0`版本，执行命令即可： +选一台服务器，我选择安装 `v1.22.0`版本，执行命令即可： ```shell sealos init --passwd 'pwd' --master 192.168.5.91 --node 192.168.5.92 --node 192.168.5.93 --pkg-url /root/kube1.22.0.tar.gz --version v1.22.0 @@ -382,7 +377,7 @@ sealos init --passwd 'pwd' --master 192.168.5.91 --node 192.168.5.92 --node 19 #### 检查初始化结果 -在`master`节点执行： +在 `master`节点执行： ```shell kubectl get nodes -o wide @@ -396,7 +391,7 @@ kubectl get nodes -o wide ### Kubernetes Dashboard -[Dashboard](https://github.com/kubernetes/dashboard)可以将容器化应用程序部署到`Kubernetes`集群，对容器化应用程序进行故障排除，以及管理集群资源。 +[Dashboard](https://github.com/kubernetes/dashboard)可以将容器化应用程序部署到 `Kubernetes`集群，对容器化应用程序进行故障排除，以及管理集群资源。 #### 安装 @@ -417,19 +412,19 @@ dashboard-metrics-scraper-8c47d4b5d-mfb6d 1/1 Running 0 83s 1 kubernetes-dashboard-6c75475678-bdwtn 1/1 Running 0 83s 10.1.0.6 docker-desktop ``` -如果执行完发现`STATUS`有`ContainerCreating`，可以查看日志找找原因（注意NAME）： +如果执行完发现 `STATUS`有 `ContainerCreating`，可以查看日志找找原因（注意NAME）： ```shell kubectl describe pod dashboard-metrics-scraper-8c47d4b5d-mfb6d --namespace=kubernetes-dashboard ``` -一般都是因为`metrics-scraper:v1.0.8`镜像下载不下来，可以手动执行下载： +一般都是因为 `metrics-scraper:v1.0.8`镜像下载不下来，可以手动执行下载： ```shell docker pull kubernetesui/metrics-scraper:v1.0.8 ``` -拉下来之后就妥了，还有一个问题就是选用的服务类型是`ClusterIP`（默认类型，服务只能够在集群内部可以访问），所以我们需要将访问形式改为`NodePort`（通过每个 Node 上的 IP 和静态端口访问）： +拉下来之后就妥了，还有一个问题就是选用的服务类型是 `ClusterIP`（默认类型，服务只能够在集群内部可以访问），所以我们需要将访问形式改为 `NodePort`（通过每个 Node 上的 IP 和静态端口访问）： ```shell kubectl --namespace=kubernetes-dashboard edit service kubernetes-dashboard @@ -455,7 +450,7 @@ kubernetes-dashboard NodePort 10.110.197.167 443:32171/TCP ![image-20201220201125802](https://images-1252557999.file.myqcloud.com/uPic/image-20201220201125802.png) -看界面需要生成`Token`： +看界面需要生成 `Token`： ```shell vim admin-user.yaml @@ -496,31 +491,31 @@ kubectl -n kubernetes-dashboard create -f admin-user-role-binding.yaml kubectl -n kubernetes-dashboard create token admin-user ``` -复制`token`到刚才的界面登录即可，登录后界面如下： +复制 `token`到刚才的界面登录即可，登录后界面如下： ![image-20201220201512486](https://images-1252557999.file.myqcloud.com/uPic/image-20201220201512486.png) -如果想延长`Token`的有效时间： +如果想延长 `Token`的有效时间： ![image-20201221204143993](https://images-1252557999.file.myqcloud.com/uPic/image-20201221204143993.png) -然后在`containners->args`加上`--token-ttl=43200`: +然后在 `containners->args`加上 `--token-ttl=43200`: ![g2tpdz](https://images-1252557999.file.myqcloud.com/uPic/g2tpdz.png) -通过`kubectl edit deployment kubernetes-dashboard -n kubernetes-dashboard `修改也行。 +通过 `kubectl edit deployment kubernetes-dashboard -n kubernetes-dashboard `修改也行。 ### KubePi > KubePi 是一个现代化的 K8s 面板，其允许管理员导入多个 Kubernetes 集群，并且通过权限控制，将不同 Cluster、Namespace 的权限分配给指定用户。 -使用`Docker`安装如下： +使用 `Docker`安装如下： ```shell docker run --privileged -d --restart always -v "`pwd`:/var/lib/kubepi" --name=kubepi --restart=unless-stopped -p 8080:80 kubeoperator/kubepi-server ``` -然后打开[KubePi地址](http://localhost:8080/)，输入用户名@密码`admin@kubepi`登录，登陆成功后设置`k8s`配置（集群列表->导入）： +然后打开[KubePi地址](http://localhost:8080/)，输入用户名@密码 `admin@kubepi`登录，登陆成功后设置 `k8s`配置（集群列表->导入）： ![13071660388227_.pic](https://images-1252557999.file.myqcloud.com/uPic/13071660388227_.pic.jpg) @@ -553,6 +548,7 @@ kubectl get services ## MINIKUBE https://minikube.sigs.k8s.io/docs/start/ + ## 参考 本部分内容有参考如下文章： @@ -569,4 +565,4 @@ https://minikube.sigs.k8s.io/docs/start/ - [sealos](https://github.com/fanux/sealos)：一条命令离线安装高可用kubernetes，3min装完，700M，100年证书，生产环境稳如老狗 - [follow-me-install-kubernetes-cluster](https://github.com/opsnull/follow-me-install-kubernetes-cluster)：和我一步步部署 kubernetes 集群 -[^1]:k8s项目的基础特性是 Google 公司在容器化基础设施领域多年来实践经验的沉淀与升华，`k8s`和`Swarm&Mesos`的竞争有兴趣可自行查询详细看看。 \ No newline at end of file +[^1]: k8s项目的基础特性是 Google 公司在容器化基础设施领域多年来实践经验的沉淀与升华，`k8s`和 `Swarm&Mesos`的竞争有兴趣可自行查询详细看看。 diff --git a/kubenets/03.管理.md b/kubenets/03.管理.md index 2bcb973a..ad0601c6 100644 --- a/kubenets/03.管理.md +++ b/kubenets/03.管理.md @@ -1,6 +1,5 @@ # 基础概念介绍 -![guitars-2912447_1920](https://images-1252557999.file.myqcloud.com/uPic/guitars-2912447_1920.jpg) 俗话说，磨刀不误砍柴工。上一章，我们成功搭建了k8s集群，接下来我们主要花时间了解一下k8s的相关概念，为后续掌握更高级的知识提前做好准备。 @@ -12,9 +11,10 @@ - `Namespace` ![](image/2022-08-22-21-08-35.png) + ## 1 引入 -让我们使用`Deployment`运行一个无状态应用来开启此章节吧，比如运行一个`nginx Deployment`（创建文件：`nginx-deployment.yaml`）： +让我们使用 `Deployment`运行一个无状态应用来开启此章节吧，比如运行一个 `nginx Deployment`（创建文件：`nginx-deployment.yaml`）： ```yaml apiVersion: apps/v1 @@ -40,7 +40,7 @@ spec: - containerPort: 80 ``` -配置文件第二行，有个`kind`字段，表示的是此时`yaml`配置的类型，即`Deployment`。什么是`Deployment`？这里我先不做解释，让我们先实践，看能不能在使用过程中体会出这个类型的概念意义。 +配置文件第二行，有个 `kind`字段，表示的是此时 `yaml`配置的类型，即 `Deployment`。什么是 `Deployment`？这里我先不做解释，让我们先实践，看能不能在使用过程中体会出这个类型的概念意义。 在终端执行： @@ -66,7 +66,7 @@ NAME READY STATUS RESTARTS AGE nginx-deployment-585449566-qslv5 1/1 Running 0 2m38s # 查看 Deployment 的信息 -kubectl describe deployment nginx +kubectl describe deployment nginx # 删除 Deployment kubectl delete deployment nginx-deployment @@ -80,33 +80,32 @@ kubectl describe pod nginx-deployment-585449566-qslv5 kubectl exec -it nginx-deployment-585449566-qslv5 -- /bin/bash ``` -此时我们已经成功在k8s上部署了一个实例的nginx应用程序。但是，等等！我们好像又看到了一个新的名词`Pod`，这又是什么？让我们带着疑问继续往下看吧。 +此时我们已经成功在k8s上部署了一个实例的nginx应用程序。但是，等等！我们好像又看到了一个新的名词 `Pod`，这又是什么？让我们带着疑问继续往下看吧。 ## 2 Pod > 在Kubernetes中，最小的管理元素不是一个个独立的容器，而是pod（目的在于解决容器间**紧密协作**关系的难题） - ![](image/2022-08-22-20-57-44.png) -`Pod`是一组并置的容器，代表了`Kubernetes`中的基本构建模块: +`Pod`是一组并置的容器，代表了 `Kubernetes`中的基本构建模块: -- 一个`Pod`包含： +- 一个 `Pod`包含： - 一个或多个容器（container） - 容器（container）的一些共享资源：存储、网络等 -- 一个`Pod`的所有容器都运行在同一个节点 +- 一个 `Pod`的所有容器都运行在同一个节点 - Node（节点）是 kubernetes 集群中的计算机，可以是虚拟机或物理机。每个 Node（节点）都由 master 管理。 - 一个 Node（节点）可以有多个Pod（容器组） 容器可以被管理，但是容器里面的多个进程实际上是不好被管理的，所以**容器被设计为每个容器只运行一个进程**。 -容器的本质实际上就是一个进程，**Namespace 做隔离，Cgroups 做限制，rootfs 做文件系统**。在一个容器只能运行一个进程的前提下，实际开发过程中一个应用是由多个容器紧密协作才可以成功地运行起来。因此，我们需要另一种更高级的结构来将容器绑定在一起，并将它们作为一个单元进行管理，这就是`Pod`出现的目的。 +容器的本质实际上就是一个进程，**Namespace 做隔离，Cgroups 做限制，rootfs 做文件系统**。在一个容器只能运行一个进程的前提下，实际开发过程中一个应用是由多个容器紧密协作才可以成功地运行起来。因此，我们需要另一种更高级的结构来将容器绑定在一起，并将它们作为一个单元进行管理，这就是 `Pod`出现的目的。 `Pod`另一个重要意义就是容器设计模式，这对传统虚拟机服务迁移起到了关键性的指导作用，`Kubernetes` 社区把**容器设计模**这个理论整理成了一篇小论文[《Design Patterns for Container-based Distributed Systems》](https://www.usenix.org/conference/hotcloud16/workshop-program/presentation/burns)，我也将这篇论文做了一个翻译，阅读地址[《设计模式——基于容器的分布式系统》](https://www.howie6879.cn/k8s/docs/03_appendix/00.%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F%E5%9F%BA%E4%BA%8E%E5%AE%B9%E5%99%A8%E7%9A%84%E5%88%86%E5%B8%83%E5%BC%8F%E7%B3%BB%E7%BB%9F/)。 ### 如何定义并创建一个Pod -创建文件`nginx-pod.yaml`: +创建文件 `nginx-pod.yaml`: ```shell apiVersion: v1 @@ -167,19 +166,19 @@ kubectl attach -it nginx -c shell kubectl delete -f nginx-pod.yaml ``` -这里简单介绍了用声明式API怎么创建`Pod`，但从技术角度看，`Pod`又是怎样被创建的呢？实际上`Pod`只是一个逻辑概念，`Pod`里的所有容器，共享的是同一个`Network Namespace`，并且可以声明共享同一个`Volume`。 +这里简单介绍了用声明式API怎么创建 `Pod`，但从技术角度看，`Pod`又是怎样被创建的呢？实际上 `Pod`只是一个逻辑概念，`Pod`里的所有容器，共享的是同一个 `Network Namespace`，并且可以声明共享同一个 `Volume`。 -`Pod`除了启动你定义的容器，还会启动一个`Infra`容器，这个容器使用的就是`k8s.gcr.io/pause`镜像，它的作用就是整一个`Network Namespace`方便用户容器加入，这就意味着`Pod`有以下特性： +`Pod`除了启动你定义的容器，还会启动一个 `Infra`容器，这个容器使用的就是 `k8s.gcr.io/pause`镜像，它的作用就是整一个 `Network Namespace`方便用户容器加入，这就意味着 `Pod`有以下特性： -- 内部直接使用`127.0.0.1`通信，网络设备一致（`Infra`容器决定） +- 内部直接使用 `127.0.0.1`通信，网络设备一致（`Infra`容器决定） - 只有一个IP地址 -- `Pod`的生命周期只跟`Infra`容器一致，而与用户容器无关 +- `Pod`的生命周期只跟 `Infra`容器一致，而与用户容器无关 ### 标签 -现在我们的集群里面只运行了一个`Pod`，但在实际环境中，我们运行数十上百个`Pod`也是一件很正常的事情，这样就引出了`Pod`管理上的问题，我们可以通过标签来组织`Pod`和所有其他`Kubernetes`对象。 +现在我们的集群里面只运行了一个 `Pod`，但在实际环境中，我们运行数十上百个 `Pod`也是一件很正常的事情，这样就引出了 `Pod`管理上的问题，我们可以通过标签来组织 `Pod`和所有其他 `Kubernetes`对象。 -前面`nginx-pod.yaml`里面就声明了`labels`字段，标签为`name`，相关操作记录如下： +前面 `nginx-pod.yaml`里面就声明了 `labels`字段，标签为 `name`，相关操作记录如下： ```shell # 查看标签 @@ -205,7 +204,7 @@ kubectl label pods nginx version- ### 命名空间 -利用标签，我们可以将`Pod`和其他对象组织成一个组，这是最小粒度的分类，当我们需要将对象分割成完全独立且不重叠的组时，比如我想单独基于`k8s`搭建一套`Flink`集群，我不想让我的`Flink`和前面搭建的`Nginx`放在一起，这个时候，命名空间（namespace）的作用就体现出来了。 +利用标签，我们可以将 `Pod`和其他对象组织成一个组，这是最小粒度的分类，当我们需要将对象分割成完全独立且不重叠的组时，比如我想单独基于 `k8s`搭建一套 `Flink`集群，我不想让我的 `Flink`和前面搭建的 `Nginx`放在一起，这个时候，命名空间（namespace）的作用就体现出来了。 ```shell # 列出所有的命名空间 @@ -219,7 +218,7 @@ kube-system Active 20d kubernetes-dashboard Active 19d ``` -让我们创建一个命名空间`vim cus-ns.yaml`，输入: +让我们创建一个命名空间 `vim cus-ns.yaml`，输入: ```shell apiVersion: v1 @@ -246,16 +245,16 @@ kubectl create -f nginx-pod.yaml -n cus-ns kubectl delete ns cus-ns ``` -这里我们可以暂时先做一个总结，如前面所说，`Pod`可以表示`k8s`中的基本部署单元。经过前面的讲解，你应该知道以下一些知识点： +这里我们可以暂时先做一个总结，如前面所说，`Pod`可以表示 `k8s`中的基本部署单元。经过前面的讲解，你应该知道以下一些知识点： -- 手动增删改查`Pod` +- 手动增删改查 `Pod` - 让其服务化（`Service`） -但是在实际使用中，我们并不会直接人工干预来管理`Pod`，为什么呢？当`Pod`健康出问题或者需要进行更新等操作时，人是没有精力来做这种维护管理工作的，但我们擅长创造工具来自动化这些繁琐的事情，所以我们可以使用后面介绍的`Deployment`。 +但是在实际使用中，我们并不会直接人工干预来管理 `Pod`，为什么呢？当 `Pod`健康出问题或者需要进行更新等操作时，人是没有精力来做这种维护管理工作的，但我们擅长创造工具来自动化这些繁琐的事情，所以我们可以使用后面介绍的 `Deployment`。 ### 外部访问 -此时我们已经启动了一个`nginx`，我们有哪些方法可以对`Pod`进行连接测试呢？ +此时我们已经启动了一个 `nginx`，我们有哪些方法可以对 `Pod`进行连接测试呢？ 可以使用如下命令： @@ -271,7 +270,7 @@ curl http://0.0.0.0:8088/ ![image-20210105230002954](https://images-1252557999.file.myqcloud.com/uPic/image-20210105230002954.png) -显然，成功访问，但是这个有个问题就是此端口不会长期开放，一旦一定时间内没有访问，就会自动断掉，我们需要其他的方式来进行访问，比如后面会提到的`Service`，这里就简单运行个命令，大家感受一下： +显然，成功访问，但是这个有个问题就是此端口不会长期开放，一旦一定时间内没有访问，就会自动断掉，我们需要其他的方式来进行访问，比如后面会提到的 `Service`，这里就简单运行个命令，大家感受一下： ```shell # 创建一个服务对象 @@ -296,17 +295,17 @@ curl http://0.0.0.0:32220/ > Service 服务的主要作用就是替代 Pod 对外暴露一个不变的访问地址 -在本文第二节`Pod`部分的`外部访问`小节，就已经提到并演示了`Service`，它很方便地将我们的服务端口成功开放给外部访问。 +在本文第二节 `Pod`部分的 `外部访问`小节，就已经提到并演示了 `Service`，它很方便地将我们的服务端口成功开放给外部访问。 ### 介绍 -我们的`Pod`是有生命周期的，它们可以被创建、销毁，但是一旦被销毁，这个对象的相关痕迹就没有了，哪怕我们用`ReplicaSet`让他又*复生*了，但是新`Pod` 的`IP`我们是没法管控的。 +我们的 `Pod`是有生命周期的，它们可以被创建、销毁，但是一旦被销毁，这个对象的相关痕迹就没有了，哪怕我们用 `ReplicaSet`让他又*复生*了，但是新 `Pod` 的 `IP`我们是没法管控的。 -很显然，如果我们的后端服务的接口地址总是在变，我们的前端人员心中定然大骂，怎么办？这就轮到`Service`出场了。 +很显然，如果我们的后端服务的接口地址总是在变，我们的前端人员心中定然大骂，怎么办？这就轮到 `Service`出场了。 ### 定义 Service -前面我们创建了一个名为`nginx-http`的`Services`，用的是命令行；接下来我们介绍一下配置文件的形式，在`nginx-deployment.yaml`后面增加以下配置： +前面我们创建了一个名为 `nginx-http`的 `Services`，用的是命令行；接下来我们介绍一下配置文件的形式，在 `nginx-deployment.yaml`后面增加以下配置： ```yaml --- @@ -327,17 +326,17 @@ spec: 相信上述配置，大部分的字段看起来都没什么问题了吧，先说一下端口这块的含义： -- nodePort：通过任意节点的`30068`端口来访问`Service` -- port：集群内的其他容器组可通过`8068`端口访问`Service` +- nodePort：通过任意节点的 `30068`端口来访问 `Service` +- port：集群内的其他容器组可通过 `8068`端口访问 `Service` - targetPort：`Pod`内容器的开发端口 -这里我想强调的是`type`字段，说明如下： +这里我想强调的是 `type`字段，说明如下： - ClusterIP：默认类型，服务只能够在集群内部可以访问 - NodePort：通过每个 Node 上的 IP 和静态端口（`NodePort`）暴露服务 - LoadBalancer：使用云提供商的负载均衡器，可以向外部暴露服务。 -关于`LoadBalancer`，基本上是云商会提供此类型，如果是我们自行搭建的，就没有此类型可选，但是很多开源项目默认是启用这种类型，我们可以自行打一个补丁来解决这个问题： +关于 `LoadBalancer`，基本上是云商会提供此类型，如果是我们自行搭建的，就没有此类型可选，但是很多开源项目默认是启用这种类型，我们可以自行打一个补丁来解决这个问题： ```shell kubectl patch svc {your-svc-name} -n default -p '{"spec": {"type": "LoadBalancer", "externalIPs":["0.0.0.0"]}}' @@ -361,19 +360,19 @@ nginx NodePort 10.110.245.214 8068:30068/TCP 11m curl http://0.0.0.0:30068/ ``` -除了前面提的两种方法（`NodePort`、`LoadBalancer`），还有另外一种方法——`Ingress`资源。我们为什么需要引入`Ingress`，最主要的原因是`LoadBalancer`需要公有的IP地址，自行搭建的就不要考虑了。 +除了前面提的两种方法（`NodePort`、`LoadBalancer`），还有另外一种方法——`Ingress`资源。我们为什么需要引入 `Ingress`，最主要的原因是 `LoadBalancer`需要公有的IP地址，自行搭建的就不要考虑了。 -而`Ingress`非常强大，它位于多个服务之前，充当集群中的**智能路由器**或入口点： +而 `Ingress`非常强大，它位于多个服务之前，充当集群中的**智能路由器**或入口点： ![Ingress.png](https://images-1252557999.file.myqcloud.com/uPic/ab886a9dd4e912cf6f5a1f3ed983ac4c.png) ## Deployment -窥一斑而知全豹，好好了解完`Pod`之后，再继续了解`k8s`的概念也就水到渠成了。我们一般不会直接创建`Pod`，毕竟通过创建`Deployment`资源可以很方便的创建管理`Pod`（水平扩展、伸缩），并支持声明式地更新应用程序。 +窥一斑而知全豹，好好了解完 `Pod`之后，再继续了解 `k8s`的概念也就水到渠成了。我们一般不会直接创建 `Pod`，毕竟通过创建 `Deployment`资源可以很方便的创建管理 `Pod`（水平扩展、伸缩），并支持声明式地更新应用程序。 ### 介绍 -本章第一小节**引入**部分就是以`Deployment`举例，当时启动配置文件我们看到了一个`Deployment`资源和一个`Pod`，查看命令如下： +本章第一小节**引入**部分就是以 `Deployment`举例，当时启动配置文件我们看到了一个 `Deployment`资源和一个 `Pod`，查看命令如下： ```shell kubectl get deployments @@ -396,33 +395,33 @@ NAME DESIRED CURRENT READY AGE nginx-deployment-585449566 1 1 1 10m ``` -嗯嗯~，让我们捋一捋，当我们创建一个`Deployment`对象时，`k8s`不会只创建一个`Deployment`资源，还会创建另外的`ReplicaSet `以及1个`Pod `对象。所以问题来了， `ReplicaSet`又是个是什么东西？ +嗯嗯~，让我们捋一捋，当我们创建一个 `Deployment`对象时，`k8s`不会只创建一个 `Deployment`资源，还会创建另外的 `ReplicaSet `以及1个 `Pod `对象。所以问题来了， `ReplicaSet`又是个是什么东西？ ### ReplicaSet -如果你更新了`Deployment`的`Pod`模板，那么`Deployment`就需要通过滚动更新（rolling update）的方式进行更新。 +如果你更新了 `Deployment`的 `Pod`模板，那么 `Deployment`就需要通过滚动更新（rolling update）的方式进行更新。 -而滚动更新，离不开`ReplicaSet`，说到`ReplicaSet`就得说到`ReplicationController`（弃用）。 +而滚动更新，离不开 `ReplicaSet`，说到 `ReplicaSet`就得说到 `ReplicationController`（弃用）。 -> `ReplicationController`是一种`k8s`资源，其会持续监控正在运行的pod列表，从而保证`Pod`的稳定（在现有`Pod`丢失时启动一个新`Pod`），也能轻松实现`Pod`的水平伸缩 +> `ReplicationController`是一种 `k8s`资源，其会持续监控正在运行的pod列表，从而保证 `Pod`的稳定（在现有 `Pod`丢失时启动一个新 `Pod`），也能轻松实现 `Pod`的水平伸缩 -`ReplicaSet`的行为与`ReplicationController`完全相同，但`Pod`选择器的表达能力更强（允许匹配缺少某个标签的Pod，或包含特定标签名的Pod）。所以我们可以将`Deployment`当成一种更高阶的资源，用于部署应用程序，并以声明的方式管理应用，而不是通过`ReplicaSet`进行部署，上述命令的创建关系如下图： +`ReplicaSet`的行为与 `ReplicationController`完全相同，但 `Pod`选择器的表达能力更强（允许匹配缺少某个标签的Pod，或包含特定标签名的Pod）。所以我们可以将 `Deployment`当成一种更高阶的资源，用于部署应用程序，并以声明的方式管理应用，而不是通过 `ReplicaSet`进行部署，上述命令的创建关系如下图： ![image-20210110174652178](https://images-1252557999.file.myqcloud.com/uPic/image-20210110174652178.png) -如上图，`Deployment`的控制器，实际上控制的是`ReplicaSet`的数目，以及每个`ReplicaSet`的属性。我们可以说`Deployment`是一个两层控制器： +如上图，`Deployment`的控制器，实际上控制的是 `ReplicaSet`的数目，以及每个 `ReplicaSet`的属性。我们可以说 `Deployment`是一个两层控制器： > Deployment-->ReplicaSet-->Pod -这种形式下滚动更新是极好的，但这里有个前提条件那就是`Pod`是无状态的，如果运行的容器必须依赖此时的相关运行数据，那么回滚后这些存在于容器的数据或者一些相关运行状态值就不存在了，对于这种情况，该怎么办？此时需要的就是`StatefulSet`（部署有状态的多副本应用）。 +这种形式下滚动更新是极好的，但这里有个前提条件那就是 `Pod`是无状态的，如果运行的容器必须依赖此时的相关运行数据，那么回滚后这些存在于容器的数据或者一些相关运行状态值就不存在了，对于这种情况，该怎么办？此时需要的就是 `StatefulSet`（部署有状态的多副本应用）。 ## StatefulSet -如果通过`ReplicaSet`创建多个`Pod`副本（其中描述了关联到特定持久卷声明的数据卷），那么这些副本都将共享这个持久卷声明的数据卷。 +如果通过 `ReplicaSet`创建多个 `Pod`副本（其中描述了关联到特定持久卷声明的数据卷），那么这些副本都将共享这个持久卷声明的数据卷。 ![img](https://images-1252557999.file.myqcloud.com/uPic/CB_3NC5VK5SeDyX6Np6Ln_00500.jpeg) -那如何运行一个pod的多个副本，让每个pod都有独立的存储卷呢？对于这个问题，之前学习的相关知识都不能提供比较好的解决方案。`k8s`提供了`Statefulset`资源来运行这类Pod，它是专门定制的一类应用，这类应用中每一个实例都是不可替代的个体，都拥有稳定的名字和状态。 +那如何运行一个pod的多个副本，让每个pod都有独立的存储卷呢？对于这个问题，之前学习的相关知识都不能提供比较好的解决方案。`k8s`提供了 `Statefulset`资源来运行这类Pod，它是专门定制的一类应用，这类应用中每一个实例都是不可替代的个体，都拥有稳定的名字和状态。 对于有状态的应用（实例之间有不对等的关系或者依赖外部数据），主要需要对以下两种类型的状态进行复刻： @@ -436,6 +435,6 @@ nginx-deployment-585449566 1 1 1 10m - [学习Kubernetes基础知识](https://kuboard.cn/learning/k8s-basics/kubernetes-basics.html) - [详解 Kubernetes Deployment 的实现原理](https://draveness.me/kubernetes-deployment/) - [Kubernetes 中文指南](https://jimmysong.io/kubernetes-handbook/concepts/deployment.html)：Deployment -- [Kubernetes 中文指南](https://jimmysong.io/kubernetes-handbook/concepts/service.html)：Service +- [Kubernetes 中文指南](https://jimmysong.io/kubernetes-handbook/concepts/service.html)：Service - [深入剖析Kubernetes](https://time.geekbang.org/column/intro/100015201?code=UhApqgxa4VLIA591OKMTemuH1%2FWyLNNiHZ2CRYYdZzY%3D)：容器编排部分 -- Kubernetes in Action中文版：第3、4、5、9章 \ No newline at end of file +- Kubernetes in Action中文版：第3、4、5、9章 diff --git a/kubenets/04.0.md b/kubenets/04.0.md deleted file mode 100644 index 8b137891..00000000 --- a/kubenets/04.0.md +++ /dev/null @@ -1 +0,0 @@ - diff --git a/kubenets/04.02Service.md b/kubenets/04.02Service.md index e69de29b..6c0a2cb9 100644 --- a/kubenets/04.02Service.md +++ b/kubenets/04.02Service.md @@ -0,0 +1,33 @@ +## 1 基本介绍 + +### 概念 + +Kubernetes Service是Kubernetes中的一个资源对象，用于定义一个逻辑服务。 + +Service为Pods提供了一个稳定的IP地址和DNS名称，以便其他应用程序可以通过这些标识符来访问该服务。 + +它还提供了负载均衡和服务发现的能力，可以将流量路由到一组具有相同标签的Pods中。 + +## 2 类型说明 + +* Headless +* ClusterIP +* NodePort +* LoadBalancer + +### HeadLess + + +### ClusterIp +ClusterIP类型将创建一个虚拟IP地址，该IP地址将绑定到Service上，并通过Kubernetes内部的代理进行转发。这种类型的服务只能在集群内部访问，并且通常用于内部服务之间的通信。 + + + +### NodePort + + +### LoadBalance + + + +## 原理介绍 diff --git a/kubenets/04.06Ingress.md b/kubenets/04.06Ingress.md new file mode 100644 index 00000000..259aa4d0 --- /dev/null +++ b/kubenets/04.06Ingress.md @@ -0,0 +1,16 @@ +# Helm + + +## 安装 + +前置条件 + +* kubernets集群 +* 安装配置helm + +``` +curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash +``` + + +## 使用 diff --git a/kubenets/03.持久化存储.md b/kubenets/05.持久化存储.md similarity index 100% rename from kubenets/03.持久化存储.md rename to kubenets/05.持久化存储.md