pod

【译文连载】 理解Istio服务网格（第二章 安装） https://www.cnblogs.com/sammyliu/p/12324399.html 全书目录 第一章 概述 本文目录 1.命令行工具安装 2. Kubernetes/OpenShift安装 3. Istio安装 4.示例Java微服务安装 4.1 源码概览 4.2 编译和部署customer服务 4.3 编译和部署Preference服务 4.4 编译和部署recommendation服务 本章中，我们会介绍如何在Kubernetes上安装Istio。Istio并没有和Kubernets绑定，实际上，它合适很多种基础架构平台。但是，Kubernetes因为原生支持边车部署（sidecar deployment）概念，因此它是运行Istio的最佳平台之一。你可以使用任何版本的Kubernetes。本章中，我们将使用Minishift，这是一个可以让你的OpenShift安装并运行在本地虚拟机上的工具，而OpenShift则是一个面向开发者的Kubernetes企业发行版。 1. 命令行工具安装 ​作为一个开发者，你可能已有了各种工具，但为了清晰起见，我们还是给个本书所需的工具列表： Minishift：这是minikube的红帽发行版 VirtualBox：提供虚拟机的虚拟化工具 Mac

作者 | 汤志敏、谢瑶瑶 会议完整视频回顾： https://www.bilibili.com/video/av88668762 2 月 12 日，阿里云和 CNCF 联合举办了线上研讨会，首次完整介绍了阿里云对 Kubernetes 社区的布局，包括了 10 个类别，20 多个开源项目，提供了完整的 Kubernetes 生命周期管理。本文汇集了此次会议完整视频回顾及资料下载，并整理了会议上未能及时回答的问题，希望能够对大家有所帮助~ 关注“阿里巴巴云原生”公众号，后台回复 “会议” 即可下载 PPT。 什么是 SIG Cloud Provider 随着时间的发展，越来越多的企业在生产环境使用 Kubernetes。Kubernetes 被广为接受，离不开其良好的设计和繁荣的社区。目前围绕着 Kubernetes 已经有 20 个左右的兴趣小组（SIG），SIG Cloud Provider 则是 Kubernetes 的重要兴趣小组之一，致力于推动所有云厂商以标准的能力提供 Kubernetes 服务。 SIG-Cloud-Provider-Alibaba 是 SIG Cloud Provider 在国内唯一的子项目。 Cloud Provider SIG 是 Kubernetes 的云厂商兴趣小组，致力于让 Kubernetes 的生态系统往厂商中立的方向演进

#查看节点状态 kubectl get nodes -o wide #查看pod状态 kubectl get pod --all-namespaces #查看pod详细信息 kubectl descrivbe pod -n <namespace> #查看副本数 kubectl get deployments #查看集群基本组件状态 kubectl get cs #查看服务 kubectl get services -n kube-system #从节点，不能访问server 将 主节点的/etc/kubernetes/admin.conf 拷贝到从节点上 执行 echo "export KUBECONFIG=/etc/kubernetes/admin.conf" >> ~/.bash_profile source ~/.bash_profile #若有镜像下载不下来，可以遵循以下步骤 1、查询镜像：docker search <镜像> 2、拉取镜像：docker pull <镜像> 3、tag镜像：docker tag <镜像> <镜像> #pod所在的节点挂了，pod任然在running状态，并没有转移到起到节点 https://kubernetes.io/docs/concepts/nodes/node/ #添加DNS vim /etc/resolv.conf 添加

一、凡是调度、网络、存储，以及安全相关的属性，基本上是 Pod 级别的。 1、这些属性的共同特征是，它们描述的是“机器”这个整体，而不是里面运行的“程序”。 1、比如，配置这个“机器”的网卡（即：Pod 的网络定义）， 2、配置这个“机器”的磁盘（即：Pod 的存储定义）， 3、配置这个“机器”的防火墙（即：Pod 的安全定义）。 4、更不用说，这台“机器”运行在哪个服务器之上（即：Pod 的调度）。 2、NodeSelector：是一个供用户将 Pod 与 Node 进行绑定的字段 apiVersion: v1 kind: Pod ... spec: nodeSelector: disktype: ssd 这样的一个配置，意味着这个 Pod 永远只能运行在携带了“disktype: ssd”标签（Label）的节点上；否则，它将调度失败。 3、NodeName：一旦Pod的这个字段被赋值，Kubernetes 项目就会被认为这个 Pod 已经经过了调度 调度的结果就是赋值的节点名字。所以，这个字段一般由调度器负责设置，但用户也可以设置它来“骗过”调度器， 当然这个做法一般是在测试或者调试的时候才会用到。 4、HostAliases：定义了Pod的hosts文件（比如 /etc/hosts）里的内容 apiVersion: v1 kind: Pod ... spec:

注意：此篇文章接上篇：K8s之Pod进阶（七） https://blog.csdn.net/JarryZho/article/details/104383739 原理： kubernetes通过watch的机制进行每个组件的协作，每个组件之间的设计实现了解耦 调度方式： nodeName用于将Pod调度到指定的Node名称上（跳过调度器直接分配） nodeSelector用于将Pod调度到匹配Label的Node上（前提是node要有标签） 图解： 左上角的运维人员往节点中创建一个nginx资源 （1）API Server和etcd和Scheduler是master （2）Kubelet和Docker是node节点 API Server做为唯一入口，接受create创建资源的属性信息写入到etcd中（属性信息：名称，镜像名称，限制条件），etcd完善发现机制（watch）给Scheduler调度器（查看那个节点适合），然后绑定相关pod的网络信息，反馈给API Server，收到信息后api写入etcd中，此时etcd存储了pod的网络信息（IP），node1、中的kubelet会管理pod资源，会触发容器的创建命令，安装完成后docker就会反馈状态信息给API Server，当API Server收到状态信息写入到etcd中 总结： apiserver相当于是平台中的书记

一、什么才是 Kubernetes 项目能“认识”的方式呢？ 1、这就是使用 Kubernetes 的必备技能：编写配置文件。 备注：这些配置文件可以是 YAML 或者 JSON 格式的。为方便阅读与理解，在后面的讲解中，我会统一使用 YAML 文件来指代它们。 Kubernetes 跟 Docker 等很多项目最大的不同，就在于它不推荐你使用命令行的方式直接运行容器（虽然 Kubernetes 项目也支持这种方式，比如：kubectl run），而是希望你用 YAML 文件的方式，即：把容器的定义、参数、配置，统统记录在一个 YAML 文件中，然后用这样一句指令把它运行起来： kubectl create -f 我的配置文件 这么做最直接的好处是，你会有一个文件能记录下 Kubernetes 到底“run”了什么 像这样的一个 YAML 文件，对应到 Kubernetes 中，就是一个 API Object（API 对象）。当你为这个对象的各个字段填好值并提交给 Kubernetes 之后，Kubernetes 就会负责创建出这些对象所定义的容器或者其他类型的 API 资源。 2、Deployment apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment spec: selector:

** ConfigMap,Secret ** secret ** 用来保存一些敏感信息，数据是比较少量的。比如数据库的用户名密码或者密钥 一条命令只能保存一条信息 创建secret的四种方式 例举：保存数据库的用户名和密码 用户名是root 密码是123.com 1.通过–from-literal：文字的方式 [root@master secret]# kubectl create secret generic（通用的，一般的） mysecret1 --from-literal=username=root --from-literal=password=123.com 2.通过–from-file：文件的方式 [root@master secret]# echo root > username [root@master secret]# echo 123.com > password [root@master secret]# kubectl create secret generic mysecret2 --from-file=username --from-file=password 3.通过–from-env-file： [root@master secret]# vim env.txt username=root password=123.com [root@master

ConfigMap、Secret 为什么有这两个东西： 我们在kubernetes上部署应用的时候，经常会需要传一些配置给我们的应用，比如数据库地址啊，用户名密码啊之类的。我们要做到这个，有好多种方案，比如： 我们可以直接在打包镜像的时候写在应用配置文件里面，但是这种方式的坏处显而易见而且非常明显。 我们可以在配置文件里面通过env环境变量传入，但是这样的话我们要修改env就必须去修改yaml文件，而且需要重启所有的container才行。 我们可以在应用启动的时候去数据库或者某个特定的地方拿，没问题！但是第一，实现起来麻烦；第二，如果配置的地方变了怎么办？ 当然还有别的方案，但是各种方案都有各自的问题。 而且，还有一个问题就是，如果说我的一个配置，是要多个应用一起使用的，以上除了第三种方案，都没办法进行配置的共享，就是说我如果要改配置的话，那得一个一个手动改。假如我们有100个应用，就得改100份配置，以此类推…… kubernetes对这个问题提供了一个很好的解决方案，就是用 ConfigMap 和 Secret 应用场景： 镜像往往是一个应用的基础，还有很多需要自定义的参数或配置，例如资源的消耗、日志的位置级别等等，这些配置可能会有很多，因此不能放入镜像中，Kubernetes中提供了Configmap来实现向容器中提供配置文件或环境变量来实现不同配置

今天清理下电脑,发现自己电脑上的cocoapods经常出现的一个问题就是一些经常用的第三方库cocoapods搜不到,比如SDWebImage,然后就鼓捣了一下 $pos list 命令发现M 以后的库查询不到了,发现 $ pod search 和 $ pod list 查找的都是本地的第三方类库，并不是服务器的类库, 于是原因肯定就出在本地和远程不同步的问题。 最后在网上找了写资料也有解决的办法 使用 pod repo update master 命令同步远程服务器的第三方类库， 发现有可能是网络问题，有可能是远程服务器就是github，然后类库列表不全。 然后想到了另外的办法，有大神在gitcafe和oschina上建立了CocoaPods索 引库的镜像。因为gitcafe和oschina都是国内的服务器，所以在执行索引更 新操作时，会快很多。 //下面的切换命令本人没有切换成功 一直报这个错误 [!] To setup the master specs repo, please run `pod setup`. $pod repo remove master ​ $ pod repo add master https://gitcafe.com/akuandev/Specs.git (2016.5.31日网站已关闭) $​pod repo update ​ 或者可用http:

我们为什么需要pod？ 1. 解决具有超亲密关系容器之间的成组调度问题 ：比如在存在A、B、C三个容器，这三个容器之间基于socket和文件交换进行通信，在docker swarm中，可以在这三个容器之间设置affinity约束来要求这三个容器必须调度 到同一个节点，但是往往就存在容器A和B调度在某个节点，而这个节点剩余的资源却又不足与调度容器C的情况。Mesos中有一个资源囤积（resource hoarding）的机制，会在所有设置了 Affinity 约束的任务都达到时，才开始对它们统一进行调度，但是调度效率 难免降低。在 Google Omega 论文中，则提出了使用乐观调度处理冲突的方法，即：先不管这些冲突，而是通过精心设计的回滚机制在出现了冲突之后解决问题，而这种复杂的机制却难于掌握。pod作为Kubernetes里的原子调度单位，统一按照Pod而非容器的资源需求计算来执行调度。 2. 支持容器设计模式 ：pod作为一个逻辑概念，通过一个中间容器pause，让业务容器通过join namespace的方式加入到pause中的namespace。比如多个业务容器之间由于都加入到了Network Namespace中，所以他们可以使用localhost进行通信，如果需要为kubernetes 开发一个网络插件，也只需要关心如何配置pause容器的Network