Use local images instead of weibotuchuang
Jimmy Song
11
README.md
|
|
@ -69,20 +69,22 @@
|
|||
- **与我联系**：扫描下面的二维码关注Jimmy Song 的<u>个人微信公众号</u>CloudNativeGo（云原生应用架构）
|
||||
|
||||
<p align="center">
|
||||
<img src="https://github.com/rootsongjc/kubernetes-handbook/blob/master/images/cloud-native-go-wechat-qr-code.jpg?raw=true" alt="云原生应用架构微信公众号二维码"/>
|
||||
<img src="images/cloud-native-go-wechat-qr-code.jpg" alt="云原生应用架构微信公众号二维码"/>
|
||||
</p>
|
||||
|
||||
|
||||
- **ServiceMesher**：ServiceMesher 社区公众号，下承 Kubernetes、上接 Serverless，云原生应用的通信层，旨在加强行业内部交流，促进开源文化构建，推动 Kubernetes、Service Mesh、Serverless 等云原生技术在企业落地，发布活动及业界最前沿资讯。[加入组织](http://www.servicemesher.com/contact/)。
|
||||
|
||||
<p align="center">
|
||||
<img src="https://ws1.sinaimg.cn/large/00704eQkgy1fshv989hhqj309k09k0t6.jpg" alt="ServiceMesher微信公众号二维码"/>
|
||||
<img src="images/servicemesher-wechat-public.jpg" alt="ServiceMesher微信公众号二维码"/>
|
||||
</p>
|
||||
|
||||
|
||||
## 读者反馈
|
||||
|
||||
以下是部分读者反馈，希望更多人[加入我们](http://www.servicemesher.com)，共同打造中国质量最高的云原生社区！
|
||||
|
||||
|
||||
|
||||
|
||||
## 云原生出版物
|
||||
|
||||
|
|
@ -98,6 +100,7 @@
|
|||
为云原生干杯🍻！使用微信扫一扫请我喝一杯☕️
|
||||
|
||||
<p align="center">
|
||||
<img src="https://github.com/rootsongjc/kubernetes-handbook/blob/master/images/wechat-appreciate-qrcode.jpg?raw=true" alt="微信赞赏码"/>
|
||||
<img src="images/wechat-appreciate-qrcode.jpg" alt="微信赞赏码"/>
|
||||
</p>
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -130,7 +130,7 @@ CNCF 年度报告的原文主要是汇报了 CNCF 一年来的所展开的活动
|
|||
|
||||
自2015年底 CNCF 创立之初 Kubernetes 成为其首个托管项目以来，截止到2018年底，CNCF 已经托管了[32个开源项目](https://www.cncf.io/projects/)，随着越来越多的项目加入到 CNCF，为了更好的管理这些项目，为这些项目划分不同的成熟度等级就成了迫在眉睫的事情。
|
||||
|
||||
|
||||
|
||||
|
||||
根据《Crossing the Chasm》一书中的技术采用生命周期理论，CNCF 将其托管的项目划分为三个等级：
|
||||
|
||||
|
|
@ -146,7 +146,7 @@ CNCF 通过为项目设置成熟度水平是来建议企业应该采用哪些项
|
|||
|
||||
通过 [KCSP](https://www.cncf.io/certification/kcsp/) 意味着企业具有为其他企业或组织提供 Kubernetes 支持、咨询、专业服务和培训的资质。 2018年又有46家企业通过了[KCSP](https://www.cncf.io/certification/kcsp/)，通过该认证的企业累计达到76家。
|
||||
|
||||
|
||||
|
||||
|
||||
**如何通过 KCSP**
|
||||
|
||||
|
|
|
|||
|
|
@ -5,9 +5,9 @@
|
|||
- 对于管理 Windows node 的生产级支持。
|
||||
- 重写了 kubectl 的文档，并为其专门启用新域名 <https://kubectl.docs.kubernetes.io/>，该文档本身类似 Gitbook 的形式，使用 Resource Config 的形式组织，集成了 [kustomize](https://github.com/kubernetes-sigs/kustomize)，还有了自己的 logo 和吉祥物 kubee-cuddle。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
- kubectl 插件机制发布稳定版本。
|
||||
- Persistent Local Volume GA。
|
||||
|
|
|
|||
|
|
@ -46,13 +46,13 @@
|
|||
|
||||
下图是 Google trend 中过去一年来全球搜索 Kubernetes 的趋势图。
|
||||
|
||||
|
||||
|
||||
|
||||
从图中可以看出 Kubernetes 在全球搜索趋势在2018年底已经达到了最巅峰，2019年可能会开始走下降趋势。
|
||||
|
||||
下图是最近5年来 Kubernetes 关键词的百度指数。
|
||||
|
||||
|
||||
|
||||
|
||||
上图来自百度指数，可以大体概括 Kubernetes 关键字在中国的搜索情况，同 Kubernetes 在全球的搜索情况一样，可能已经过了巅峰期。
|
||||
|
||||
|
|
@ -60,7 +60,7 @@
|
|||
|
||||
以 Kubernetes 为核心来运维上层应用，诞生了一种名为”Kubernetes Native“的新型运维方式，真正践行 DevOps 理念的产物，开发者将于软件的运维逻辑写成代码，利用 Kubernetes 的**控制器模式（Controller Pattern）**和 [CRD](../concepts/crd.md) 来扩展 Kubernetes 的 API，各种 Operator 层出不穷，[awesome-operators](https://github.com/operator-framework/awesome-operators) 列举了目前所有的 Operator。例如我们熟悉的 [Istio](https://istio.io) 中就有50个 CRD。
|
||||
|
||||
|
||||
|
||||
|
||||
CNCF 生态中的诸多应用都已支持 Kubernetes Operator，可以说 Operator 将成为云原生中默认的软件动态运行时管理工具，参考 CoreOS（已被 RedHat 收购，RedHat 已被 IBM 收购） CTO Brandon Philips 的这篇文章 [Introducing the Operator Framework: Building Apps on Kubernetes](https://www.redhat.com/en/blog/introducing-operator-framework-building-apps-kubernetes)。
|
||||
|
||||
|
|
@ -68,15 +68,15 @@ CNCF 生态中的诸多应用都已支持 Kubernetes Operator，可以说 Operat
|
|||
|
||||
下图展示的是 2019 Q1 的软件架构趋势，（图片来自 [Architecture and Design InfoQ Trends Report - January 2019](https://www.infoq.com/articles/architecture-trends-2019)）我们可以看到 Service Mesh 还处于创新者阶段，如果从软件生命周期的全阶段来看，它还只是刚刚进入很多人的眼帘，对于这张的新兴技术，在蚂蚁金服的支持的下创办了 [ServiceMesher 社区](http://www.servicemesher.com)。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
既然 Kubernetes 已经开始变得无聊，2018年落地 Kubernetes 已经不是初创公司的事情了，很多大公司甚至传统企业都开始试水或者大规模落地，在 Kubernetes 进一步成熟之时，以 Kubernetes 为基础向上发展，开辟新的战场就能收获更多的业务场景和需求。
|
||||
|
||||
Kubernetes 并不直接对外提供业务能力，而是作为应用运行的底层平台，在应用和平台间还有一个 Gap，这需要中间件的能力来补充。
|
||||
|
||||
|
||||
|
||||
|
||||
- 2018年5月，ServiceMesher 社区由蚂蚁金服发起成立。
|
||||
- 2018年5月30日，[Envoy最新官方文档中文版发布——由Service Mesh爱好者倾情奉献](http://www.servicemesher.com/envoy/)。
|
||||
|
|
@ -121,7 +121,7 @@ Kubernetes 并不直接对外提供业务能力，而是作为应用运行的底
|
|||
|
||||
我们再看 CNCF 的 [Landscape](https://landscape.cncf.io/)，其中右下部分有一个单列的 Serverless 单元，详见 <https://landscape.cncf.io/>。
|
||||
|
||||
|
||||
|
||||
|
||||
我们再看下 Kubernetes、Service Mesh、Serviceless 三者之间的关系：
|
||||
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ Kubernetes 社区的贡献、交流和治理方式相关的内容都保存在 <h
|
|||
- 社区成员的角色分类与职责
|
||||
- 社区贡献的 Kubernetes 资源图标
|
||||
|
||||
|
||||
|
||||
|
||||
## 生态环境
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@
|
|||
|
||||
下文部分来自Joe Duffy的博客[Hello, Pulumi](http://joeduffyblog.com/2018/06/18/hello-pulumi/)！
|
||||
|
||||
|
||||
|
||||
|
||||
TL;DR 有了Pulumi，38页的手动操作说明将变成了38行代码。25000行YAML配置变成了使用真实编程语言的500行语句。
|
||||
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ CNCF（云原生计算基金会）是Linux基金会旗下的一个基金会，
|
|||
|
||||
下图是我根据CNCF章程绘制的组织架构图。
|
||||
|
||||
|
||||
|
||||
|
||||
## 1. CNCF的使命
|
||||
|
||||
|
|
@ -345,7 +345,7 @@ CNCF社区坚信云原生计算包含三个核心属性：
|
|||
- 在标准化子系统的边界处定义良好的API
|
||||
- 应用程序生命周期管理的最小障碍
|
||||
|
||||
|
||||
|
||||
|
||||
因为上述时间表已经有些过时了，CNCF成立已经有三年时间了，正在规划新的方案。
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ CNCF 根据“[鸿沟理论](https://www.jianshu.com/p/a305fa93580b)”将其托
|
|||
|
||||
> “[鸿沟理论](https://www.jianshu.com/p/a305fa93580b)”是由Geoffrey A. Moore提出的高科技产品的市场营销理论。新技术要想跨越鸿沟，必须能够实现一些跨越式的发展，**拥有某一些以前不可能实现的功能**，具有某种内在价值并能够**赢得非技术人员的**青睐。
|
||||
|
||||
|
||||
|
||||
|
||||
目前处于沙箱、孵化中、已毕业项目的数量比例为5：16：13，详见 <https://cncf.io/projects>。其中沙箱（sandbox）项目因为其处于早期阶段并没有直接在上面的链接页面中列出，而是一个单独的 [Sandbox](https://www.cncf.io/sandbox-projects/) 页面，因为 CNCF 为 sandbox 阶段的项目会谨慎背书。
|
||||
|
||||
|
|
@ -20,7 +20,7 @@ CNCF 中托管的开源项目要符合云原生定义：
|
|||
|
||||
下图演示了开源项目加入 CNCF 后的整个运作流程。
|
||||
|
||||
|
||||
|
||||
|
||||
## 开源项目如何加入 CNCF
|
||||
|
||||
|
|
@ -99,3 +99,4 @@ CNCF 的开源项目遵循如下图所示的成熟度演进。
|
|||
|
||||
- [鸿沟理论 - jianshu.com](https://www.jianshu.com/p/a305fa93580b)
|
||||
- [CNCF Graduation Criteria v1.2 - github.com](https://github.com/cncf/toc/blob/master/process/graduation_criteria.adoc)
|
||||
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ CNCF作为一个厂商中立的基金会，致力于Github上的快速成长的
|
|||
|
||||
下图是CNCF的全景图。
|
||||
|
||||
|
||||
|
||||
|
||||
该全景图不断更新中，原图请见：https://github.com/cncf/landscape
|
||||
|
||||
|
|
|
|||
|
|
@ -44,11 +44,11 @@
|
|||
|
||||
但就2017年为止，Kubernetes的主要使用场景也主要作为应用开发测试环境、CI/CD和运行Web应用这几个领域，如下图[TheNewStack](http://thenewstack.io)的Kubernetes生态状况调查报告所示。
|
||||
|
||||
|
||||
|
||||
|
||||
另外基于Kubernetes的构建PaaS平台和Serverless也处于爆发的准备的阶段，如下图中Gartner的报告中所示：
|
||||
|
||||
|
||||
|
||||
|
||||
当前各大公有云如Google GKE、微软Azure ACS、亚马逊EKS（2018年上线）、VMWare、Pivotal、腾讯云、阿里云等都提供了Kubernetes服务。
|
||||
|
||||
|
|
@ -84,7 +84,7 @@ CNCF（云原生计算基金会）给出了云原生应用的三大特征：
|
|||
|
||||
[CNCF](https://cncf.io)所托管的应用（目前已达12个），即朝着这个目标发展，其公布的[Cloud Native Landscape](https://github.com/cncf/landscape)，给出了云原生生态的参考体系。
|
||||
|
||||
|
||||
|
||||
|
||||
**使用Kubernetes构建云原生应用**
|
||||
|
||||
|
|
@ -181,7 +181,7 @@ Linker的部署十分简单，本身就是一个镜像，使用Kubernetes的[Dae
|
|||
|
||||
给开发者带来最大的配置和上线的灵活性，践行DevOps流程，改善研发效率，下图这样的情况将更少发生。
|
||||
|
||||
|
||||
|
||||
|
||||
我们知道Kubernetes中的所有应用的部署都是基于YAML文件的，这实际上就是一种**Infrastructure as code**，完全可以通过Git来管控基础设施和部署环境的变更。
|
||||
|
||||
|
|
@ -246,7 +246,7 @@ Spark现在已经非官方支持了基于Kubernetes的原生调度，其具有
|
|||
|
||||
下图是我们刚调研准备使用Kubernetes时候的调研方案选择。
|
||||
|
||||
|
||||
|
||||
|
||||
对于一个初次接触Kubernetes的人来说，看到这样一个庞大的架构选型时会望而生畏，但是Kubernetes的开源社区帮助了我们很多。
|
||||
|
||||
|
|
|
|||
|
|
@ -15,13 +15,13 @@
|
|||
|
||||
一句话解释什么是云原生应用：云原生应用就是为了在云上运行而开发的应用
|
||||
|
||||
|
||||
|
||||
|
||||
要运行这样的应用必须有一个操作系统，就像我们运行PC或手机应用一样，而Kubernetes就是一个这样的操作系统。
|
||||
|
||||
我们再来看下操作系统宝库哪些层次。
|
||||
|
||||
|
||||
|
||||
|
||||
- 硬件管理：可以管理CPU、内存、网络和存储
|
||||
- 设备接口、虚拟化工具、实用工具
|
||||
|
|
@ -30,7 +30,7 @@
|
|||
|
||||
下面是CNCF给出的云原生景观图。
|
||||
|
||||
|
||||
|
||||
|
||||
该图中包括云原生的各种层次的提供者和应用，通过该图可以组合出一些列的云原生平台。
|
||||
|
||||
|
|
@ -52,7 +52,7 @@ Kubernetes发展已经有3年多的时间了，它已经基本成为了容器编
|
|||
|
||||
这是KubeVirt的架构图。
|
||||
|
||||
|
||||
|
||||
|
||||
我们看到图中有两个是Kubernetes原生的组件，API server和kubelet，我们创建了virt-controller就是为了创建CRD的controller，它扩展了kube-controller的功能，用于管理虚拟机的生命周期，同时在每个节点上都用DaemonSet的方式运行一个virt-handler，这个handler是用于创建虚拟机的处理器，每个节点上即可用运行虚拟机也可以运行容器，只要这个节点上有virt-handler就可以运行和调度虚拟机。
|
||||
|
||||
|
|
@ -64,7 +64,7 @@ Kubernetes的资源隔离也能保证对集群资源的最大化和最优利用
|
|||
|
||||
下图中展示了Kubernetes中的资源隔离层次。
|
||||
|
||||
|
||||
|
||||
|
||||
- 容器
|
||||
- Pod：命名空间的隔离，共享网络，每个Pod都有独立IP，使用Service Account为Pod赋予账户
|
||||
|
|
@ -80,13 +80,13 @@ Kubernetes中的基本资源类型分成了三类：
|
|||
|
||||
在最近一届的KubeCon & CloudNativeCon上Operator已经变得越来越流行。下面是OpenEBS的一个使用Operator的例子。
|
||||
|
||||
|
||||
|
||||
|
||||
OpenEBS是一款容器化存储，它基于Ceph构建，容器化存储最大的好处就是复用Kubernetes的资源类型，简化存储应用的部署，将单体的存储拆分为“微服务化”的存储，即每个应用在声明PV的时候才会创建存储，并与PV的生命周期一样都是独立于应用的。
|
||||
|
||||
OpenEBS的存储也是分控制平面和数据平面的，下图是OpenEBS的架构图。
|
||||
|
||||
|
||||
|
||||
|
||||
黄色部分是OpenEBS的组件（除了kube-dashboard），它是使用Kubernetes的各种原语和CRD来创建的，架构跟Kubernetes本身也很类似。
|
||||
|
||||
|
|
@ -94,13 +94,13 @@ OpenEBS的存储也是分控制平面和数据平面的，下图是OpenEBS的架
|
|||
|
||||
上面说到了Operator的一个应用，下面再来看一个我们之前在Kubernetes中部署Hadoop YARN和Spark的例子。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Kubernetes始于12因素应用的PaaS平台，它是微服务的绝佳部署管理平台，基于它可以应用多种设计模式。它的未来将变成什么样呢？
|
||||
|
||||
|
||||
|
||||
|
||||
- Service Mesh：解决微服务治理问题
|
||||
- Auto Pilot：自动驾驭能力，服务自动扩展，智能运维
|
||||
|
|
@ -114,7 +114,7 @@ Kubernetes始于12因素应用的PaaS平台，它是微服务的绝佳部署管
|
|||
|
||||
甚至出现了像ballerina这样的云原生编程语言，它的出现就是为了解决应用开发到服务集成之间的鸿沟的。它有以下几个特点。
|
||||
|
||||
|
||||
|
||||
|
||||
- 使用云原生语义的DSL
|
||||
- 注解式配置
|
||||
|
|
@ -123,13 +123,13 @@ Kubernetes始于12因素应用的PaaS平台，它是微服务的绝佳部署管
|
|||
|
||||
要完成云的集成CI/CD，或者用一个词代替来说就是GitOps的需求越来越强烈。
|
||||
|
||||
|
||||
|
||||
|
||||
### Kubernetes没有做什么
|
||||
|
||||
看下这张图中的两个服务，它们使用的是kube-proxy里基于iptables的原生的负载均衡，并且服务间的流量也没有任何控制。
|
||||
|
||||
|
||||
|
||||
|
||||
Kubernetes缺少的最重要的一个功能就是微服务的治理，微服务比起单体服务来说使得部署和运维起来更加复杂，对于微服务的可观测性也有更高的要求，同时CI/CD流程Kubernetes本身也没有提供。
|
||||
|
||||
|
|
@ -141,7 +141,7 @@ Service Mesh是一个专用的基础设施层，它能够将微服务的治理
|
|||
|
||||
这是Istio Service Mesh的架构图。
|
||||
|
||||
|
||||
|
||||
|
||||
- Pilot：提供用户接口，用户可以通过该接口配置各种路由规则，Pilot还可以通过适配器获取平台上各种服务之间的管理，Evnoy这个使用Sidecar方式部署到每个应用pod中的进程会通过Pilot中的Envoy API获得平台上各个服务之间的管理，同时也会应用用户配置的路由规则。
|
||||
- Mixer：获取各种平台属性，服务间通讯时会先访问Mixer兼容各平台的属性信息，如quota、访问控制和策略评估，将服务间的访问信息记录后上报到mixer形成遥测报告。
|
||||
|
|
@ -149,7 +149,7 @@ Service Mesh是一个专用的基础设施层，它能够将微服务的治理
|
|||
|
||||
Service Mesh实际上为了解决社会分工问题，它本身是为了解决微服务的治理。
|
||||
|
||||
|
||||
|
||||
|
||||
Pilot和控制平面是为了运维人员准备的。
|
||||
|
||||
|
|
@ -157,7 +157,7 @@ Pilot和控制平面是为了运维人员准备的。
|
|||
|
||||
Isito在每个上下游服务之间部署一个Envoy，Envoy中有几个基本的服务发现服务，监听器即Envoy要转发的流量端口，Endpoint是要转发的目的地，Cluster是一系列Endpoint用来做负载均衡，Route是定义各种路由规则，每个Envoy进程里可以设置多个Listener。
|
||||
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
[Calico](https://www.projectcalico.org/) 原意为”有斑点的“，如果说一只猫为 calico cat 的话，就是说这是只花猫，也叫三色猫，所以 calico 的 logo 是只三色猫。
|
||||
|
||||
|
||||
|
||||
|
||||
## 概念
|
||||
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ KV 存储数据库用存储以下状态：
|
|||
|
||||
下图是 Cilium 的组件示意图，Cilium 是位于 Linux kernel 与容器编排系统的中间层。向上可以为容器配置网络，向下可以向 Linux 内核生成 BPF 程序来控制容器的安全性和转发行为。
|
||||
|
||||
|
||||
|
||||
|
||||
管理员通过 Cilium CLI 配置策略信息，这些策略信息将存储在 KV 数据库里，Cilium 使用插件（如 CNI）与容器编排调度系统交互，来实现容器间的联网和容器分配 IP 地址分配，同时 Cilium 还可以获得容器的各种元数据和流量信息，提供监控 API。
|
||||
|
||||
|
|
@ -109,7 +109,7 @@ Available Commands:
|
|||
|
||||
将该配置保存成 JSON 文件，在使用 `cilium policy import` 命令即可应用到 Cilium 网络中。
|
||||
|
||||
|
||||
|
||||
|
||||
如图所示，此时 `id` 标签为其他值的容器就无法访问 `id=app1` 容器，策略配置中的 `toPorts` 中还可以配置 HTTP `method` 和 `path`，实现更细粒度的访问策略控制，详见 [Cilium 官方文档](https://cilium.readthedocs.io/en/stable/gettingstarted/docker/)。
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ Cilium是一个纯开源软件，没有哪家公司提供商业化支持，也
|
|||
|
||||
Cilium的基础是一种名为BPF的新Linux内核技术，它可以在Linux本身动态插入强大的安全可见性和控制逻辑。由于BPF在Linux内核中运行，因此可以应用和更新Cilium安全策略，而无需对应用程序代码或容器配置进行任何更改。
|
||||
|
||||
|
||||
|
||||
|
||||
基于微服务的应用程序分为小型独立服务，这些服务使用**HTTP**、**gRPC**、**Kafka**等轻量级协议通过API相互通信。但是，现有的Linux网络安全机制（例如iptables）仅在网络和传输层（即IP地址和端口）上运行，并且缺乏对微服务层的可见性。
|
||||
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@
|
|||
|
||||
Kubernetes设计理念和功能其实就是一个类似Linux的分层架构，如下图所示
|
||||
|
||||
|
||||
|
||||
|
||||
* 核心层：Kubernetes最核心的功能，对外提供API构建高层的应用，对内提供插件式应用执行环境
|
||||
* 应用层：部署（无状态应用、有状态应用、批处理任务、集群应用等）和路由（服务发现、DNS解析等）
|
||||
|
|
|
|||
|
After Width: | Height: | Size: 297 KiB |
|
After Width: | Height: | Size: 269 KiB |
|
After Width: | Height: | Size: 167 KiB |
|
After Width: | Height: | Size: 75 KiB |
|
After Width: | Height: | Size: 474 KiB |
|
After Width: | Height: | Size: 73 KiB |
|
After Width: | Height: | Size: 291 KiB |
|
After Width: | Height: | Size: 172 KiB |
|
After Width: | Height: | Size: 537 KiB |
|
After Width: | Height: | Size: 232 KiB |
|
After Width: | Height: | Size: 436 KiB |
|
After Width: | Height: | Size: 166 KiB |
|
After Width: | Height: | Size: 111 KiB |
|
After Width: | Height: | Size: 184 KiB |
|
After Width: | Height: | Size: 146 KiB |
|
After Width: | Height: | Size: 212 KiB |
|
After Width: | Height: | Size: 374 KiB |
|
After Width: | Height: | Size: 204 KiB |
|
After Width: | Height: | Size: 209 KiB |
|
After Width: | Height: | Size: 232 KiB |
|
After Width: | Height: | Size: 316 KiB |
|
After Width: | Height: | Size: 68 KiB |
|
After Width: | Height: | Size: 6.8 KiB |
|
After Width: | Height: | Size: 13 KiB |
|
After Width: | Height: | Size: 269 KiB |
|
After Width: | Height: | Size: 195 KiB |
|
After Width: | Height: | Size: 62 KiB |
|
After Width: | Height: | Size: 243 KiB |
|
After Width: | Height: | Size: 220 KiB |
|
After Width: | Height: | Size: 62 KiB |
|
After Width: | Height: | Size: 73 KiB |
|
After Width: | Height: | Size: 85 KiB |
|
After Width: | Height: | Size: 109 KiB |
|
After Width: | Height: | Size: 113 KiB |
|
After Width: | Height: | Size: 150 KiB |
|
After Width: | Height: | Size: 269 KiB |
|
After Width: | Height: | Size: 538 KiB |
|
After Width: | Height: | Size: 126 KiB |
|
After Width: | Height: | Size: 133 KiB |
|
After Width: | Height: | Size: 176 KiB |
|
After Width: | Height: | Size: 188 KiB |
|
After Width: | Height: | Size: 246 KiB |
|
After Width: | Height: | Size: 197 KiB |
|
After Width: | Height: | Size: 220 KiB |
|
After Width: | Height: | Size: 23 KiB |
|
After Width: | Height: | Size: 172 KiB |
|
After Width: | Height: | Size: 422 KiB |
|
After Width: | Height: | Size: 429 KiB |
|
After Width: | Height: | Size: 426 KiB |
|
After Width: | Height: | Size: 345 KiB |
|
After Width: | Height: | Size: 553 KiB |
|
After Width: | Height: | Size: 608 KiB |
|
After Width: | Height: | Size: 174 KiB |
|
After Width: | Height: | Size: 368 KiB |
|
After Width: | Height: | Size: 452 KiB |
|
After Width: | Height: | Size: 517 KiB |
|
After Width: | Height: | Size: 562 KiB |
|
After Width: | Height: | Size: 42 KiB |
|
After Width: | Height: | Size: 428 KiB |
|
After Width: | Height: | Size: 231 KiB |
|
After Width: | Height: | Size: 231 KiB |
|
After Width: | Height: | Size: 86 KiB |
|
After Width: | Height: | Size: 343 KiB |
|
After Width: | Height: | Size: 68 KiB |
|
After Width: | Height: | Size: 90 KiB |
|
After Width: | Height: | Size: 144 KiB |
|
After Width: | Height: | Size: 124 KiB |
|
After Width: | Height: | Size: 158 KiB |
|
After Width: | Height: | Size: 157 KiB |
|
After Width: | Height: | Size: 168 KiB |
|
After Width: | Height: | Size: 331 KiB |
|
After Width: | Height: | Size: 567 KiB |
|
After Width: | Height: | Size: 2.5 MiB |
|
After Width: | Height: | Size: 230 KiB |
|
After Width: | Height: | Size: 397 KiB |
|
After Width: | Height: | Size: 760 KiB |
|
After Width: | Height: | Size: 644 KiB |
|
After Width: | Height: | Size: 675 KiB |
|
After Width: | Height: | Size: 1.2 MiB |
|
After Width: | Height: | Size: 521 KiB |
|
After Width: | Height: | Size: 566 KiB |
|
After Width: | Height: | Size: 520 KiB |
|
After Width: | Height: | Size: 796 KiB |
|
After Width: | Height: | Size: 586 KiB |
|
After Width: | Height: | Size: 1.0 MiB |