首页 文章 精选 留言 我的

精选列表

搜索[k8s]，共4073篇文章
优秀的个人博客,低调大师

K8S 生态周报 | 首个 Docker 官方 Action 发布

云栖号资讯：【点击查看更多行业资讯】在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！ 首个 Docker 官方 GitHub Action 发布了 从去年 Docker 将企业服务相关的业务出售给 Mirantis 之后，Docker 将重心放在助力开发者体验上，并为此做了一系列的努力。包括 1 月份发布了 Docker Desktop v2.2 ，提供了 WSL2 的新架构，以及新的交互式 Desktop Dashboard 等特性。 本周又发布了首个 Docker GitHub Action，简化了 CI/CD 的流程。 这其实也是从另一个角度来推进 DockerHub 的普及（比预期的晚了一些）。DockerHub 上一直都有构建 Docker 镜像的功能，但我个人感觉体验并不够好，从一般意义上来说，它不够灵活；另外我感觉它的调度略慢了一点（虽然现在在优化中了）。 但本次发布的 Docker GitHub Action 可以让用户可以更灵活的通过 GitHub Action 来定义自己的 workflow，并将镜像推送至镜像仓库。这里的镜像仓库并没有和 DockerHub 强制绑定，用户可以自定义镜像仓库的地址。 使用示例如下，完整的项目可参考 docker-github-action 。需要额外注意的是， 如果你的仓库是公开的，请注意将自己的用户名密码等设置为 secrets ，可参考下方示例，以防泄漏。 name: Build and push Docker images uses: docker/build-push-action@v1.0 with: # Username used to log in to a Docker registry. If not set then no login will occur username: ${{ secrets.DOCKER_USERNAME }} # Password or personal access token used to log in to a Docker registry. If not set then no login will occur password: ${{ secrets.DOCKER_TOKEN }} # Docker repository to tag the image with repository: ${{ secrets.DOCKER_USERNAME }}/${{ secrets.DOCKER_PROJECT }} # Automatically tags the built image with the git reference as per the readme tag_with_ref: true # Automatically tags the built image with the git short SHA as per the readme tag_with_sha: true # Path to run docker build from path: . # Name of the Dockerfile (Default is 'path/Dockerfile') dockerfile: Dockerfile # Always attempt to pull a newer version of the image always_pull: true # Adds labels with git repository information to the built image add_git_labels: true # Whether to push the image push: true 此外 Visual Studio Code Docker extension 1.0 也在本周发布了！据说比之前版本的都好用，使用 vsc 的小伙伴可以尝试下。 etcd v3.4.5 发布 etcd 本周发布的 v3.4.5 包含了一些： 11704 在 server 端的日志中记录了 /health 的检查结果，主要是为了便于在 etcd 挂掉时分析根因； 11694 修复了一个在处理 metrics 可能引起的异常; 其他变更，请参考其 ReleaseNote Trivy 授权协议变更为 Apache-2.0 Aqua Security 开源的 trivy 是一款镜像漏洞安全扫描程序，对 CI 友好。 可能有些小伙伴不太了解 Aqua Security 这家公司，但大多数人都或多或少用过或者了解过它的一些开源项目： kubectl-who-can kube-bench kube-hunter 近期，trivy 的授权协议从 AGPL v3 修改成了 Apache-2.0，这个事情的意义在于，更多的厂商或者公司可以不用担心 trivy 自身的授权协议，可以在自己的产品或者环境中集成使用 trivy 了！ 目前包括 Harbor，Docker 及 Mirantis Docker Enterprise 等正在或者将使用 trivy 作为其默认镜像安全扫描工具。 但需要注意的是，trivy 使用的数据源有些是还是禁止商用来着。 上游进展 这是一个对 Kubernetes v1.16 的修复，将一系列主线中的修复都合并到了 v1.16 。这里专门提到它，是因为如果你集群中有很多节点变 NotReady 时，可能会导致 control plane 超载，出现不可用的情况。主要的修正都在 NodeLifecycleController 上，建议想要使用或者正在 v1.16 版本的用户关注下此问题（如果集群规模不大，那受此问题影响的可能性比较小），详情请查看 #88959。 项目推荐 Reloader 是一个 Kubernetes controller ，它会 watch ConfigMap 或 Secrets，然后对使用这些资源的 Pod 执行滚动升级。 注意它只兼容 Kubernetes v1.9 及以上。如果有相关需求的小伙伴可以进行尝试。 【云栖号在线课堂】每天都有产品技术专家分享！课程地址：https://yqh.aliyun.com/zhibo 立即加入社群，与专家面对面，及时了解课程最新动态！【云栖号在线课堂 社群】https://c.tb.cn/F3.Z8gvnK 原文发布时间：2020-03-24本文作者：张晋涛本文来自：“掘金”，了解相关信息可以关注“掘金”
2020-03-24
优秀的个人博客,低调大师

使用K8s遇难题？Istio来帮您！

如果你正在使用容器，特别是Kubernetes，那么你应该也听说过Istio。对于初学者来说，Istio是Kubernetes的服务网格（service mesh）。所谓服务网格，它是一个网络层，并且可以动态管理服务流量，然后以安全的方式进行管理。 如何充分使用Istio，这不是一篇博客文章能阐述清楚的。因此，在本文中我将介绍一些它的特性，更重要的是，你可以通过这篇文章，了解到一些方法来自动化解决某些实际问题。 Istio可以让你使用一组自定义Kubernetes资源来管理网络流量，并且可以帮助你保护和加密服务之间以及集群内外的网络流量。它全面集成了Kubernetes API，这意味着可以使用与其他Kubernetes配置完全相同的方式来定义和管理Istio设置。 权衡利弊,再做选择 如果要开始使用Istio，首先应该问自己为什么。Istio提供了一些非常有价值的功能，如金丝雀发布等，但是如果不增加一些复杂性，就无法使用它们。你还需要投入一定的时间来学习它。也就是说，如果你的情况合适使用它，你可以（并且应该）在自己的集群中谨慎且逐步地采用Istio的功能。 如果你要从头开始构建新环境，并且经过利弊权衡决定继续使用Istio，那么一定要从一开始就使用严格的相互TLS对其进行设置，并积极使用其强大的功能。具体操作请参考： https://istio.io/docs/setup/install/kubernetes/#installation-steps 为了使一切都有价值并且具有一定的性价比，我们需要在实际应用程序的上下文中考虑Istio，但是如果没有快速免责声明的话，最好不要这样做。如果你只需要管理少量服务（且位于单个集群内），那么引入Istio的性价比相对而言没有那么高。 本文中的代码示例不一定能够完全帮助你解决你的问题，但是如果你需要所有的代码以及如何使用它的详细说明都可以在GitLab上找到： https://gitlab.com/ContainerSolutions/k8s-deployment-mtl/ 接下来是你在Cloud Native旅程中可能遇到的两个常见问题，以及如何使用Istio来解决这些问题。 问题1：我不相信我的测试 如果测试范围并没有完全涵盖你所更改的应用程序，那么你可能会很快采取行动进行新一轮测试，但也有可能应用程序无法正常运行了。 在理想状况下，我们都想要确保每个代码经过全面的测试，否则就不会将功能添加到应用程序中。但是现实总归是骨感的，我们常常被ddl追赶，可能还未编写或者更新测试，功能就得上传到项目中了。 解决方案：放慢速度 那么，如何确保我绝大多数用户不受代码中潜伏的任何错误的影响，又如何进行更改和部署新功能呢？答案是通过先将新版本部署到最少数量的用户来最大程度地减少这些小问题的辐射范围。 如果更改能够按照预期工作的话，你可以缓慢增加使用新版本的用户百分比。如果各项指标出现问题，你可以轻松回滚你的更改，然后重试。 在没有Istio的情况下可以在Kubernetes上运行金丝雀部署吗？当然没问题，但是如果要自动化这一过程，你需要完全将自己的精力放在web服务器代码和自定义自动化脚本方面。这样的操作方式性价比并不高。 Istio有一些十分优雅的流量分配解决方案，我们可以使用它们在恰当的时间为合适的版本提供适当的客户端服务，并且我们只需调整其中的1个或2个参数。 为了实现这一点，你需要设置一个网关入口（Ingress gateway）、一个虚拟服务（virtual service）和一个destination rule。这将位于一般的部署和服务之上，并为你分配流量。 apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: http-gateway spec: selector: istio: ingressgateway servers: - port: number: 80 name: http protocol: HTTP hos ts: - "*" --- apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: my-app spec: hosts: - "*" gateways: - http-gateway http: - match: - uri: prefix: "/my-app" rewrite: uri: "/" route: - destination: host: my-app subset: v1 port: number: 80 weight: 90 - destination: host: my-app subset: v2 port: number: 80 weight: 10 --- apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: my-app spec: host: my-app subsets: - name: v1 labels: version: v1.0.0 - name: v2 labels: version: v2.0.0 从虚拟服务的权重字段中可以看到，Istio将根据指定的值在应用程序的两个版本之间分配流量。这些值的总和必须为100％，否则，API将拒绝应用该定义。 然后，你（或者理想情况下，在“持续集成/连续交付”流水线中手动执行一个或多个步骤）将调整权重，以将新版本推广给更多用户，直到所有请求由新版本满足为止，并且以前的版本可以停止维护。 通过使用Istio的故障注入功能来模拟网络中断和实际流量性能下降，还可以将Istio集成到您的集成测试策略中。 如果在生产中进行测试的想法给你留下了心理阴影，那一定是你的做法有所欠缺。例如，尝试在你的虚拟服务规范中添加以下代码片段以添加一些混乱，然后再找一篇文章来看看怎么用Istio解决这样的混乱。 spec: hosts: - my-app http: - fault: delay: fixedDelay: 7s percent: 100 route: - destination: host: ratings subset: v2 问题2：市场策略无法确定发布版本 通常，业务需要针对实际用户测试应用程序的多个版本。但是有时实在无法搞清楚是哪种营销策略可以带来最佳转化率，或者哪种设计选择可以带来最佳的客户留存率。 使用Kubernetes，你可以将流量分为两个版本，但是要想从练习中获得任何有价值的见解，则再次需要一大堆自定义代码来获取相关信息，并以非技术同事可以理解的方式对其进行处理。 解决方案：使用Istio进行A/B测试 Istio的流量分配规则可以再次解决这一问题，它与Prometheus和Grafana的紧密集成可以帮助你获取直观的A/B测试的结果。一般而言，根据传入数据包内容的某些部分，几乎有无数种方法来决定哪些用户可以获取你的应用程序的版本。 在这一示例中，我们将使用User-Agent字段为不同的浏览器提供不同的版本。 apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: my-app spec: hosts: - "*" gateways: - http-gateway http: - match: - headers: user-agent: regex: ".*Chrome.*" uri: prefix: "/my-app" rewrite: uri: "/" route: - destination: host: my-app subset: v1 port: number: 80 - match: - headers: user-agent: regex: ".*Mozilla.*" uri: prefix: "/my-app" rewrite: uri: "/" route: - destination: host: my-app subset: v2 port: number: 80 从上面的代码中可以看到，使用Firefox的用户将获得应用程序的版本1，而Chrome用户将获得版本2。如果浏览器的“User-Agent”字段不包含“mozilla”或“chrome”，则他们都将不会获得任一版本。 要为其他客户提供服务，您需要添加一条默认路由，我将作为练习留给你。（嘿嘿） 如果你不想安装其他浏览器，只是想尝试一下，则可以使用带有头部标志的curl伪装成所需的任何浏览器，例如： curl /my-app -H "User-Agent: Chrome" 通过更改user-agent的值，你可以从命令行测试所有不同的路由。 总 结 以上两种情况大概能让你体验到Istio强大功能的冰山一角。正如上文所说，如果没有Istio，你依然可以进行金丝雀部署和A/B测试，只是你必须自己实现流量分配。但这大大增加了开发部署的复杂性，实属性价比低之选。 我希望这篇文章可以让你对Istio的实际应用有很好的理解，并且十分期待你自己尝试一下。如果你想了解更多关于Istio的信息，可以访问它们的官网，上面有许多有用的资料：https://istio.io/ 值得一提的是，Rancher 2.3 Preview2版本上开始支持Istio，用户可以直接在UI界面中启动Istio并且可以为每个命名空间注入自动sidecar。此外，Rancher简化Istio的安装和配置，内置了一个支持Kiali的仪表盘，用于流量和遥测的可视化，然后用Jaeger进行追踪，甚至还有自己的Prometheus和Grafana（与用于高级监控的实例不同）。这一切让部署和管理Istio变得简单而快速。 有关发行说明和安装步骤，请访问GitHub： https://github.com/rancher/rancher/releases/tag/v2.3.0-alpha5
2019-09-24
优秀的个人博客,低调大师

容器服务K8S 实践与踩坑记录

1.前言 ： 容器服务 kubernetes 是目前炙手可热的云原生基础设施，笔者过去一年上线了一个用户数极速增长的应用：该应用一个月内日活用户从零至四千万，用户数从零到一亿的裂变式增长，充分享受了容器服务快速简便的扩容操作和高可用特性。 但是，容器服务毕竟是阿里云新产品，存在各式各样的坑，笔者使用容器服务 Kubernetes 集群 将公司内系统完全上云1年多，记录一下其中的踩坑与优化记录。 2. 创建集群 创建集群时，做好规划，选择优化好的集群配置，可以大大减少后期运维工作，其中部分集群的配置时候在建立后再也没法修改或者修改极其麻烦。 2.1 集群规划 网络规划： 网络类型: Flannel、Terway； Terway 是阿里云容器服务自研的网络插件，功能上完全兼容Flan
2019-08-26
优秀的个人博客,低调大师

云效发布不同租户 k8s 应用

1. 需求 开发环境是开发测试人员使用的应用环境，除了应用运行依赖的云产品，还需要购买开发人员使用的云产品和运维产品。 主要有： 云效持续集成 maven 私有仓库 gitlib 代码仓库 Node模块仓库 镜像仓库购买 开发环境应用运行环境 2.云效与相关配置 2.1 maven 代码仓库： 私有仓库配置： maven 工具的 profiles 节点，增加私有仓库的 repository; settings 文件加入代码库根目录或者根目录下 pom.xml 增加 repository节点，指向私有仓库。 上传私有仓库： 使用migrate-local-repo-tool.jar(来自开源工具) 上传： $ java -jar migrate-local-repo-tool.jar -cd "/$HOME/.m2/repositor
2019-08-26
优秀的个人博客,低调大师

