Use local images instead of weibotuchuang
Jimmy Song
parent
e83f6989b4
commit
e4218e6512
11
README.md
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>
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -199,4 +199,4 @@ ps： 个人觉得这个课程太贵了，为了省点钱 ， 仔细研究下
|
|||
|
||||
|
||||
|
||||
From: [Github_hackstoic](https://github.com/hackstoic/kubernetes_practice/blob/master/%E5%85%B3%E4%BA%8EK8S%E7%9B%B8%E5%85%B3%E8%AE%A4%E8%AF%81%E7%9A%84%E8%AF%B4%E6%98%8E.md)
|
||||
From: [Github_hackstoic](https://github.com/hackstoic/kubernetes_practice/blob/master/%E5%85%B3%E4%BA%8EK8S%E7%9B%B8%E5%85%B3%E8%AE%A4%E8%AF%81%E7%9A%84%E8%AF%B4%E6%98%8E.md)
|
||||
|
|
|
|||
|
|
@ -29,4 +29,4 @@ KCSP计划的适用对象是通过初审的服务提供商，它们为踏上Kube
|
|||
|
||||
## 参考
|
||||
|
||||
- [CNCF 宣布首批 Kubernetes 认证服务提供商](https://mp.weixin.qq.com/s?__biz=MjM5MzM3NjM4MA==&mid=2654684649&idx=2&sn=4bd259d40d4eb33fc07340c07281e6cf)
|
||||
- [CNCF 宣布首批 Kubernetes 认证服务提供商](https://mp.weixin.qq.com/s?__biz=MjM5MzM3NjM4MA==&mid=2654684649&idx=2&sn=4bd259d40d4eb33fc07340c07281e6cf)
|
||||
|
|
|
|||
|
|
@ -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,4 +5,4 @@ CNCF成立于2015年12月11日，自2018年开始每年年初都会发布一次
|
|||
## 参考
|
||||
|
||||
- [CNCF Annual Report 2017 pdf](https://www.cncf.io/wp-content/uploads/2018/03/CNCF-Annual-Report-2017.pdf)
|
||||
- [CNCF Annual Report 2018 pdf](https://www.cncf.io/wp-content/uploads/2019/02/CNCF_Annual_Report_2018_FInal.pdf)
|
||||
- [CNCF Annual Report 2018 pdf](https://www.cncf.io/wp-content/uploads/2019/02/CNCF_Annual_Report_2018_FInal.pdf)
|
||||
|
|
|
|||
|
|
@ -37,4 +37,4 @@ kubectl logs -f my-pod -c my-container
|
|||
```bash
|
||||
kubectl exec my-pod -it /bin/bash
|
||||
kubectl top pod POD_NAME --containers
|
||||
```
|
||||
```
|
||||
|
|
|
|||
|
|
@ -131,4 +131,4 @@ Docker提供了一系列[log drivers](https://docs.docker.com/engine/admin/loggi
|
|||
|
||||
- Email：rootsongjc@gmail.com
|
||||
|
||||
更多关于**Docker**、**MicroServices**、**Big Data**、**DevOps**、**Deep Learning**的内容请关注[Jimmy Song's Blog](https://jimmysong.io)，将不定期更新。
|
||||
更多关于**Docker**、**MicroServices**、**Big Data**、**DevOps**、**Deep Learning**的内容请关注[Jimmy Song's Blog](https://jimmysong.io)，将不定期更新。
|
||||
|
|
|
|||
|
|
@ -126,4 +126,4 @@ kubectl patch deploy --namespace kube-system tiller-deploy -p '{"spec":{"templat
|
|||
|
||||
## 参考
|
||||
|
||||
- [Persistent Volume](https://kubernetes.io/docs/concepts/storage/persistent-volumes/)
|
||||
- [Persistent Volume](https://kubernetes.io/docs/concepts/storage/persistent-volumes/)
|
||||
|
|
|
|||
|
|
@ -30,4 +30,4 @@ CRD不再局限于对单一版本的定制化资源作出定义。如今，利
|
|||
|
||||
## 参考
|
||||
|
||||
- [Kubernetes 1.11: In-Cluster Load Balancing and CoreDNS Plugin Graduate to General Availability](https://kubernetes.io/blog/2018/06/27/kubernetes-1.11-release-announcement/)
|
||||
- [Kubernetes 1.11: In-Cluster Load Balancing and CoreDNS Plugin Graduate to General Availability](https://kubernetes.io/blog/2018/06/27/kubernetes-1.11-release-announcement/)
|
||||
|
|
|
|||
|
|
@ -48,4 +48,4 @@ Kubernetes 1.12可以[在GitHub上下载](https://github.com/kubernetes/kubernet
|
|||
|
||||
## 参考
|
||||
|
||||
- [Kubernetes 1.12: Kubelet TLS Bootstrap and Azure Virtual Machine Scale Sets (VMSS) Move to General Availability](https://kubernetes.io/blog/2018/09/27/kubernetes-1.12-kubelet-tls-bootstrap-and-azure-virtual-machine-scale-sets-vmss-move-to-general-availability/)
|
||||
- [Kubernetes 1.12: Kubelet TLS Bootstrap and Azure Virtual Machine Scale Sets (VMSS) Move to General Availability](https://kubernetes.io/blog/2018/09/27/kubernetes-1.12-kubelet-tls-bootstrap-and-azure-virtual-machine-scale-sets-vmss-move-to-general-availability/)
|
||||
|
|
|
|||
|
|
@ -22,4 +22,4 @@
|
|||
## 参考
|
||||
|
||||
- [Overview of kubeadm](https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm/)
|
||||
- [Kubernetes 1.13: Simplified Cluster Management with Kubeadm, Container Storage Interface (CSI), and CoreDNS as Default DNS are Now Generally Available](https://kubernetes.io/blog/2018/12/03/kubernetes-1-13-release-announcement/)
|
||||
- [Kubernetes 1.13: Simplified Cluster Management with Kubeadm, Container Storage Interface (CSI), and CoreDNS as Default DNS are Now Generally Available](https://kubernetes.io/blog/2018/12/03/kubernetes-1-13-release-announcement/)
|
||||
|
|
|
|||
|
|
@ -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。
|
||||
|
|
@ -17,4 +17,4 @@
|
|||
|
||||
## 参考
|
||||
|
||||
- [Kubernetes 1.14: Production-level support for Windows Nodes, Kubectl Updates, Persistent Local Volumes GA - kuberentes.io](https://kubernetes.io/blog/2019/03/25/kubernetes-1-14-release-announcement/)
|
||||
- [Kubernetes 1.14: Production-level support for Windows Nodes, Kubectl Updates, Persistent Local Volumes GA - kuberentes.io](https://kubernetes.io/blog/2019/03/25/kubernetes-1-14-release-announcement/)
|
||||
|
|
|
|||
|
|
@ -111,4 +111,4 @@ Kubernetes已成为GitHub上参与和讨论人数最多的开源项目，在其
|
|||
|
||||
2018年的IaaS的运营商将主要提供基础架构服务，如虚拟机、存储和数据库等传统的基础架构和服务，仍然会使用现有的工具如Chef、Terraform、Ansible等来管理；Kubernetes则可能直接运行在裸机上运行，结合CI/CD成为DevOps的得力工具，并成为高级开发人员的应用部署首选；Kubernetes也将成为PaaS层的重要组成部分，为开发者提供应用程序部署的简单方法，但是开发者可能不会直接与Kubernetes或者PaaS交互，实际的应用部署流程很可能落在自动化CI工具如Jenkins上。
|
||||
|
||||
2018年，Kubernetes将更加稳定好用，云原生将会出现更多的落地与最佳实践，这都值得我们期待！
|
||||
2018年，Kubernetes将更加稳定好用，云原生将会出现更多的落地与最佳实践，这都值得我们期待！
|
||||
|
|
|
|||
|
|
@ -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 三者之间的关系：
|
||||
|
||||
|
|
|
|||
|
|
@ -17,4 +17,4 @@
|
|||
|
||||
## 更多
|
||||
|
||||
追踪Kubernetes最新特性，请访问互动教学网站提供商 [Katacoda.com](https://katacoda.com) 创建的 [kubernetesstatus.com](http://kubernetesstatus.com/)。
|
||||
追踪Kubernetes最新特性，请访问互动教学网站提供商 [Katacoda.com](https://katacoda.com) 创建的 [kubernetesstatus.com](http://kubernetesstatus.com/)。
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ Kubernetes 社区的贡献、交流和治理方式相关的内容都保存在 <h
|
|||
- 社区成员的角色分类与职责
|
||||
- 社区贡献的 Kubernetes 资源图标
|
||||
|
||||
|
||||
|
||||
|
||||
## 生态环境
|
||||
|
||||
|
|
@ -83,4 +83,4 @@ Kubernetes和Cloud Native相关网站、专栏、博客等。
|
|||
- [twistlock](https://www.twistlock.com/blog/)
|
||||
- [vamp](https://medium.com/vamp-io)
|
||||
- [weave](https://www.weave.works/blog/)
|
||||
- [wercker](http://blog.wercker.com/)
|
||||
- [wercker](http://blog.wercker.com/)
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
# Kubernetes及云原生年度总结及展望
|
||||
|
||||
本节将聚焦Kubernetes及云原生技术的年度总结并展望下一年的发展。
|
||||
本节将聚焦Kubernetes及云原生技术的年度总结并展望下一年的发展。
|
||||
|
|
|
|||
|
|
@ -40,4 +40,4 @@
|
|||
|
||||
云原生计算基金会（CNCF）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式普惠，让这些创新为大众所用。
|
||||
|
||||
**注**：该定义的中文译本还未正式确定，详见[Cloud Native Definition in Chinese](https://github.com/cncf/toc/blob/master/DEFINITION.md)。
|
||||
**注**：该定义的中文译本还未正式确定，详见[Cloud Native Definition in Chinese](https://github.com/cncf/toc/blob/master/DEFINITION.md)。
|
||||
|
|
|
|||
|
|
@ -353,4 +353,4 @@ rm -rf .vagrant
|
|||
- [duffqiu/centos-vagrant](https://github.com/duffqiu/centos-vagrant)
|
||||
- [coredns/deployment](https://github.com/coredns/deployment)
|
||||
- [Kubernetes 1.8 kube-proxy 开启 ipvs](https://mritd.me/2017/10/10/kube-proxy-use-ipvs-on-kubernetes-1.8/#%E4%B8%80%E7%8E%AF%E5%A2%83%E5%87%86%E5%A4%87)
|
||||
- [Vistio—使用Netflix的Vizceral可视化Istio service mesh](https://servicemesher.github.io/blog/vistio-visualize-your-istio-mesh-using-netflixs-vizceral/)
|
||||
- [Vistio—使用Netflix的Vizceral可视化Istio service mesh](https://servicemesher.github.io/blog/vistio-visualize-your-istio-mesh-using-netflixs-vizceral/)
|
||||
|
|
|
|||
|
|
@ -183,4 +183,4 @@ Ballerina 是一种旨在**集成简化**的语言。基于顺序图的交互，
|
|||
## 参考
|
||||
|
||||
- https://ballerina.io
|
||||
- [Microservices, Docker, Kubernetes, Serverless, Service Mesh, and Beyond](https://dzone.com/articles/microservices-docker-kubernetes-serverless-service)
|
||||
- [Microservices, Docker, Kubernetes, Serverless, Service Mesh, and Beyond](https://dzone.com/articles/microservices-docker-kubernetes-serverless-service)
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@
|
|||
|
||||
下文部分来自Joe Duffy的博客[Hello, Pulumi](http://joeduffyblog.com/2018/06/18/hello-pulumi/)！
|
||||
|
||||
|
||||
|
||||
|
||||
TL;DR 有了Pulumi，38页的手动操作说明将变成了38行代码。25000行YAML配置变成了使用真实编程语言的500行语句。
|
||||
|
||||
|
|
@ -151,4 +151,4 @@ $ curl -fsSL https://get.pulumi.com | sh
|
|||
## 参考
|
||||
|
||||
- [Pulumi](https://pulumi.io)
|
||||
- [Hello, Pulumi!](http://joeduffyblog.com/2018/06/18/hello-pulumi/)
|
||||
- [Hello, Pulumi!](http://joeduffyblog.com/2018/06/18/hello-pulumi/)
|
||||
|
|
|
|||
|
|
@ -18,4 +18,4 @@
|
|||
|
||||
使用这种相同类型的配置表示基于容器的微服务、serverless和细粒度托管服务之间的关系导致了异常的复杂性。将应用程序转变为分布式系统应该是事后的想法。事实证明，云覆盖了您的架构和设计。表达架构和设计的最好的方式是使用代码，使用真正的编程语言编写抽象，重用和优秀的工具。
|
||||
|
||||
早些时候，Eric和我采访了几十个客户。我们发现，开发人员和DevOps工程师都普遍感到幻灭。我们发现了极端的专业化，即使在同一个团队中，工程师也不会使用同一种语言。最近几周我已经听到了这个消息，我期待有一天会出现NoYAML运动。
|
||||
早些时候，Eric和我采访了几十个客户。我们发现，开发人员和DevOps工程师都普遍感到幻灭。我们发现了极端的专业化，即使在同一个团队中，工程师也不会使用同一种语言。最近几周我已经听到了这个消息，我期待有一天会出现NoYAML运动。
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
@ -98,4 +98,5 @@ 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)
|
||||
- [CNCF Graduation Criteria v1.2 - github.com](https://github.com/cncf/toc/blob/master/process/graduation_criteria.adoc)
|
||||
|
||||
|
|
|
|||
|
|
@ -27,4 +27,4 @@
|
|||
|
||||
## 参考
|
||||
|
||||
- [CNCF Project Proposal Process v1.2 - github.com](https://github.com/cncf/toc/blob/master/process/project_proposals.adoc)
|
||||
- [CNCF Project Proposal Process v1.2 - github.com](https://github.com/cncf/toc/blob/master/process/project_proposals.adoc)
|
||||
|
|
|
|||
|
|
@ -170,4 +170,4 @@ TOC和CNCF工作人员将一起起草一套上述初步章程，并征集/选举
|
|||
|
||||
## 参考
|
||||
|
||||
- [CNCF Special Interest Groups（SIGs）](https://github.com/cncf/toc/blob/master/sigs/cncf-sigs.md)
|
||||
- [CNCF Special Interest Groups（SIGs）](https://github.com/cncf/toc/blob/master/sigs/cncf-sigs.md)
|
||||
|
|
|
|||
|
|
@ -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,8 +157,8 @@ Pilot和控制平面是为了运维人员准备的。
|
|||
|
||||
Isito在每个上下游服务之间部署一个Envoy，Envoy中有几个基本的服务发现服务，监听器即Envoy要转发的流量端口，Endpoint是要转发的目的地，Cluster是一系列Endpoint用来做负载均衡，Route是定义各种路由规则，每个Envoy进程里可以设置多个Listener。
|
||||
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
本文根据 [Jimmy Song](https://jimmysong.io) 于2018年5月20日在[第四届南京全球技术周](http://njsd-china.org/)上【互联网技术专场】上的题为【云原生应用的下一站】的演讲的部分内容的文字整理而成。
|
||||
本文根据 [Jimmy Song](https://jimmysong.io) 于2018年5月20日在[第四届南京全球技术周](http://njsd-china.org/)上【互联网技术专场】上的题为【云原生应用的下一站】的演讲的部分内容的文字整理而成。
|
||||
|
|
|
|||
|
|
@ -79,4 +79,4 @@ Kubernetes 目前支持的准入控制器有：
|
|||
|
||||
## 参考
|
||||
|
||||
- [Using Admission Controllers - kubernetes.io](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/)
|
||||
- [Using Admission Controllers - kubernetes.io](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/)
|
||||
|
|
|
|||
|
|
@ -25,4 +25,4 @@ Aggregated（聚合的）API server是为了将原来的API server这个巨石
|
|||
|
||||
## 参考
|
||||
|
||||
[Aggregated API Servers - kuberentes design-proposals](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/aggregated-api-servers.md)
|
||||
[Aggregated API Servers - kuberentes design-proposals](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/aggregated-api-servers.md)
|
||||
|
|
|
|||
|
|
@ -129,4 +129,4 @@ v1
|
|||
|
||||
## 参考
|
||||
|
||||
- [API Conventions](https://github.com/kubernetes/community/blob/master/contributors/devel/api-conventions.md#resources)
|
||||
- [API Conventions](https://github.com/kubernetes/community/blob/master/contributors/devel/api-conventions.md#resources)
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
# 身份与权限认证
|
||||
|
||||
Kubernetes中提供了良好的多租户认证管理机制，如RBAC、ServiceAccount还有各种Policy等。
|
||||
Kubernetes中提供了良好的多租户认证管理机制，如RBAC、ServiceAccount还有各种Policy等。
|
||||
|
|
|
|||
|
|
@ -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地址和端口）上运行，并且缺乏对微服务层的可见性。
|
||||
|
||||
|
|
@ -113,4 +113,4 @@ BPF的使用使得Cilium能够以高度可扩展的方式实现以上功能，
|
|||
|
||||
- [Cilium官方网站 - cilium.io](https://cilium.io)
|
||||
- [eBPF 简史 - ibm.com](https://www.ibm.com/developerworks/cn/linux/l-lo-eBPF-history/index.html)
|
||||
- [网络层拦截可选项 - zhihu.com](https://zhuanlan.zhihu.com/p/25672552)
|
||||
- [网络层拦截可选项 - zhihu.com](https://zhuanlan.zhihu.com/p/25672552)
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
# 集群信息
|
||||
|
||||
为了管理异构和不同配置的主机，为了便于Pod的运维管理，Kubernetes中提供了很多集群管理的配置和管理功能，通过namespace划分的空间，通过为node节点创建label和taint用于pod的调度等。
|
||||
为了管理异构和不同配置的主机，为了便于Pod的运维管理，Kubernetes中提供了很多集群管理的配置和管理功能，通过namespace划分的空间，通过为node节点创建label和taint用于pod的调度等。
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@
|
|||
|
||||
Kubernetes设计理念和功能其实就是一个类似Linux的分层架构，如下图所示
|
||||
|
||||
|
||||
|
||||
|
||||
* 核心层：Kubernetes最核心的功能，对外提供API构建高层的应用，对内提供插件式应用执行环境
|
||||
* 应用层：部署（无状态应用、有状态应用、批处理任务、集群应用等）和路由（服务发现、DNS解析等）
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
# 控制器
|
||||
|
||||
Kubernetes中内建了很多controller（控制器），这些相当于一个状态机，用来控制Pod的具体状态和行为。
|
||||
Kubernetes中内建了很多controller（控制器），这些相当于一个状态机，用来控制Pod的具体状态和行为。
|
||||
|
|
|
|||
|
|
@ -66,4 +66,4 @@ $ kubectl get --raw=apis/custom-metrics.metrics.k8s.io/v1alpha1
|
|||
- [1.7版本的kubernetes中启用自定义HPA](https://docs.bitnami.com/kubernetes/how-to/configure-autoscaling-custom-metrics/)
|
||||
- [Horizontal Pod Autoscaler Walkthrough](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)
|
||||
- [Kubernetes 1.8: Now with 100% Daily Value of Custom Metrics](https://blog.openshift.com/kubernetes-1-8-now-custom-metrics/)
|
||||
- [Arbitrary/Custom Metrics in the Horizontal Pod Autoscaler#117](https://github.com/kubernetes/features/issues/117)
|
||||
- [Arbitrary/Custom Metrics in the Horizontal Pod Autoscaler#117](https://github.com/kubernetes/features/issues/117)
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
# 扩展
|
||||
|
||||
Kubernetes是一个高度开放可扩展的架构，可以通过自定义资源类型CRD来定义自己的类型，还可以自己来扩展API服务，用户的使用方式跟Kubernetes的原生对象无异。
|
||||
Kubernetes是一个高度开放可扩展的架构，可以通过自定义资源类型CRD来定义自己的类型，还可以自己来扩展API服务，用户的使用方式跟Kubernetes的原生对象无异。
|
||||
|
|
|
|||
|
|
@ -133,4 +133,4 @@ kubectl delete replicaset my-repset --cascade=false
|
|||
|
||||
原文地址：https://k8smeetup.github.io/docs/concepts/workloads/controllers/garbage-collection/
|
||||
|
||||
译者：[shirdrn](https://github.com/shirdrn)
|
||||
译者：[shirdrn](https://github.com/shirdrn)
|
||||
|
|
|
|||
|
|
@ -150,4 +150,4 @@ Kubernetes 然后查询新的自定义 metric API 来获取相应自定义 metri
|
|||
|
||||
- 自定义metrics开发：https://github.com/kubernetes/metrics
|
||||
|
||||
- 1.7版本的kubernetes中启用自定义HPA：[Configure Kubernetes Autoscaling With Custom Metrics in Kubernetes 1.7 - Bitnami](https://docs.bitnami.com/kubernetes/how-to/configure-autoscaling-custom-metrics/)
|
||||
- 1.7版本的kubernetes中启用自定义HPA：[Configure Kubernetes Autoscaling With Custom Metrics in Kubernetes 1.7 - Bitnami](https://docs.bitnami.com/kubernetes/how-to/configure-autoscaling-custom-metrics/)
|
||||
|
|
|
|||
|
|
@ -249,4 +249,4 @@ API Server 版本为 1.6 或更高版本的集群，通过使用 `spec.initConta
|
|||
>
|
||||
> 译者：[shirdrn](https://github.com/shirdrn)
|
||||
>
|
||||
> 校对：[Jimmy Song](https://github.com/rootsongjc)
|
||||
> 校对：[Jimmy Song](https://github.com/rootsongjc)
|
||||
|
|
|
|||
|
|
@ -226,4 +226,4 @@ spec:
|
|||
|
||||
## 参考
|
||||
|
||||
- [Local Persistent Storage User Guide](https://github.com/kubernetes-incubator/external-storage/tree/master/local-volume)
|
||||
- [Local Persistent Storage User Guide](https://github.com/kubernetes-incubator/external-storage/tree/master/local-volume)
|
||||
|
|
|
|||
|
|
@ -103,4 +103,4 @@ spec:
|
|||
## 参考
|
||||
|
||||
- [Network Policies - k8smeetup.github.io](https://k8smeetup.github.io/docs/concepts/services-networking/network-policies/)
|
||||
- [Network Policies - kubernetes.io](https://kubernetes.io/docs/concepts/services-networking/network-policies/)
|
||||
- [Network Policies - kubernetes.io](https://kubernetes.io/docs/concepts/services-networking/network-policies/)
|
||||
|
|
|
|||
|
|
@ -30,4 +30,4 @@ Kubernetes中的网络可以说对初次接触Kubernetes或者没有网络方面
|
|||
下面仅以当前最常用的flannel和calico插件为例解析。
|
||||
|
||||
- [Kubernetes中的网络解析——以flannel为例](flannel.md)
|
||||
- [Kubernetes中的网络解析——以calico为例](calico.md)
|
||||
- [Kubernetes中的网络解析——以calico为例](calico.md)
|
||||
|
|
|
|||
|
|
@ -38,4 +38,4 @@ Hook调用的日志没有暴露个给Pod的event，所以只能通过`describe`
|
|||
## 参考
|
||||
|
||||
- [Attach Handlers to Container Lifecycle Events](https://kubernetes.io/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)
|
||||
- [Container Lifecycle Hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/)
|
||||
- [Container Lifecycle Hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/)
|
||||
|
|
|
|||
|
|
@ -8,4 +8,4 @@
|
|||
- Pod的生命周期
|
||||
- Pod中容器的启动顺序模板定义
|
||||
|
||||
Kubernetes中的基本组件`kube-controller-manager`就是用来控制Pod的状态和生命周期的，在了解各种controller之前我们有必要先了解下Pod本身和其生命周期。
|
||||
Kubernetes中的基本组件`kube-controller-manager`就是用来控制Pod的状态和生命周期的，在了解各种controller之前我们有必要先了解下Pod本身和其生命周期。
|
||||
|
|
|
|||
|
|
@ -38,4 +38,4 @@ spec:
|
|||
|
||||
## 参考
|
||||
|
||||
- [Configure Quality of Service for Pods](https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/)
|
||||
- [Configure Quality of Service for Pods](https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/)
|
||||
|
|
|
|||
|
|
@ -583,4 +583,4 @@ kubectl create clusterrolebinding permissive-binding \
|
|||
--user=admin \
|
||||
--user=kubelet \
|
||||
--group=system:serviceaccounts
|
||||
```
|
||||
```
|
||||
|
|
|
|||
|
|
@ -9,4 +9,4 @@ Kubernetes中的众多资源类型，例如Deployment、DaemonSet、StatefulSet
|
|||
考虑以下两种情况：
|
||||
|
||||
- 集群中有新增节点，想要让集群中的节点的资源利用率比较均衡一些，想要将一些高负载的节点上的pod驱逐到新增节点上，这是kuberentes的scheduler所不支持的，需要使用如[descheduler](https://github.com/kubernetes-incubator/descheduler)这样的插件来实现。
|
||||
- 想要运行一些大数据应用，设计到资源分片，pod需要与数据分布达到一致均衡，避免个别节点处理大量数据，而其它节点闲置导致整个作业延迟，这时候可以考虑使用[kube-batch](https://github.com/kubernetes-incubator/kube-batch)。
|
||||
- 想要运行一些大数据应用，设计到资源分片，pod需要与数据分布达到一致均衡，避免个别节点处理大量数据，而其它节点闲置导致整个作业延迟，这时候可以考虑使用[kube-batch](https://github.com/kubernetes-incubator/kube-batch)。
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
# 服务发现
|
||||
|
||||
Kubernetes中为了实现服务实例间的负载均衡和不同服务间的服务发现，创造了Serivce对象，同时又为从集群外部访问集群创建了Ingress对象。
|
||||
Kubernetes中为了实现服务实例间的负载均衡和不同服务间的服务发现，创造了Serivce对象，同时又为从集群外部访问集群创建了Ingress对象。
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
# 存储
|
||||
|
||||
为了管理存储，Kubernetes提供了Secret用于管理敏感信息，ConfigMap存储配置，Volume、PV、PVC、StorageClass等用来管理存储卷。
|
||||
为了管理存储，Kubernetes提供了Secret用于管理敏感信息，ConfigMap存储配置，Volume、PV、PVC、StorageClass等用来管理存储卷。
|
||||
|
|
|
|||
|
|
@ -59,4 +59,4 @@ tolerations:
|
|||
|
||||
## 参考
|
||||
|
||||
- [Taints and Tolerations - kuberentes.io](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/)
|
||||
- [Taints and Tolerations - kuberentes.io](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/)
|
||||
|
|
|
|||
|
|
@ -719,4 +719,4 @@ spec:
|
|||
|
||||
- https://kubernetes.io/docs/concepts/storage/volumes/
|
||||
|
||||
- [使用持久化卷来部署 WordPress 和 MySQL](https://kubernetes.io/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/)
|
||||
- [使用持久化卷来部署 WordPress 和 MySQL](https://kubernetes.io/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/)
|
||||
|
|
|
|||
|
|
@ -99,4 +99,4 @@ Kubernetes 在设计之初就考虑到了可扩展性。如果上面提到的 AP
|
|||
- 如果您想推荐新功能或跟上Kubernetes应用开发的最新进展，请考虑加入 SIG，如 [SIG Apps](https://github.com/kubernetes/community/tree/master/sig-apps)。
|
||||
- 如果您有兴趣详细了解 Kubernetes 的内部运作（例如网络），请考虑查看[集群运维之旅](https://kubernetes.io/docs/user-journeys/users/cluster-operator/foundational/)。
|
||||
|
||||
原文：https://kubernetes.io/docs/user-journeys/users/application-developer/advanced
|
||||
原文：https://kubernetes.io/docs/user-journeys/users/application-developer/advanced
|
||||
|
|
|
|||
|
|
@ -38,4 +38,4 @@ index.tenxcloud.com/jimmy/kube-cross:v1.7.5-2
|
|||
|
||||
在我自己的电脑上的整个编译过程大概要半个小时。
|
||||
|
||||
编译完成的二进制文件在`/_output/local/go/bin/`目录下。
|
||||
编译完成的二进制文件在`/_output/local/go/bin/`目录下。
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
# 开发指南说明
|
||||
|
||||
讲解如何在原生 Kubernetes 的基础上做定制开发。
|
||||
讲解如何在原生 Kubernetes 的基础上做定制开发。
|
||||
|
|
|
|||
|
|
@ -31,4 +31,4 @@ Kubebuilder 提供基于简洁的精心设计的示例 godoc 来提供整洁的
|
|||
## 参考
|
||||
|
||||
- [Kubebuilder quick start - book.kubebuilder.io](https://book.kubebuilder.io/quick_start.html)
|
||||
- [kubebuilder - github.com](https://github.com/kubernetes-sigs/kubebuilder/)
|
||||
- [kubebuilder - github.com](https://github.com/kubernetes-sigs/kubebuilder/)
|
||||
|
|
|
|||
|
|
@ -68,4 +68,4 @@ minikube stop
|
|||
|
||||
[Install minikube](https://kubernetes.io/docs/tasks/tools/install-minikube/)
|
||||
|
||||
[Driver plugin installation - xhyve-driver](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#xhyve-driver)
|
||||
[Driver plugin installation - xhyve-driver](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#xhyve-driver)
|
||||
|
|
|
|||
|
|
@ -64,4 +64,4 @@ operator-sdk new kubernetes-operator-sdk-tutorial --api-version=jimmysong.io/v1a
|
|||
|
||||
## 参考
|
||||
|
||||
- [A complete guide to Kubernetes Operator SDK](https://banzaicloud.com/blog/operator-sdk/)
|
||||
- [A complete guide to Kubernetes Operator SDK](https://banzaicloud.com/blog/operator-sdk/)
|
||||
|
|
|
|||
|
|
@ -47,4 +47,4 @@ Operator本质上是与应用息息相关的，因为这是特定领域的知识
|
|||
- [OperatorHub - operatorhub.io](https://www.operatorhub.io)
|
||||
- [Writing a Kubernetes Operator in Golang](https://medium.com/@mtreacher/writing-a-kubernetes-operator-a9b86f19bfb9)
|
||||
- [Introducing Operators: Putting Operational Knowledge into Software](https://coreos.com/blog/introducing-operators.html)
|
||||
- [Automating Kubernetes Cluster Operations with Operators](https://thenewstack.io/automating-kubernetes-cluster-operations-operators/)
|
||||
- [Automating Kubernetes Cluster Operations with Operators](https://thenewstack.io/automating-kubernetes-cluster-operations-operators/)
|
||||
|
|
|
|||
|
|
@ -47,4 +47,4 @@ Kubernetes的社区是以SIG（Special Interest Group特别兴趣小组）和工
|
|||
- **Kubeadm Adoption**：提高kubeadm工具的采用率。
|
||||
- **Resource Management**J：资源隔离和提高资源利用率。
|
||||
|
||||
详细信息请参考 https://github.com/kubernetes/community/blob/master/sig-list.md
|
||||
详细信息请参考 https://github.com/kubernetes/community/blob/master/sig-list.md
|
||||
|
|
|
|||
|
|
@ -288,4 +288,4 @@ rm -rf .vagrant
|
|||
- [Kubernetes handbook - jimmysong.io](https://jimmysong.io/kubernetes-handbook)
|
||||
- [duffqiu/centos-vagrant](https://github.com/duffqiu/centos-vagrant)
|
||||
- [kubernetes-vagrant-centos-cluster](https://github.com/rootsongjc/kubernetes-vagrant-centos-cluster)
|
||||
- [Kubernetes 1.8 kube-proxy 开启 ipvs](https://mritd.me/2017/10/10/kube-proxy-use-ipvs-on-kubernetes-1.8/#%E4%B8%80%E7%8E%AF%E5%A2%83%E5%87%86%E5%A4%87)
|
||||
- [Kubernetes 1.8 kube-proxy 开启 ipvs](https://mritd.me/2017/10/10/kube-proxy-use-ipvs-on-kubernetes-1.8/#%E4%B8%80%E7%8E%AF%E5%A2%83%E5%87%86%E5%A4%87)
|
||||
|
|
|
|||
|
|
@ -247,4 +247,4 @@ $ kubectl cluster-info
|
|||
- 由一些云提供商提供（例如 AWS ELB，Google Cloud Load Balancer）
|
||||
- 当 Kubernetes service 类型为 LoadBalancer 时，会自动创建
|
||||
- 仅使用 UDP/TCP
|
||||
- 实施方式因云提供商而异
|
||||
- 实施方式因云提供商而异
|
||||
|
|
|
|||
|
|
@ -170,4 +170,4 @@ spec:
|
|||
|
||||
## 参考
|
||||
|
||||
- [Accessing Kubernetes Pods from Outside of the Cluster - alesnosek.com](http://alesnosek.com/blog/2017/02/14/accessing-kubernetes-pods-from-outside-of-the-cluster/)
|
||||
- [Accessing Kubernetes Pods from Outside of the Cluster - alesnosek.com](http://alesnosek.com/blog/2017/02/14/accessing-kubernetes-pods-from-outside-of-the-cluster/)
|
||||
|
|
|
|||
|
|
@ -2,4 +2,4 @@
|
|||
|
||||
理论上只要可以使用主机名做服务注册的应用都可以迁移到 kubernetes 集群上。看到这里你可能不禁要问，为什么使用 IP 地址做服务注册发现的应用不适合迁移到 kubernetes 集群？因为这样的应用不适合自动故障恢复，因为目前 kubernetes 中不支持固定 Pod 的 IP 地址，当 Pod 故障后自动转移到其他 Node 的时候该 Pod 的 IP 地址也随之变化。
|
||||
|
||||
将传统应用迁移到 kubernetes 中可能还有很长的路要走，但是直接开发 Cloud native 应用，kubernetes 就是最佳运行时环境了。
|
||||
将传统应用迁移到 kubernetes 中可能还有很长的路要走，但是直接开发 Cloud native 应用，kubernetes 就是最佳运行时环境了。
|
||||
|
|
|
|||
|
|
@ -113,4 +113,4 @@ kubectl create rolebinding $ROLEBINDING_NAME --clusterrole=admin --serviceaccoun
|
|||
## 参考
|
||||
|
||||
- [JSONPath 手册](https://kubernetes.io/docs/user-guide/jsonpath/)
|
||||
- [Kubernetes 中的认证](https://kubernetes.io/docs/admin/authentication/)
|
||||
- [Kubernetes 中的认证](https://kubernetes.io/docs/admin/authentication/)
|
||||
|
|
|
|||
|
|
@ -284,4 +284,4 @@ $ kubectl config use-context federal-context
|
|||
|
||||
- 仔细看一下，了解您的 api-server 的启动方式：在设计 kubeconfig 文件以方便身份验证之前，您需要知道您自己的安全要求和策略。
|
||||
- 将上面的代码段替换为您的集群的 api-server 端点的信息。
|
||||
- 确保您的 api-server 至少能够以提供一个用户（即 `green-user`）凭据的方式启动。 当然您必须查看 api-server 文档，以了解当前关于身份验证细节方面的最新技术。
|
||||
- 确保您的 api-server 至少能够以提供一个用户（即 `green-user`）凭据的方式启动。 当然您必须查看 api-server 文档，以了解当前关于身份验证细节方面的最新技术。
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
# 集群安全性管理
|
||||
|
||||
Kuberentes 支持多租户，这就需要对集群的安全性进行管理。
|
||||
Kuberentes 支持多租户，这就需要对集群的安全性进行管理。
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
# 命令使用
|
||||
|
||||
Kubernetes 中的 kubectl 及其他管理命令使用。
|
||||
Kubernetes 中的 kubectl 及其他管理命令使用。
|
||||
|
|
|
|||
|
|
@ -77,4 +77,4 @@
|
|||
|
||||
## 讨论
|
||||
|
||||
创建连接，将本地的 6379 端口转发到运行在 Pod 中的 Redis 服务器的 6379 端口。有了这个连接您就可以在本地工作站中调试运行在 Pod 中的数据库。
|
||||
创建连接，将本地的 6379 端口转发到运行在 Pod 中的 Redis 服务器的 6379 端口。有了这个连接您就可以在本地工作站中调试运行在 Pod 中的数据库。
|
||||
|
|
|
|||
|
|
@ -153,4 +153,4 @@ kubectl apply -n default -f <(istioctl kube-inject -f k8s-app-monitor-istio-all-
|
|||
|
||||
|
||||
|
||||
至此从代码提交到上线到Kubernetes集群上并集成Istio service mesh的过程就全部完成了。
|
||||
至此从代码提交到上线到Kubernetes集群上并集成Istio service mesh的过程就全部完成了。
|
||||
|
|
|
|||
|
|
@ -266,4 +266,4 @@ Grafana is running at https://108.59.85.141/api/v1/namespaces/kube-system/servic
|
|||
Heapster is running at https://108.59.85.141/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy
|
||||
InfluxDB is running at https://108.59.85.141/api/v1/namespaces/kube-system/services/monitoring-influxdb/proxy
|
||||
```
|
||||
原文地址：https://github.com/rootsongjc/kubernetes.github.io/blob/master/docs/user-guide/docker-cli-to-kubectl.md
|
||||
原文地址：https://github.com/rootsongjc/kubernetes.github.io/blob/master/docs/user-guide/docker-cli-to-kubectl.md
|
||||
|
|
|
|||
|
|
@ -95,4 +95,4 @@ MASQUERADE all -- anywhere anywhere /* ip-masq-agent:
|
|||
|
||||
原文地址：https://k8smeetup.github.io/docs/tasks/administer-cluster/ip-masq-agent/
|
||||
|
||||
译者：[rootsongjc](https://github.com/rootsongjc)
|
||||
译者：[rootsongjc](https://github.com/rootsongjc)
|
||||
|
|
|
|||
|
|
@ -296,4 +296,4 @@ $ kubectl taint nodes foo dedicated=special-user:NoSchedule
|
|||
|
||||
- [JsonPath 手册](https://kubernetes.io/docs/user-guide/jsonpath)
|
||||
|
||||
本文是对官方文档的中文翻译，原文地址：<https://kubernetes.io/docs/user-guide/kubectl-cheatsheet/>
|
||||
本文是对官方文档的中文翻译，原文地址：<https://kubernetes.io/docs/user-guide/kubectl-cheatsheet/>
|
||||
|
|
|
|||
|
|
@ -136,4 +136,4 @@ No resources found.
|
|||
|
||||
可以使用我写的[create-user.sh脚本](https://github.com/rootsongjc/kubernetes-handbook/blob/master/tools/create-user/create-user.sh)来创建namespace和用户并授权，参考[说明](../tools/create-user/README.md)。
|
||||
|
||||
关于角色绑定的更多信息请参考 [RBAC——基于角色的访问控制](rbac.md)。
|
||||
关于角色绑定的更多信息请参考 [RBAC——基于角色的访问控制](rbac.md)。
|
||||
|
|
|
|||
|
|
@ -72,4 +72,4 @@ Namespace 和 API 组属性总是空字符串，资源的名字总是 kubelet
|
|||
- verb=*, resource=nodes, subresource=stats
|
||||
- verb=*, resource=nodes, subresource=log
|
||||
- verb=*, resource=nodes, subresource=spec
|
||||
- verb=*, resource=nodes, subresource=metrics
|
||||
- verb=*, resource=nodes, subresource=metrics
|
||||
|
|
|
|||
|
|
@ -10,4 +10,4 @@ Kubernetic - 一款kubenretes桌面客户端，<https://kubernetic.com/>，支
|
|||
|
||||
|
||||
|
||||
该客户端支持Mac和Windows系统，beta版本免费使用，stable版本需要付费。beta版本某些功能不完善，比如无法在应用内修改ingress配置，无法监控应用的状态等。
|
||||
该客户端支持Mac和Windows系统，beta版本免费使用，stable版本需要付费。beta版本某些功能不完善，比如无法在应用内修改ingress配置，无法监控应用的状态等。
|
||||
|
|
|
|||
|
|
@ -36,4 +36,4 @@
|
|||
- [Isolate containers with a user namespace](https://docs.docker.com/engine/security/userns-remap/)
|
||||
- [Docker Security – It’s a Layered Approach](https://logz.io/blog/docker-security/)
|
||||
- [Kubernetes 1.8: Security, Workloads and Feature Depth](http://blog.kubernetes.io/2017/09/kubernetes-18-security-workloads-and.html)
|
||||
- [Security Matters: RBAC in Kubernetes](https://blog.heptio.com/security-matters-rbac-in-kubernetes-e369b483c8d8)
|
||||
- [Security Matters: RBAC in Kubernetes](https://blog.heptio.com/security-matters-rbac-in-kubernetes-e369b483c8d8)
|
||||
|
|
|
|||
|
|
@ -218,4 +218,4 @@
|
|||
--from-file=artifacts/spark/spark-defaults.conf
|
||||
```
|
||||
|
||||
所有的配置完成后，可以可以使用 kubectl 命令来启动和管理集群了，我们编写了 Makefile，您可以直接使用该 Makefile 封装的命令实现部分的自动化。
|
||||
所有的配置完成后，可以可以使用 kubectl 命令来启动和管理集群了，我们编写了 Makefile，您可以直接使用该 Makefile 封装的命令实现部分的自动化。
|
||||
|
|
|
|||
|
|
@ -584,4 +584,4 @@ kubectl create clusterrolebinding permissive-binding \
|
|||
--user=admin \
|
||||
--user=kubelet \
|
||||
--group=system:serviceaccounts
|
||||
```
|
||||
```
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
# 资源配置
|
||||
|
||||
Kubernetes 中的各个 Object 的配置指南。
|
||||
Kubernetes 中的各个 Object 的配置指南。
|
||||
|
|
|
|||
|
|
@ -96,4 +96,4 @@ spec:
|
|||
|
||||
- [资源配额](https://k8smeetup.github.io/docs/concepts/policy/resource-quotas/)
|
||||
- [为命名空间配置默认的内存请求与限额](https://k8smeetup.github.io/docs/tasks/administer-cluster/memory-default-namespace/)
|
||||
- [在命名空间中配置默认的CPU请求与限额](https://k8smeetup.github.io/docs/tasks/administer-cluster/cpu-default-namespace/)
|
||||
- [在命名空间中配置默认的CPU请求与限额](https://k8smeetup.github.io/docs/tasks/administer-cluster/cpu-default-namespace/)
|
||||
|
|
|
|||
|
|
@ -578,4 +578,4 @@ Pod 中有多个容器。但是，pod 中的每个容器必须请求其挂载卷
|
|||
- 如果运行了多个副本，那么这些 secret 将在它们之间共享。默认情况下，etcd 不能保证与 SSL/TLS 的对等通信，尽管可以进行配置。
|
||||
- 目前，任何节点的 root 用户都可以通过模拟 kubelet 来读取 API server 中的任何 secret。只有向实际需要它们的节点发送 secret 才能限制单个节点的根漏洞的影响，该功能还在计划中。
|
||||
|
||||
原文地址：https://github.com/rootsongjc/kubernetes.github.io/blob/master/docs/concepts/configuration/secret.md
|
||||
原文地址：https://github.com/rootsongjc/kubernetes.github.io/blob/master/docs/concepts/configuration/secret.md
|
||||
|
|
|
|||
|
|
@ -182,4 +182,4 @@ kubectl config set-credentials kubelet-bootstrap --token=${BOOTSTRAP_TOKEN} --ku
|
|||
|
||||
签名控制器不会立即签署所有证书请求。相反，它会一直等待直到适当特权的用户被标记为 “已批准” 状态。这最终将是由外部审批控制器来处理的自动化过程，但是对于 alpha 版本的 API 来说，可以由集群管理员通过 kubectl 命令手动完成。
|
||||
|
||||
管理员可以使用 `kubectl get csr` 命令列出所有的 CSR，使用 `kubectl describe csr <name>` 命令描述某个 CSR的详细信息。在 1.6 版本以前，[没有直接的批准/拒绝命令](https://github.com/kubernetes/kubernetes/issues/30163) ，因此审批者需要直接更新 Status 信息（[查看如何实现](https://github.com/gtank/csrctl)）。此后的 Kubernetes 版本中提供了 `kubectl certificate approve <name>` 和 `kubectl certificate deny <name>` 命令。
|
||||
管理员可以使用 `kubectl get csr` 命令列出所有的 CSR，使用 `kubectl describe csr <name>` 命令描述某个 CSR的详细信息。在 1.6 版本以前，[没有直接的批准/拒绝命令](https://github.com/kubernetes/kubernetes/issues/30163) ，因此审批者需要直接更新 Status 信息（[查看如何实现](https://github.com/gtank/csrctl)）。此后的 Kubernetes 版本中提供了 `kubectl certificate approve <name>` 和 `kubectl certificate deny <name>` 命令。
|
||||
|
|
|
|||
|
|
@ -74,4 +74,4 @@ source <(kubectl completion zsh)
|
|||
|
||||
保存后重启终端即可生效。
|
||||
|
||||
参考：[Install and Set Up kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/#using-zsh)
|
||||
参考：[Install and Set Up kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/#using-zsh)
|
||||
|
|
|
|||
|
|
@ -323,4 +323,4 @@ spec:
|
|||
## 参考
|
||||
|
||||
- https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/
|
||||
- [kubernetes contrib - statefulsets](https://github.com/kubernetes/contrib/tree/master/statefulsets)
|
||||
- [kubernetes contrib - statefulsets](https://github.com/kubernetes/contrib/tree/master/statefulsets)
|
||||
|
|
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 297 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 269 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 167 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 75 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 474 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 73 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 291 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 172 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 537 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 232 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 436 KiB |
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue