pod

kubernetes 核心组件 etcd ：保存整个集群的状态 apiserver ：提供资源操作的唯一入口，并提供认证、授权、访问控制、api注册和发现等机制 controller manager ：负责维护集群的状态，比如故障检测、自动扩展、滚动更新等 scheduler ：负责资源调度，按照预定的调度策略将pod调度到相应的机器上 kubelet ：负责维护容器的生命周期，同时也负责volume(CVI)和网络(CNI)的管理 CNI：容器网络接口标准 Container runtime ：负责镜像管理以及pod和容器的真正运行（CRI） kube-proxy ：负责为service提供cluster内部的服务发现和负责均衡 kubernetes 核心对象 Cluster :计算、存储、网络资源的集合，kubernetes利用这些资源运行各种基于容器的应用。 Master ：是Cluster的大脑，她主要职责是调度，即决定将应用放在那里运行，可以运行多个Master Node ：职责是运行容器应用，Node由Master管理，Node负责监控并汇报容器的状态，bin根据Master的要求管理容器的生命周期 Pod ：是kubernetes的最小工作单元，每个Pod包含一个或多个容器，Pod中的容器被作为一个整体被Master调度到一个Node上运行。目的：可管理性

目录 kubernetes网络通信 需要解决的问题 flannel Calico/Cannel kubernetes网络通信 需要解决的问题 同一个pod内部的不同容器间通信, local Pod间的通信 pod与Service的通信: PodIP<--->ClusterIP Service 与集群外部通信 CNI： 常见的解决方案 flannel calico canel kube-router 解决方案： 虚拟网桥：brige方案 多路复用：MacVLAN（二层方案） 硬件交换：SR-IOV flannel 查看集群的flannel 配置文件 将配置文件放到/etc/cni/net.d目录下， kubelet 会加载该文件。 cat /etc/cni/net.d/10-flannel.conflist flannel不支持网络策略 不同namespace 的pod 可以相互通信 支持多种方式后端 Vxlan 工作原理 vxlan Directrouting # 同网段使用host-gw 不同网段使用vxlan host-gw： Host Gateway 工作原理 UDP： 效率很低 flannel 的配置参数： network 使用CIRD格式的网络地址： 10.244.0.0/16 -> master: 10.244.0.0/24 ​ node1: 10.244.1.0/24

容器 在了解 Kubernetes 之前，让我们先了解一个容器。 因为如果不了解容器就没法聊容器编排。 容器就是...一个你塞入所有 材料 的容器。 “材料”是指你的应用代码、依赖库，以及直到内核的依赖关系。 关键概念是 隔离 ，把你的这些材料隔离出来，以便更好的控制他们。 容器提供了3种类型的隔离： 工作空间隔离（进程、网络） 资源隔离（CPU、内存） 文件系统隔离 容器可以理解为节食的VM，具有隔离性，但容器非常精简、体积小、启动快。 VM是在操作系统之上又安装了多个操作系统，VM之间自然是隔离的。 而容器是通过 Linux 的 cgroup 实现了VM那样的隔离性，并不需要安装操作系统。 什么时候使用Kubernetes？ 容器挺好的，为什么需要 Kubernetes 这样的容器协调器呢？ 如果你达到图中这个状态时，你就需要他了，有太多的容器需要管理了。 Q：我前端容器在哪儿呢？有多少个在运行？ A：很难说啊，快使用容器编排吧。 Q：如何让我的前端容器与新创建的后端容器沟通？ A：可以硬编码 IP，或者，使用容器编排。 Q：如何滚动升级？ A：你可以手动控制每一步，或者，使用容器编排。 Kubernetes 体系结构 每个Kubernetes集群都有两种类型的节点：master 和 worker。 master 是控制和监控 worker 工作的这个集群的。 master