K8S自己动手系列 - 2.3 - PV & PVC

前言 在实验2.2 – Deployment中，我们将原来基于Pod部署的wordpress+mysql成功改造成基于Deployment部署，基于Deployment部署有很多好处，例如：支持滚动升级（Rolling Update），支持水平扩展。 不过有个问题，就是当我们的Deployment修改了，或者Pod删除重建了，数据也随之丢失了，这是我们不希望看到的，本篇文章我们就来尝试一下基于PV & PVC保存数据状态的有状态应用。 场景 对于单实例的有状态应用，我们可以定义Deployment并且replicas只能为1，用指定PVC的方式关联到一个PV上，使用PV提供的状态存储功能。如果要启动多实例，那么Deployment就无法胜任这个任务，必须使用到我们后面会讲到的StatefulSet+PVC Template的方式创建多实例对多PVC的模型。 本文实验所有的源码保存在：https://github.com/zrbcool/blog-public/tree/master/k8s-hands-on/lab06 实战 PVC定义 lab06 git:(master) cat 03-wordpress-pvc.yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: wordpress-pv-claim spec: accessModes: - ReadWriteOnce resources: requests: storage: 2Gi 部署后查看状态 lab06 git:(master) kubectl apply -f 03-wordpress-pvc.yaml persistentvolumeclaim/wordpress-pv-claim created lab06 git:(master) kubectl get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE wordpress-mysql-pv-claim Pending 4s 发现PVC处于Pending状态，追查下原因 lab06 git:(master) kubectl describe pvc/wordpress-mysql-pv-claim Name: wordpress-mysql-pv-claim Namespace: default StorageClass: Status: Pending Volume: Labels: <none> Annotations: kubectl.kubernetes.io/last-applied-configuration: {"apiVersion":"v1","kind":"PersistentVolumeClaim","metadata":{"annotations":{},"name":"wordpress-mysql-pv-claim","namespace":"default"},"s... Finalizers: [kubernetes.io/pvc-protection] Capacity: Access Modes: VolumeMode: Filesystem Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal FailedBinding 6s (x4 over 36s) persistentvolume-controller no persistent volumes available for this claim and no storage class is set Mounted By: <none> 接下来我们创建PV PV定义 查看定义 lab06 git:(master) cat 04-wordpress-pv.yaml kind: PersistentVolume apiVersion: v1 metadata: name: wordpress-mysql-pv-volume labels: type: local spec: capacity: storage: 2Gi accessModes: - ReadWriteOnce hostPath: path: "/data/pv/wordpress/mysql" 该pv定义是基于hostPath的方式，所以我们要在节点上提前创建好目录，如下： lab06 git:(master) mkdir -p /data/pv/wordpress/mysql lab06 git:(master) kubectl create -f 04-wordpress-pv.yaml persistentvolume/wordpress-mysql-pv-volume created lab06 git:(master) kubectl get pv NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE wordpress-mysql-pv-volume 2Gi RWO Retain Bound default/wordpress-mysql-pv-claim 31s lab06 git:(master) kubectl get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE wordpress-mysql-pv-claim Bound wordpress-mysql-pv-volume 2Gi RWO 118s 此时我们之前定义的pvc也已经成功绑定了 使Deployment使用该PVC 查看定义 lab06 git:(master) cat 01-wordpress-mysql-deployment.yaml apiVersion: extensions/v1beta1 kind: Deployment metadata: labels: app: wordpress name: wordpress spec: replicas: 1 selector: matchLabels: app: wordpress template: metadata: labels: app: wordpress spec: containers: - image: wordpress:latest imagePullPolicy: IfNotPresent name: wordpress env: - name: WORDPRESS_DB_HOST value: "127.0.0.1" - name: WORDPRESS_DB_USER value: "root" - name: WORDPRESS_DB_PASSWORD value: "passw0rd" - image: mysql:5.7.26 imagePullPolicy: IfNotPresent name: mysql env: - name: MYSQL_ROOT_PASSWORD value: "passw0rd" - name: MYSQL_DATABASE value: "wordpress" volumeMounts: - name: mysql-persistent-storage mountPath: /var/lib/mysql volumes: - name: mysql-persistent-storage persistentVolumeClaim: claimName: wordpress-mysql-pv-claim 执行更新并查看效果 lab06 git:(master) kubectl apply -f 01-wordpress-mysql-deployment.yaml deployment.extensions/wordpress configured lab06 git:(master) kubectl get pod NAME READY STATUS RESTARTS AGE wordpress-6cfd879fcd-9mlhb 2/2 Running 0 29s lab06 git:(master) ls -l /data/pv/wordpress/mysql/ total 188480 -rw-r----- 1 999 999 56 Jun 10 23:42 auto.cnf -rw------- 1 999 999 1675 Jun 10 23:42 ca-key.pem -rw-r--r-- 1 999 999 1107 Jun 10 23:42 ca.pem ... drwxr-x--- 2 999 999 12288 Jun 10 23:42 sys drwxr-x--- 2 999 999 4096 Jun 10 23:42 wordpress 可见，Pod已经在/data/pv/wordpress/mysql/下产生数据了，接下来我们来试一下配置数据后，删除Pod，使Deployment控制Pod重建，配置数据是否能够保存通过下面命令删除Pod使其重建 lab06 git:(master) kubectl get pod NAME READY STATUS RESTARTS AGE wordpress-6cfd879fcd-9mlhb 2/2 Running 0 7m34s lab06 git:(master) kubectl delete pod/wordpress-6cfd879fcd-9mlhb pod "wordpress-6cfd879fcd-9mlhb" deleted lab06 git:(master) kubectl get pod NAME READY STATUS RESTARTS AGE wordpress-6cfd879fcd-29qg9 2/2 Running 1 11s 刷新网页，发布的测试文件还在，测试成功 新问题 查看官网说明：意思是说，对于这个单实例的有状态Deployment不要对其进行扩容，同时当Deployment定义发生更新时也不能使用滚动更新，而应该先删除再创建，也就是strategy: type: Recreate修改后的文件如下： lab06 git:(master) cat 01-wordpress-mysql-deployment.yaml apiVersion: extensions/v1beta1 kind: Deployment metadata: labels: app: wordpress name: wordpress spec: strategy: type: Recreate replicas: 1 selector: matchLabels: app: wordpress template: metadata: labels: app: wordpress spec: containers: - image: wordpress:latest imagePullPolicy: IfNotPresent name: wordpress env: - name: WORDPRESS_DB_HOST value: "127.0.0.1" - name: WORDPRESS_DB_USER value: "root" - name: WORDPRESS_DB_PASSWORD value: "passw0rd" - image: mysql:5.7.26 imagePullPolicy: IfNotPresent name: mysql env: - name: MYSQL_ROOT_PASSWORD value: "passw0rd" - name: MYSQL_DATABASE value: "wordpress" volumeMounts: - name: mysql-persistent-storage mountPath: /var/lib/mysql volumes: - name: mysql-persistent-storage persistentVolumeClaim: claimName: wordpress-mysql-pv-claim 清除数据 lab06 git:(master) kubectl delete -f . deployment.extensions "wordpress" deleted service "wordpress-svc" deleted persistentvolumeclaim "wordpress-mysql-pv-claim" deleted persistentvolume "wordpress-mysql-pv-volume" deleted
2019-06-19
优秀的个人博客,低调大师

