pod

vSphere 7融合Kubernetes，构建现代化应用的平台 http://www.itpub.net/2020/03/13/5484/ 　　 题图摄于加州Monterey：太平洋的清晨 VMware 最新产品 vSphere 7 正式发布，致力于打造现代化应用平台，备受用户瞩目和期待。本文带你深入了解 vSphere 7 的原生 Kubernetes 功能，欢迎阅读。（本文仅代表作者个人观点。） VMware 在去年 VMWorld 介绍了云原生组合 Tanzu 和太平洋项目（Project Pacific）。3月11日，VMware 发布了近10年来最重要的一个版本：vSphere 7，包含众多的新功能。其中最引人注目的更新当属在 vSphere with Kubernetes (VwK) 功能，原生支持 Kubernetes 平台，实现了虚机和容器混合管理的能力，使 vSphere 成为全新的现代化应用开发运维平台。 vSphere with Kubernetes, 即之前的太平洋项目，对 vSphere 进行了多项的重构，引入了 Kubernetes 的概念和架构，以应用为中心，让开发人员和运维人员从不同的视图使用系统，带来里程碑式的革新。 VwK 在 VMware 公司内部已孕育了3年有多，目标深远、工程浩大，Kubernetes 联合创始人 Joe Beda

kubernetes http://docs.kubernetes.org.cn/227.html https://www.kubernetes.org.cn/k8s Kubernetes是容器集群管理系统，是一个开源的平台，可以实现容器集群的自动化部署、自动扩缩容、维护等功能。 通过Kubernetes你可以： 快速部署应用 快速扩展应用 无缝对接新的应用功能 节省资源，优化硬件资源的使用 可移植 : 支持公有云，私有云，混合云，多重云（multi-cloud） 可扩展 : 模块化, 插件化, 可挂载, 可组合 自动化 : 自动部署，自动重启，自动复制，自动伸缩/扩展 基础概念 http://docs.kubernetes.org.cn/92.html 对集群 Nodes Service Pod Deployment讲述的非常清楚，有图画形式，非常形象。 基本命令 http://docs.kubernetes.org.cn/683.html https://www.cnblogs.com/klvchen/p/9585746.html # 查看所有 pod 列表, -n 后跟 namespace, 查看指定的命名空间 kubectl get pod kubectl get pod -n kube kubectl get pod -o wide # 查看 RC 和 service

原文地址： 点这里 1. helm部署redis主从节点 1.1.确认仓库里有chart，redis chart版本号为10.5.7 1.2.部署redis一主二从节点 2. 部署redis 高可用哨兵模式 2.1.确认仓库里有chart，redis chart版本号为10.5.7 2.2. 部署redis 高可用 2.3.如果需要暴露给外部使用则需要再部署一个 NodePort Service 1. helm部署redis主从节点 1.1. helm部署redis条件 a. 准备storageClass服务作为永久存储，名称为nfs b. helm Client："v2.13.1"， Server:"v2.13.1" c. 仓库源为http://mirror.azure.cn/kubernetes/charts/ d. 确认仓库里有chart，redis chart版本号为10.5.7 [root@ops1 redis]# helm version Client: &version.Version{SemVer:"v2.13.1", GitCommit:"618447cbf203d147601b4b9bd7f8c37a5d39fbb4", GitTreeState:"clean"} Server: &version.Version{SemVer:"v2.13.1",

本指南适用于想要搭建一个定制化 Kubernetes 集群的人员。如果您在 列表 中找到现有的入门指南可以满足您的需求，那么建议使用它们，因为可从他人的经验中获益。但是，如果您使用特定的 IaaS，网络，配置管理或操作系统，同时又不符合这些指南的要求，那么本指南会为您提供所需的步骤大纲。请注意，比起其他预定义的指南，研习本指南需做出相当多的努力。 本指南对那些想要从更高层次了解现有集群安装脚本执行步骤的人员也很有用。 设计和准备 学习 您应该已经熟悉使用 Kubernetes 集群。建议按照如下入门指南启动一个临时的集群。首先帮您熟悉 CLI（kubectl）和概念（pods，services等）。 您的工作站应该已经存在 ‘kubectl’。这是完成其他入门指南后的一个附加安装。如果没有，请遵循 说明。 Cloud Provider Kubernetes 的 Cloud Provider 是一个模块，它提供一个管理 TCP 负载均衡，节点（实例）和网络路由的接口。此接口定义在 pkg/cloudprovider/cloud.go。未实现 Cloud Provider 也可以建立自定义集群（例如使用裸机），并不是所有的接口功能都必须实现，这取决于如何在各组件上设置标识。 节点 您可以使用虚拟机或物理机。 虽然可以使用一台机器构建集群，但为了运行所有的例子和测试，至少需要4个节点。

kubectl get pods 发现很多pod的状态为Evicted 原因 eviction，即驱赶的意思，意思是当节点出现异常时，kubernetes将有相应的机制驱赶该节点上的Pod。<br/>多见于资源不足时导致的驱赶，本次问题为磁盘不足导致。 解决办法 排查资源和异常原因，防止新的驱赶产生。处理资源问题后，删除Evicted状态pod，重新拉起 kubectl get pods | grep Evicted | awk '{print $1}' | xargs kubectl delete pod 来源： 51CTO 作者： 正义的阿根 链接： https://blog.51cto.com/13210651/2451633

由于node节点资源不足，造成资源的争抢，并出现大量的驱逐的pod，可以使用grep Evicted查看哪些pod [root@k8s-master istio-1.4.2]# kubectl get pods -n istio-system | grep Evicted grafana-6b65874977-2w54r 0/1 Evicted 0 21m grafana-6b65874977-pcctb 0/1 Evicted 0 21m grafana-6b65874977-s6mkb 0/1 Evicted 0 29m istio-galley-5fc6d6c45b-tlbzs 0/1 Evicted 0 25m istio-ingressgateway-6d759478d8-c8psq 0/1 Evicted 0 28m istio-pilot-5c4995d687-5jtwd 0/1 Evicted 0 21m istio-pilot-5c4995d687-678hg 0/1 Evicted 0 48m istio-pilot-5c4995d687-bxt8p 0/1 Evicted 0 21m istio-pilot-5c4995d687-c4zw8 0/1 Evicted 0 21m istio-pilot-5c4995d687-cv79t 0/1 Evicted 0

CRD GitHub地址： https://github.com/kubernetes-sigs/kubebuilder Kubernetes 里资源类型有如下所示： 上述资源类型可以满足大多数分布式系统部署的需求 但是在不同应用业务环境下，对于平台可能有一些特殊的需求，这些需求可以抽象为 Kubernetes 的扩展资源，而 Kubernetes 的 CRD (CustomResourceDefinition)为这样的需求提供了轻量级的机制，保证新的资源的快速注册和使用。 举个栗子： 我希望在 kubernetes 中有 KafkaSource 这个资源， 资源示例 kafka-source.yaml如下： 我们希望在执行 kubectl create -f kafka-source.yaml 之后，在 kubernetes 里会启动一个 pod，这个 pod 会做下面的事情： 它会从地址是 my-cluster-kafka-bootstrap.kafka:9092，topic 是 knative- demo-topic 的 kafka 机群里读取消 将读到的消息，发送到 kubernetes 的一个 Service 去执行 Kuberentes 里并没有 KafkaSource 这个资源可以使用，所以直接执行 kubectl create -f kafka-source

Tungsten Fabric入门宝典系列文章，来自技术大牛倾囊相授的实践经验，由TF中文社区为您编译呈现，旨在帮助新手深入理解TF的运行、安装、集成、调试等全流程。如果您有相关经验或疑问，欢迎与我们互动，并与社区极客们进一步交流。更多TF技术文章，请点击公号底部按钮＞学习＞文章合集。 作者：Tatsuya Naganawa 译者：TF编译组 两年来，我在Tungsten Fabric的旅程中学到了不少知识，接下来，我会用几篇文章来简要介绍一下。 1为什么要用Tungsten Fabric？ 首先，让我们来看一个重要的问题，SDN/Neutron/CNI都有很多不错的实现案例，为什么还要再尝试另一个呢？据我所知，Tungsten Fabric具有两个关键的差异化特征，这使它变得如此与众不同。 I. 与ASIC的互操作性 尽管有很多技术使Linux软件成为生产路由器/交换机的理想选择，但ASIC仍然是这一行业的重要组成部分。为了与它们进行互操作，SDN平台需要使用路由协议，例如BGP或OVSDB。 许多服务提供商和云服务商使用VRF来终结和分离每个客户的网络连接，这使得路由器和SDN之间的连接变得很复杂。 通常，它们之间可以使用VLAN，但是SDN平台上的终结点可能会成为瓶颈 此外，每个SDN终结点（类似于OpenStack中的网络节点）需要为每个客户进行单独的配置，这使配置更加复杂

国内业界大家对组件化的讨论从今年年初开始到年尾，不外乎两个方案：URL/protocol注册调度，runtime调度。 我之前批评过URL注册调度是错误的组件化实施方案，在所有的基于URL注册调度的方案中，存在两个普遍问题： 命名域渗透 因注册是不必要的，而带来同样不必要的注册列表维护成本 其它各家的基于URL注册的不同方案在这两个普遍问题上还有各种各样的其他问题，例如FRDIntent库中的FRDIntent对象其本质是鸡肋对象、原属于响应者的业务被渗透到调用者的业务中、组件化实施方案的过程中会产生对原有代码的侵入式修改等问题。 另外，我也发现还是有人在都没有理解清楚的前提下就做出了自己的解读，流毒甚广。我之前写过 关于CTMediator比较理论的描述 ，也有 Demo ，但惟独没有写实践方面的描述。我本来以为Demo就足够了，可现在看来还是要给一篇实践的文章的。 在更早之前，卓同学的swift老司机群里也有人提出因为自己并没有理解透彻CTMediator方案，所以不敢贸然直接在项目中应用。所以这篇文章的另一个目的也是希望能够让大家明白，基于CTMediator的组件化方案实施其实非常简单，而且也是有章法可循的。这篇文章可能会去讨论一些理论的东西，但主要还会是以实践为主。争取做到能够让大家看完文章之后就可以直接在自己的项目中顺利实施组件化。 最后

本文来自 Rancher Labs 昨天Kubernetes最新版本v1.18已经发布，其包含了38项功能增强，其中15项为稳定版功能、11项beta版功能以及12项alpha版功能。在本文中，我们将探索其中一些功能，希望能帮助你决定是否需要升级。那么，我们现在开始吧！ 将Service Account Token作为通用身份验证方法 Kubernetes使用service account来验证集群内的服务。例如，如果你想要一个pod来管理其他Kubernetes资源，如Deployment或者Service，你可以与Service Account相关联并创建必要的角色和角色绑定。Kubernetes Service Account（KSA）发送JSON Web Tokens（JWT）到API server以验证它们。这使API server成为service account身份验证的唯一来源。 那么，如果实体需要针对集群外的其他服务进行身份验证，该怎么办？为了使用其KSA，外部身份验证器必须联系API server以验证请求。但是，API server不应公开访问。因为这使你可以使用其他身份验证系统进行验证，这会增加复杂性。即使第三方服务位于可以访问API server的集群中，也会增加负载。 于是在Kubernetes 1.18中增加了一个功能（#1393），该功能使API