Kube

Kubernetes中提供了良好的多租户认证管理机制，如RBAC、ServiceAccount还有各种Policy等。 ServiceAccount Service Account为Pod中的进程提供身份信息。 当用户访问集群（例如使用 kubectl 命令）时， apiserver 会将用户认证为一个特定的 User Account （ 目前通常是 admin ，除非系统管理员自定义了集群配置）。Pod 容器中的进程也可以与 apiserver 联系。 当它们在联系 apiserver 的时候，它们会被认证为一个特定的 Service Account（例如 default ）。 使用默认的 Service Account 访问 API server 　　当创建 pod 的时候， 如果没有指定一个 service account，系统会自动得在与该pod 相同的 namespace 下为其指派一个 default service account 。如果获取刚创建的 pod 的原始 json 或 yaml 信息（ 例如使用 kubectl get pods podename -o yaml 命令），将看到 spec.serviceAccountName 字段已经被设置为 default 。 　　可以在 pod 中使用自动挂载的 service account 凭证来访问 API，如

一，引言 　　上一节，我们使用Azure CLI 创建了Azure Resource Group 和 Azure Container Registry 资源，并且将本地的一个叫 “k8s.net.demo”的 images 推送到远端创建的私有的Docker Image Repo,今天接着上一篇我们学习一下Azure Kubernetes 服务，通过 Azure Portal 创建 Azure Kubernetes Service，并且希望将 Push 上去的Docker Image 部署到Azure Kubernetes 集群中 　　Azure Kubernetes Service 简称AKS，它托管的Kubernetes 环境，可以使我们在Azure中很轻松的部署和管理容器话的应用程序。AKS环境启用了自动更新，自愈和自动缩放等功能。Kubernetes 的集群主机由Azure 免费管理，创建AKS服务的时候，我们可以将集群主机交由Aure进行托管，另外一种是我们在创建的时候，将我们自己创建好的VMSS挂载到AKS服务上。我们只需要为节点所在其上运行的VM付费即可。 　　接下来，我们看看当前基础设施架构图 --------------------我是分割线-------------------- --------------------我是分割线----------------

一，引言 　　上一节，我们使用Azure CLI 创建了Azure Resource Group 和 Azure Container Registry 资源，并且将本地的一个叫 “k8s.net.demo”的 images 推送到远端创建的私有的Docker Image Repo,今天接着上一篇我们学习一下Azure Kubernetes 服务，通过 Azure Portal 创建 Azure Kubernetes Service，并且希望将 Push 上去的Docker Image 部署到Azure Kubernetes 集群中 　　Azure Kubernetes Service 简称AKS，它托管的Kubernetes 环境，可以使我们在Azure中很轻松的部署和管理容器话的应用程序。AKS环境启用了自动更新，自愈和自动缩放等功能。Kubernetes 的集群主机由Azure 免费管理，创建AKS服务的时候，我们可以将集群主机交由Aure进行托管，另外一种是我们在创建的时候，将我们自己创建好的VMSS挂载到AKS服务上。我们只需要为节点所在其上运行的VM付费即可。 　　接下来，我们看看当前基础设施架构图 --------------------我是分割线-------------------- --------------------我是分割线----------------

作为一名容器时代的程序员相信你已经或多或少接触过Docker，但同时你也会发现Docker虽然流行了多年，但之前却很少有公司直接将线上应用通过Docker容器进行大规模地部署。但最近三年，你会发现几乎绝大多数有条件的公司都已经在使用Kubernetes部署和发布自己的线上业务了。对一名普通开发人员来说，这一切可能发生得太快，以至于你还没有搞清楚它是怎么发生的，也会疑惑Docker和Kubernetes之间到底是个什么关系。 在今天的内容中，我们从Kubernetes的系统架构及容器编排核心概念两个方面来简单聊一聊这个问题，希望能帮助到你更好地理解Docker和Kubernetes之间因果关系。 Kubernetes介绍 在具体介绍Kubernetes之前不得不再提一下Docker，如果你用过Docker部署过程序，那么你一定会非常享受它带给你的丝滑体验，而联想到在此之前发布一个程序需要写各种脚本、进行各种环境匹配的糟糕体验，那么相信你的这种感觉会更加强烈。 而Docker之所以能做到这一点，就在于它以“Docker镜像”的方式一举解决了应用打包和发布这一困扰业界多年的技术难题，并且大大降低了普通开发人员运维部署应用的门槛。正是因为解决了应用打包这个根本性的问题，才使得Docker很快就被广大开发/运维人员所接受，迅速成为炙手可热的技术，并在一定时间内引领了容器化技术发展的浪潮。