K8S自己动手系列 - 1.3 - Taint & Affinity

Taint please refer https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/三种taint： NoSchedule PreferNoSchedule NoExecute 为节点打Taint ~ kubectl taint node worker02 role=nginx:NoSchedule node/worker02 tainted ~ kubectl describe node worker02 Name: worker02 ... Taints: role=nginx:NoSchedule ~ kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES nginx-7cffb9df96-748j6 1/1 Running 0 5m21s 10.244.0.23 worker01 <none> <none> nginx-7cffb9df96-d2rt5 1/1 Running 0 5m22s 10.244.1.35 worker02 <none> <none> 通过查看pod，发现已经运行的pod并未受影响扩容pod，看下效果 ~ kubectl scale --replicas=5 deployment/nginx deployment.extensions/nginx scaled ~ kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES nginx-7cffb9df96-4rjhf 0/1 ContainerCreating 0 1s <none> worker01 <none> <none> nginx-7cffb9df96-748j6 1/1 Running 0 6m8s 10.244.0.23 worker01 <none> <none> nginx-7cffb9df96-89ngr 0/1 ContainerCreating 0 1s <none> worker01 <none> <none> nginx-7cffb9df96-d2rt5 1/1 Running 0 6m9s 10.244.1.35 worker02 <none> <none> nginx-7cffb9df96-zsgmd 0/1 ContainerCreating 0 1s <none> worker01 <none> <none> 通过实验发现由于taint NoSchedule的影响，新pod不会调度到含有污点的节点上 移除节点Taint ~ kubectl taint node worker02 role:NoSchedule- node/worker02 untainted 再次扩容，查看效果 ~ kubectl scale --replicas=10 deployment/nginx deployment.extensions/nginx scaled ~ kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES nginx-7cffb9df96-2wlln 1/1 Running 0 4s 10.244.1.38 worker02 <none> <none> nginx-7cffb9df96-4rjhf 1/1 Running 0 3m10s 10.244.0.26 worker01 <none> <none> nginx-7cffb9df96-748j6 1/1 Running 0 9m17s 10.244.0.23 worker01 <none> <none> nginx-7cffb9df96-89ngr 1/1 Running 0 3m10s 10.244.0.24 worker01 <none> <none> nginx-7cffb9df96-9vbdt 1/1 Running 0 4s 10.244.1.36 worker02 <none> <none> nginx-7cffb9df96-d2rt5 1/1 Running 0 9m18s 10.244.1.35 worker02 <none> <none> nginx-7cffb9df96-hqvfh 1/1 Running 0 4s 10.244.1.37 worker02 <none> <none> nginx-7cffb9df96-mhxmn 1/1 Running 0 4s 10.244.1.40 worker02 <none> <none> nginx-7cffb9df96-xdnzc 1/1 Running 0 4s 10.244.1.39 worker02 <none> <none> nginx-7cffb9df96-zsgmd 1/1 Running 0 3m10s 10.244.0.25 worker01 <none> <none> 发现新增加的pod已经可以调度到worker02上了 容忍节点Taint 重新为节点增加污点 ~ kubectl taint node worker02 role=nginx:NoSchedule node/worker02 tainted 然后在deploy定义中增加： tolerations: - key: "role" operator: "Equal" value: "nginx" effect: "NoSchedule" 通过kubectl diff -f xxx.yaml可以查看变化情况 lab02 kubectl diff -f nginx-deploy.yaml diff -u -N /tmp/LIVE-021075426/extensions.v1beta1.Deployment.default.nginx /tmp/MERGED-503027673/extensions.v1beta1.Deployment.default.nginx --- /tmp/LIVE-021075426/extensions.v1beta1.Deployment.default.nginx 2019-06-09 15:53:54.120907334 +0800 +++ /tmp/MERGED-503027673/extensions.v1beta1.Deployment.default.nginx 2019-06-09 15:53:54.128907426 +0800 @@ -4,7 +4,7 @@ annotations: deployment.kubernetes.io/revision: "8" creationTimestamp: "2019-06-08T04:27:19Z" - generation: 23 + generation: 24 labels: app: nginx name: nginx @@ -14,7 +14,7 @@ uid: b43106be-89a5-11e9-8ec2-080027a62701 spec: progressDeadlineSeconds: 2147483647 - replicas: 1 + replicas: 2 revisionHistoryLimit: 2147483647 selector: matchLabels: @@ -42,6 +42,11 @@ schedulerName: default-scheduler securityContext: {} terminationGracePeriodSeconds: 30 + tolerations: + - effect: NoSchedule + key: role + operator: Equal + value: nginx status: availableReplicas: 1 conditions: exit status 1 再次扩容，查看效果 lab02 kubectl get pods -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES nginx-859959cc7f-7sx2p 1/1 Running 0 4s 10.244.0.38 worker01 <none> <none> nginx-859959cc7f-8tpw7 1/1 Running 0 4s 10.244.0.39 worker01 <none> <none> nginx-859959cc7f-ffh7v 1/1 Running 0 4s 10.244.1.49 worker02 <none> <none> nginx-859959cc7f-j2xp7 1/1 Running 0 4s 10.244.0.37 worker01 <none> <none> nginx-859959cc7f-lht8b 1/1 Running 0 4s 10.244.1.47 worker02 <none> <none> nginx-859959cc7f-mcth6 1/1 Running 0 17s 10.244.0.36 worker01 <none> <none> nginx-859959cc7f-sx5ln 1/1 Running 0 4s 10.244.1.48 worker02 <none> <none> nginx-859959cc7f-tlxk5 1/1 Running 0 4s 10.244.1.46 worker02 <none> <none> nginx-859959cc7f-xkjtq 1/1 Running 0 4s 10.244.1.45 worker02 <none> <none> nginx-859959cc7f-xltkz 1/1 Running 0 17s 10.244.1.44 worker02 <none> <none> Affinity 上面通过节点污点的方式，我们可以避免pod被调度到含有污点的节点，同时也可以使某些pod容忍节点的污点，配合下面要说的affinity，可以实现特定节点为特定pod专用的目的 NodeSelector 在pod定义中增加如下： nodeSelector: kubernetes.io/hostname: worker02 执行查看效果 lab02 kubectl apply -f nginx-deploy-toleration-nodeselector.yaml deployment.extensions/nginx configured lab02 kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES nginx-564c745dcd-6dtz7 1/1 Running 0 25s 10.244.1.56 worker02 <none> <none> nginx-564c745dcd-fw8kt 1/1 Running 0 25s 10.244.1.55 worker02 <none> <none> nginx-564c745dcd-l8k7m 1/1 Running 0 22s 10.244.1.58 worker02 <none> <none> nginx-564c745dcd-mvqjd 1/1 Running 0 28s 10.244.1.53 worker02 <none> <none> nginx-564c745dcd-qn6r9 1/1 Running 0 29s 10.244.1.52 worker02 <none> <none> nginx-564c745dcd-rbl57 1/1 Running 0 27s 10.244.1.54 worker02 <none> <none> nginx-564c745dcd-s2jbm 1/1 Running 0 19s 10.244.1.59 worker02 <none> <none> nginx-564c745dcd-wnd45 1/1 Running 0 30s 10.244.1.50 worker02 <none> <none> nginx-564c745dcd-zlnfg 1/1 Running 0 30s 10.244.1.51 worker02 <none> <none> nginx-564c745dcd-zm7qx 1/1 Running 0 22s 10.244.1.57 worker02 <none> <none> NodeAffinity NodeAffinity与NodeSelector有相似的作用，但是相比之下有更加灵活的表达语义please refer： https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity
2019-06-16
优秀的个人博客,低调大师