作者 | 匡大虎 阿里巴巴技术专家 本文整理自《CNCF x Alibaba 云原生技术公开课》第 27 讲， 点击直达课程页面 。 关注“阿里巴巴云原生”公众号，回复关键词 “入门” ，即可下载从零入门 K8s 系列文章 PPT。 导读： 访问控制是云原生安全的一个重要组成部分，也是 K8s 集群在多租环境下必要且基本的安全加固手段。在 K8s 体系中，访问控制又分为三个重要的组成部分，请求认证，鉴权和运行时刻的 admission 准入控制。在本文中，作者将带领大家了解这 3 部分的基本定义和使用方法，并给出多租环境下安全加固的相关最佳实践。 一、Kubernetes API 请求访问控制 访问控制 大家都知道访问控制是云原生安全中的一个重要组成部分。也是一个 Kubernetes 集群在多租户环境下必须要采取的一个基本的安全防护手段。 那么在概念上可以抽象的定义为谁在何种条件下可以对什么资源做什么操作。这里的资源就是在 Kubernetes 中我们熟知的：Pod、 ConfigMaps、Deployment、Secrets 等等这样的资源模型。 Kubernetes API 请求 由上图来介绍一下 Kubernetes API 的请求从发起到其持久化入库的一个流程。 首先看一下请求的发起，请求的发起分为两个部分： 第一个部分是人机交互的过程。 是大家非常熟悉的用

作者 | 匡大虎 阿里巴巴技术专家 本文整理自《CNCF x Alibaba 云原生技术公开课》第 27 讲， 点击直达课程页面 。 关注“阿里巴巴云原生”公众号，回复关键词 “入门” ，即可下载从零入门 K8s 系列文章 PPT。 导读： 访问控制是云原生安全的一个重要组成部分，也是 K8s 集群在多租环境下必要且基本的安全加固手段。在 K8s 体系中，访问控制又分为三个重要的组成部分，请求认证，鉴权和运行时刻的 admission 准入控制。在本文中，作者将带领大家了解这 3 部分的基本定义和使用方法，并给出多租环境下安全加固的相关最佳实践。 一、Kubernetes API 请求访问控制 访问控制 大家都知道访问控制是云原生安全中的一个重要组成部分。也是一个 Kubernetes 集群在多租户环境下必须要采取的一个基本的安全防护手段。 那么在概念上可以抽象的定义为谁在何种条件下可以对什么资源做什么操作。这里的资源就是在 Kubernetes 中我们熟知的：Pod、 ConfigMaps、Deployment、Secrets 等等这样的资源模型。 Kubernetes API 请求 由上图来介绍一下 Kubernetes API 的请求从发起到其持久化入库的一个流程。 首先看一下请求的发起，请求的发起分为两个部分： 第一个部分是人机交互的过程。 是大家非常熟悉的用

一、概要 iOS开发时，项目中会引用许多第三方库，CocoaPods（https://github.com/CocoaPods/CocoaPods） 可以用来方便的统一管理这些第三方库。 二、安装 由于网上的教程基本都大同小异，但细节之处还不是很完善，所以借机会在这里补充下： 注：要使用CocoaPods，那就要下载安装它，而下载安装CocoaPods需要Ruby环境 1、Ruby环境搭建 Mac OS本身自带Ruby，但还是更新一下保险. a查看下当前ruby版本：打开终端输入 ruby -v（确实安装了，不过用这个版本接下来工作失败了，所以更新下ruby） // ruby -v 终端显示结果 ruby 2.0.0p645 (2015-04-13 revision 50299) [universal.x86_64-darwin15] b更新ruby 终端输入如下命令（把Ruby镜像指向taobao，避免被墙，你懂得） gem sources --remove https://rubygems.org/ gem sources -a https://ruby.taobao.org/ gem sources -l （用来检查使用替换镜像位置成功） 2、下载安装CocoaPods 终端输入：sudo gem install cocoapods 最终出现: 8 gem installed

本文来自 Rancher Labs 什么是Pod安全策略？ Kubernetes Pod安全策略（PSP）是Kubernetes安全版块中极为重要的组件。Pod安全策略是集群级别的资源，用于控制Pod安全相关选项，并且还是一种强化Kubernetes工作负载安全性的机制。Kubernetes平台团队或集群运维人员可以利用它来控制pod的创建以及限制特定的用户、组或应用程序可以使用的功能。 举个简单的例子，使用PSP你可以： 防止特权Pod启动并控制特权升级。 限制Pod可以访问的主机命名空间、网络和文件系统 限制可以运行pod的用户/组。 限制Pod可以访问的Volume 限制其他参数，如运行时配置文件或只读根文件系统 在本文中，我们将向你展示在Rancher中如何通过启用一个简单的Pod安全策略来强化你的Kubernetes安全。 Pod安全策略真的可以增强K8S的安全性吗？ 是的，Pod安全策略确实可以增强Kubernetes的安全性。它提供了Kubernetes原生控制机制，可以防止威胁而不影响性能，这与agent必须拦截主机上的每个动作有所区别。 如果你尚未在集群中启用PSP（或执行访问控制之类的等效方法），则Kubernetes用户可能会生成特权集群。这将会被恶意利用，例如提升特权进而突破容器隔离并访问其他Pod/服务。 如果没有限制Pod spec特权的机制，**

简介 Rook官网： https://rook.io Rook是 云原生计算基金会 (CNCF)的孵化级项目. Rook是Kubernetes的开源 云本地存储协调 器，为各种存储解决方案提供平台，框架和支持，以便与云原生环境本地集成。 至于CEPH，官网在这： https://ceph.com/ ceph官方提供的helm部署，至今我没成功过，所以转向使用rook提供的方案 有道笔记原文： http://note.youdao.com/noteshare?id=281719f1f0374f787effc90067e0d5ad&sub=0B59EA339D4A4769B55F008D72C1A4C0 环境 centos 7.5 kernel 4.18.7-1.el7.elrepo.x86_64 docker 18.06 kubernetes v1.12.2 kubeadm部署： 网络: canal DNS: coredns 集群成员： 192.168.1.1 kube-master 192.168.1.2 kube-node1 192.168.1.3 kube-node2 192.168.1.4 kube-node3 192.168.1.5 kube-node4 所有node节点准备一块200G的磁盘：/dev/sdb 准备工作 所有节点开启ip_forward cat <<EOF

1 标签 1.1 为什么要有标签？   在微服务架构中，部署的微服务数量很容器达到几十个，这些组件可能是副本（部署同一组件的多个副本）和多个不同的发布版本（stable、beta、canary等）同时运行。导致K8S系统中会出现多个pod，如果没有机制去组织这些组件，极容易产生混乱。需要一种能够基于任意标准将上述pod组织成更小群体的方式，这个时候就产生了 标签 ，标签可以组织pod和其他K8S对象。 1.2 标签介绍   标签是一种简单却功能强大的K8S特性，可以附加到K8S资源的任意键值对，可以通过 标签选择器 筛选出需要寻找的确切标签的资源。在资源内标签的key需唯一，一个资源可拥有多个标签。   K8S中的任意API对象都是通过Label进行标识、实质是一系列key/value键值对，其中key与value由用户自己指定。 金丝雀发布：在部署新版本时，先只让一小部分用户体验新版本以观察新版本的表现，然后再向所有用户进行推广，这样可防止暴露有问题的版本给过多的用户。 1.3 标签命令 列出pods的标签 $ kubectl get po --show-labels 查看具体标签 $ kubectl get po -L label_key1, label_key2 添加标签 $ kubectl label po po_name label_key=label_value 其中，

修改了 Deployment 后，旧的 Pod 被 Terminated，新的 Pod 被启动。 然后问题就出现了，旧 Pod 一直处于 Exited: Terminated 状态，无法删除。 因为我们使用了 hostPort，端口一直被这个旧 Pod 占用，新 Pod 就无法启动，一直 Pending. 解决方法 手动登录到对应的节点，通过 docker ps -a | grep 查找到已经 Exited 的容器，然后 docker rm -f <container-id> 手动删除掉它。 现在再进 kubernetes，发现旧 Pod 已经消失了。 来源： https://www.cnblogs.com/kirito-c/p/12508577.html