作者 | 淮右、临石 **导读：**单 K8s 集群为用户提供了 Namespace 级别的隔离能力，理论上支持不超过 5K Node、15W Pod。多 K8s 集群则解决了单集群的资源隔离、故障隔离难题，打破可支持节点数、Pod 数的限制，但与此同时也带来了集群管理复杂度的上升；尤其在专有云场景中，K8s 工程师不可能像在公有云中一样快速触达客户环境，运维成本被进一步放大。因此如何低成本、高效率、自动化低管理多套 K8s 集群，成为业内普遍难题。 背景 多集群主要应用在如下场景： 1.产品本身需要多集群能力。产品的管控需要部署在 K8s 集群内，同时，该产品还需要提供 K8s 集群给用户使用，从故障隔离、稳定性、安全多重角度考虑，容器服务的管控和业务应该分别部署在不同的集群内； 2.用户在使用 K8s 的时候，也希望具备生产多套集群供不同业务使用，从而进行资源隔离、故障隔离； 3.同一用户可能需要多种类型集群的能力，以边缘计算 IOT 为例，它需要一个定制的边缘 K8s 集群，如果按照普通的独立 K8s 集群来创建，一方面会存在资源浪费，另一方面独立的集群为用户增加了运维的成本。 我们总结了运维 K8s 集群的难点，可以分为两部分： 难点 1：运维 K8s 集群的管控面 如何支持用户一键弹出新的 Kubernetes 集群？ 如何升级多个 K8s 集群的版本，当社区重大 CVE

作者：Sudip Sengupta 翻译： Bach （才云） 校对： bot （才云）、 星空下的文仔 （才云） 在 Kubernetes 中，创建、删除 Pod 可以说是最常见的任务之一。当我们进行滚动更新、扩展部署等等，都会创建 Pod。另外，在我们将节点标记为不可调度时，Pod 被驱逐后也会被删除并重新创建。 这些 Pod 的生命周期非常短暂，如果 Pod 还在响应请求的过程中，就被关闭了会怎么样？ 关闭前的请求是否已完成？ 接下来的请求又如何呢？ 在讨论删除 Pod 时会发生什么之前，我们需要知道在创建 Pod 时会发生什么。假设我们在集群中创建了以下 Pod： 我们将Pod YAML 定义提交给集群： 在输入命令后，kubectl 就会将 Pod 定义提交给 Kubernetes API。 K8sMeetup 在数据库中保存集群状态 API 接收并检查 Pod 定义，然后将其存储在 etcd 数据库中。另外，Pod 将被添加到调度程序的队列中。 调度程序会检查 Pod 定义，再收集有关工作负载的详细信息，例如 CPU 和内存请求，然后确定哪个节点最适合运行它。在调度程序结束后： 在 etcd 中的 Pod 会被标记为 Scheduled。 Pod 被分配到一个节点。 Pod 的状态会存储在 etcd 中。 但是 Pod 此时仍然是不存在的

系统初始化 集群规划 主机名 地址 组件 备注 k8s-m-1 10.66.10.26 ha+keeplaive kube-apiserver kube-controller_manager kube-scheduler vip :10.66.10.3 k8s-m-2 10.66.10.27 k8s-m-3 10.66.10.28 k8s-w-1 10.66.10.31 docker flannel kubelet kube-proxy k8s-w-2 10.66.10.32 k8s-w-3 10.66.10.33 ... ... k8s-w-10 10.66.10.40 主机名 设置永久主机名称，然后重新登录:（所有机器操作） hostnamectl set-hostname k8s-m-1 ... hostnamectl set-hostname k8s-w-10 设置的主机名保存在 /etc/hostname 文件中； 如果 DNS 不支持解析主机名称，则需要修改每台机器的 /etc/hosts 文件，添加主机名和 IP 的对应关系： cat >>/etc/hosts<<EOF 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost

作者 | 新胜 阿里云技术专家 导读： OpenYurt 开源两周以来，以非侵入式的架构设计融合云原生和边缘计算两大领域，引起了不少行业内同学的关注。阿里云推出开源项目 OpenYurt，一方面是把阿里云在云原生边缘计算领域的经验回馈给开源社区，另一方面也希望加速云计算向边缘延伸的进程，并和社区共同探讨未来云原生边缘计算架构的统一标准。为了更好地向社区和用户介绍 OpenYurt，我们特地推出 【深度解读OpenYurt】 系列文章，本文为系列文章的第三篇，一一介绍了 OpenYurt 中组件 YurtHub 的扩展能力。 系列文章推荐： OpenYurt 开箱测评 | 一键让原生 K8s 集群具备边缘计算能力 深度解读 OpenYurt ：边缘自治能力设计解析 OpenYurt 介绍 阿里云边缘容器服务上线 1 年后，正式开源了云原生边缘计算解决方案 OpenYurt ，跟其他开源的容器化边缘计算方案的区别在于：OpenYurt 秉持 Extending your native Kubernetes to edge 的理念，对 Kubernetes 系统零修改，并提供一键式转换原生 Kubernetes 为 openyurt，让原生 K8s 集群具备边缘集群能力。 同时随着 OpenYurt 的持续演进，也一定会继续保持如下发展理念： 非侵入式增强 K8s

作者：Viswajith Venugopal 翻译： Bach （ 才云 ） 校对： bot （ 才云 ）、 星空下的文仔 （ 才云 ） Kubernetes 中的网络策略用于指定 Pod 组之间以及其与外部网络端点之间的通信，它就像是 Kubernetes 的防火墙。与大多数 Kubernetes 对象一样，网络策略非常灵活，功能也很强大。如果了解应用程序中服务的确切通信模式，我们就可以通过网络策略将通信限制在我们想要范围之内。 Ingress 与 Egress 网络策略可用于指定 Pod 的 入口（Ingress）** 流量 和 出口（Egress）流量**，其规则如下： 如果允许集群外部网络端点到 Pod 的通讯，那么该端点可以访问 Pod。 如果允许 Pod 到集群外部网络端点的通讯，那么 Pod 也可以访问该端点。 如果 Pod（A）到 Pod（B）的流量被允许，那么流量可以通过 A 的出口以及 B 的入口。注意这是单向的，流量从 B 到 A，那么只能从 B 的出口到 A 的入口。 设置 Ingress 在完成入** 口网络策略的设置并成功运行后，我们再设置出口网络策略**。这样做的原因有两个：首先，一次执行两项操作比较困难，而且我们很难知道是由于入口还是出口配置导致的网络连接失败；其次，出口网络策略通常更难以实施。限制出口可能会引发各种错误，从而影响应用程序运行。

一、管理k8s资源 1.管理k8s核心资源的三种基本方法 陈述式管理方法----主要依赖命令行cli工具进行管理 声明式管理方法--主要依赖统一资源配置清单（manifest）进行管理 GUI式管理方法--主要依赖图形化操作界面（web页面）进行管理 2.陈述式管理方法 2.1 管理namespace资源 ##查看名称空间 [root@kjdow7-21 ~]# kubectl get namespaces #或者 kubectl get ns NAME STATUS AGE default Active 4d18h kube-node-lease Active 4d18h kube-public Active 4d18h kube-system Active 4d18h ##查看名称空间内的资源 [root@kjdow7-21 ~]# kubectl get all -n default NAME READY STATUS RESTARTS AGE pod/nginx-ds-ssdtm 1/1 Running 1 2d18h pod/nginx-ds-xfsk4 1/1 Running 1 2d18h NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/kubernetes ClusterIP 192.168.0.1