使用Minikube 搭建最简易的K8S 集群

Minikube Minikuge 是一个跨平台的，可以在本地环境搭起的最简单的一个集群的一个工具。 安装步骤 kubectl kubectl的安装参考官网地址 $ curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl $ chmod +x ./kubectl $ sudo mv ./kubectl /usr/local/bin/kubectl ...... Minikube 参考官方地址 安装 minikube 有两种方式 第一种 $ brew cask install minikube $ sudo mv minikube /usr/local/bin ...... 第二种 $ curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-darwin-amd64 \ && chmod +x minikube $ sudo mv minikube /usr/local/bin ...... 启动 $ minikube start ......
2019-04-26

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

时间: 2026-04-11 大小: 211.28KB 下载: 56次
Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

时间: 2026-09-24 大小: 189MB 下载: 9次
Spring

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

时间: 2026-08-21 大小: 5MB 下载: 2次
Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能，例如代码缩略图，Python的插件，代码段等。还可自定义键绑定，菜单和工具栏。Sublime Text 的主要功能包括：拼写检查，书签，完整的 Python API ， Goto 功能，即时项目切换，多选择，多窗口等等。Sublime Text 是一个跨平台的编辑器，同时支持Windows、Linux、Mac OS X等操作系统。

时间: 2026-08-21 大小: 9.84MB 下载: 40次
热门标签
DeepSeek Jdk25 OpenAi HarmonyOS6 Nacos3 SpringBoot4 SpringCloud Docker Kubernetes Service Mesh Redis Gemini3 Rocky

欢迎您来访！

登录后，您将获得更多功能！
热门文章
联系我们

有任何问题或合作意向欢迎联系我们

Email: 99873273@qq.com

QQ: 99873273

用户登录
用户注册