refine
Jimmy song
parent
0c46171d3b
commit
5cde869b16
|
|
@ -2,6 +2,10 @@
|
|||
|
||||
> 云原生是一种行为方式和设计理念，如今它正在遭受过度地市场化包装。究其本质，凡是能够提高云上资源利用率和应用交付效率的行为或方式都是云原生的。云计算的发展史就是一部云原生化的历史。—— [Jimmy Song](https://jimmysong.io)
|
||||
|
||||
|
||||
|
||||
👉 [https://cloudnative.to](https://cloudnative.to)
|
||||
|
||||
[Kubernetes](http://kubernetes.io) 是 Google 于 [2014 年 6 月](https://jimmysong.io/cloud-native/memo/open-source/)基于其内部使用的 [Borg](https://research.google.com/pubs/pub43438.html) 系统开源出来的容器编排调度引擎，Google 将其作为初始和核心项目贡献给 [CNCF](https://cncf.io)（云原生计算基金会），近年来逐渐发展出了云原生生态。
|
||||
|
||||
Kubernetes 的目标不仅仅是一个编排系统，而是提供一个规范用以描述集群的架构，定义服务的最终状态，使系统自动地达到和维持该状态。Kubernetes 作为云原生应用的基石，相当于一个云操作系统，其重要性不言而喻。
|
||||
|
|
@ -80,7 +84,9 @@ Kubernetes Handbook 开源于 2017 年 3 月并在其后不断完善，是第一
|
|||
|
||||
## 云原生社区
|
||||
|
||||
云原生社区是一个有技术、有温度、有情怀的开源社区，由 [Jimmy 和他的伙伴们](https://cloudnative.to/team) 成立于 2020 年 5 月 12 日，秉持 “共识、共治、共建、共享” 的原则。立足中国，面向世界，企业中立，旨在借助开源打破企业的边界，关注技术人的成长，面向全球华人，促进中国云原生开源的发展。云原生官方网站 <https://cloudnative.to>，关注社区微信公众号，获取加入方式。
|
||||
云原生社区是一个有技术、有温度、有情怀的开源社区，由 [Jimmy 和他的伙伴们](https://cloudnative.to/team) 成立于 2020 年 5 月 12 日，由 2016 年即成立的「K8s&云原生讨论群」改组而成，覆盖了上千名云原生早期采纳者。社区秉持 “共识、共治、共建、共享” 的原则，立足中国，面向世界，企业中立，旨在为广大云原生爱好者构建一个自由交流和分享的平台，让云原生技术为大众所用。
|
||||
|
||||
官方网站 <https://cloudnative.to>，关注云原生社区官方微信公众号，获取加入方式。
|
||||
|
||||
<p align="center">
|
||||
<img src="images/cloud-native-wechat.jpg" alt="云原生社区微信公众号" title="云原生社区微信公众号"/>
|
||||
|
|
|
|||
|
|
@ -1,5 +1,7 @@
|
|||
# DaemonSet
|
||||
|
||||
本文将为您介绍 DaemonSet 的基本概念。
|
||||
|
||||
## 什么是 DaemonSet？
|
||||
|
||||
_DaemonSet_ 确保全部（或者一些）Node 上运行一个 Pod 的副本。当有 Node 加入集群时，也会为他们新增一个 Pod 。当有 Node 从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。
|
||||
|
|
|
|||
|
|
@ -128,9 +128,4 @@ kubectl delete replicaset my-repset --cascade=false
|
|||
## 已知的问题
|
||||
|
||||
- 1.7 版本，垃圾收集不支持 [自定义资源](https://kubernetes.io/docs/concepts/api-extension/custom-resources/)，比如那些通过 CustomResourceDefinition 新增，或者通过 API server 聚集而成的资源对象。
|
||||
|
||||
[其它已知的问题](https://github.com/kubernetes/kubernetes/issues/26120)
|
||||
|
||||
原文地址：https://k8smeetup.github.io/docs/concepts/workloads/controllers/garbage-collection/
|
||||
|
||||
译者：[shirdrn](https://github.com/shirdrn)
|
||||
- [其它已知的问题](https://github.com/kubernetes/kubernetes/issues/26120)。
|
||||
|
|
|
|||
|
|
@ -242,11 +242,3 @@ Pod 重启，会导致 Init 容器重新执行，主要有如下几个原因：
|
|||
## 支持与兼容性
|
||||
|
||||
API Server 版本为 1.6 或更高版本的集群，通过使用 `spec.initContainers` 字段来支持 Init 容器。之前的版本可以使用 alpha 和 beta 注解支持 Init 容器。`spec.initContainers` 字段也被加入到 alpha 和 beta 注解中，所以 Kubernetes 1.3.0 版本或更高版本可以执行 Init 容器，并且 1.6 版本的 API Server 能够安全地回退到 1.5.x 版本，而不会使已创建的 Pod 失去 Init 容器的功能。
|
||||
|
||||
---
|
||||
|
||||
> 原文地址：https://k8smeetup.github.io/docs/concepts/workloads/pods/init-containers/
|
||||
>
|
||||
> 译者：[shirdrn](https://github.com/shirdrn)
|
||||
>
|
||||
> 校对：[Jimmy Song](https://github.com/rootsongjc)
|
||||
|
|
|
|||
|
|
@ -10,9 +10,7 @@
|
|||
|
||||
**获取集群中有哪些 namespace **
|
||||
|
||||
```
|
||||
kubectl get ns
|
||||
```
|
||||
```kubectl get ns```
|
||||
|
||||
集群中默认会有 `default` 和 `kube-system` 这两个 namespace。
|
||||
|
||||
|
|
@ -21,4 +19,3 @@ kubectl get ns
|
|||
用户的普通应用默认是在 `default` 下，与集群管理相关的为整个集群提供服务的应用一般部署在 `kube-system` 的 namespace 下，例如我们在安装 kubernetes 集群时部署的 `kubedns`、`heapseter`、`EFK` 等都是在这个 namespace 下面。
|
||||
|
||||
另外，并不是所有的资源对象都会对应 namespace，`node` 和 `persistentVolume` 就不属于任何 namespace。
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Node
|
||||
|
||||
Node是kubernetes集群的工作节点，可以是物理机也可以是虚拟机。
|
||||
Node 是 Kubernetes 集群的工作节点，可以是物理机也可以是虚拟机。
|
||||
|
||||
## Node 的状态
|
||||
|
||||
|
|
@ -23,13 +23,13 @@ Node包括如下状态信息：
|
|||
|
||||
## Node 管理
|
||||
|
||||
禁止pod调度到该节点上
|
||||
禁止 Pod 调度到该节点上。
|
||||
|
||||
```bash
|
||||
kubectl cordon <node>
|
||||
```
|
||||
|
||||
驱逐该节点上的所有pod
|
||||
驱逐该节点上的所有 Pod。
|
||||
|
||||
```bash
|
||||
kubectl drain <node>
|
||||
|
|
|
|||
|
|
@ -198,5 +198,3 @@ spec:
|
|||
## 参考
|
||||
|
||||
- [Pod lifecycle - kubernetes.io](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/)
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,7 @@
|
|||
# Pod 概览
|
||||
|
||||
本文将为您讲解 Pod 的基础概念。
|
||||
|
||||
## 理解 Pod
|
||||
|
||||
Pod 是 kubernetes 中你可以创建和部署的最小也是最简的单位。Pod 代表着集群中运行的进程。
|
||||
|
|
@ -14,7 +16,7 @@ Pod中封装着应用的容器（有的情况下是好几个容器），存储
|
|||
- **一个 Pod 中运行一个容器**。“每个 Pod 中一个容器” 的模式是最常见的用法；在这种使用方式中，你可以把 Pod 想象成是单个容器的封装，kuberentes 管理的是 Pod 而不是直接管理容器。
|
||||
- **在一个 Pod 中同时运行多个容器**。一个 Pod 中也可以同时封装几个需要紧密耦合互相协作的容器，它们之间共享资源。这些在同一个 Pod 中的容器可以互相协作成为一个 service 单位 —— 一个容器共享文件，另一个 “sidecar” 容器来更新这些文件。Pod 将这些容器的存储资源作为一个实体来管理。
|
||||
|
||||
[Kubernetes Blog](http://blog.kubernetes.io) 有关于Pod用例的详细信息，查看：
|
||||
[Kubernetes Blog](https://kubernetes.io/blog) 有关于 Pod 用例的详细信息，查看：
|
||||
|
||||
- [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns/)
|
||||
- [Container Design Patterns](https://kubernetes.io/blog/2016/06/container-design-patterns/)
|
||||
|
|
|
|||
|
|
@ -184,7 +184,3 @@ podsecuritypolicy "permissive" deleted
|
|||
在 Kubernetes 1.5 或更新版本，可以使用 PodSecurityPolicy 来控制，对基于用户角色和组的已授权容器的访问。访问不同的 PodSecurityPolicy 对象，可以基于认证来控制。基于 Deployment、ReplicaSet 等创建的 Pod，限制访问 PodSecurityPolicy 对象，[Controller Manager](https://kubernetes.io/docs/admin/kube-controller-manager/) 必须基于安全 API 端口运行，并且不能够具有超级用户权限。
|
||||
|
||||
PodSecurityPolicy 认证使用所有可用的策略，包括创建 Pod 的用户，Pod 上指定的服务账户（service acount）。当 Pod 基于 Deployment、ReplicaSet 创建时，它是创建 Pod 的 Controller Manager，所以如果基于非安全 API 端口运行，允许所有的 PodSecurityPolicy 对象，并且不能够有效地实现细分权限。用户访问给定的 PSP 策略有效，仅当是直接部署 Pod 的情况。当直接部署 Pod 时，应用 PodSecurityPolicy 控制基于角色和组的已授权容器的访问 。
|
||||
|
||||
原文地址：https://k8smeetup.github.io/docs/concepts/policy/pod-security-policy/
|
||||
|
||||
译者：[shirdrn](https://github.com/shirdrn)
|
||||
|
|
|
|||
|
|
@ -1,7 +1,5 @@
|
|||
# RBAC—— 基于角色的访问控制
|
||||
|
||||
以下内容是 [xingzhou](https://github.com/xingzhou) 对 kubernetes 官方文档的翻译，原文地址 https://k8smeetup.github.io/docs/admin/authorization/rbac/
|
||||
|
||||
基于角色的访问控制（Role-Based Access Control, 即”RBAC”）使用”rbac.authorization.k8s.io” API Group 实现授权决策，允许管理员通过 Kubernetes API 动态配置策略。
|
||||
|
||||
截至 Kubernetes 1.6，RBAC 模式处于 beta 版本。
|
||||
|
|
@ -56,8 +54,9 @@ rules:
|
|||
|
||||
`RoleBinding` 可以引用在同一命名空间内定义的 `Role` 对象。 下面示例中定义的 `RoleBinding` 对象在”default” 命名空间中将”pod-reader” 角色授予用户”jane”。 这一授权将允许用户”jane” 从”default” 命名空间中读取 pod。
|
||||
|
||||
以下角色绑定定义将允许用户 "jane" 从 "default" 命名空间中读取 pod。
|
||||
|
||||
```yaml
|
||||
# 以下角色绑定定义将允许用户"jane"从"default"命名空间中读取pod。
|
||||
kind: RoleBinding
|
||||
apiVersion: rbac.authorization.k8s.io/v1beta1
|
||||
metadata:
|
||||
|
|
@ -96,8 +95,9 @@ roleRef:
|
|||
|
||||
最后，可以使用`ClusterRoleBinding`在集群级别和所有命名空间中授予权限。下面示例中所定义的`ClusterRoleBinding`允许在用户组”manager” 中的任何用户都可以读取集群中任何命名空间中的 secret。
|
||||
|
||||
以下 `ClusterRoleBinding` 对象允许在用户组 "manager" 中的任何用户都可以读取集群中任何命名空间中的 secret。
|
||||
|
||||
```yaml
|
||||
# 以下`ClusterRoleBinding`对象允许在用户组"manager"中的任何用户都可以读取集群中任何命名空间中的secret。
|
||||
kind: ClusterRoleBinding
|
||||
apiVersion: rbac.authorization.k8s.io/v1beta1
|
||||
metadata:
|
||||
|
|
@ -116,10 +116,7 @@ roleRef:
|
|||
|
||||
大多数资源由代表其名字的字符串表示，例如”pods”，就像它们出现在相关 API endpoint 的 URL 中一样。然而，有一些 Kubernetes API 还 包含了” 子资源”，比如 pod 的 logs。在 Kubernetes 中，pod logs endpoint 的 URL 格式为：
|
||||
|
||||
```
|
||||
GET /api/v1/namespaces/{namespace}/pods/{name}/log
|
||||
|
||||
```
|
||||
```GET /api/v1/namespaces/{namespace}/pods/{name}/log```
|
||||
|
||||
在这种情况下，”pods” 是命名空间资源，而”log” 是 pods 的子资源。为了在 RBAC 角色中表示出这一点，我们需要使用斜线来划分资源 与子资源。如果需要角色绑定主体读取 pods 以及 pod log，您需要定义以下角色：
|
||||
|
||||
|
|
@ -213,9 +210,7 @@ rules:
|
|||
verbs: ["get", "post"]
|
||||
```
|
||||
|
||||
### 对角色绑定主体（Subject）的引用
|
||||
|
||||
`RoleBinding`或者`ClusterRoleBinding`将角色绑定到*角色绑定主体*（Subject）。 角色绑定主体可以是用户组（Group）、用户（User）或者服务账户（Service Accounts）。
|
||||
对角色绑定主体（Subject）的引用`RoleBinding`或者`ClusterRoleBinding` 将角色绑定到 *角色绑定主体*（Subject）。 角色绑定主体可以是用户组（Group）、用户（User）或者服务账户（Service Accounts）。
|
||||
|
||||
用户由字符串表示。可以是纯粹的用户名，例如”alice”、电子邮件风格的名字，如 “bob@example.com” 或者是用字符串表示的数字 id。由 Kubernetes 管理员配置 [认证模块](https://k8smeetup.github.io/docs/admin/authentication/) 以产生所需格式的用户名。对于用户名，RBAC 授权系统不要求任何特定的格式。然而，前缀 `system:` 是 为 Kubernetes 系统使用而保留的，所以管理员应该确保用户名不会意外地包含这个前缀。
|
||||
|
||||
|
|
@ -261,11 +256,9 @@ subjects:
|
|||
- kind: Group
|
||||
name: system:serviceaccounts:qa
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
```
|
||||
```在集群中的所有服务账户：
|
||||
|
||||
在集群中的所有服务账户：
|
||||
|
||||
```yaml
|
||||
```yaml
|
||||
subjects:
|
||||
- kind: Group
|
||||
name: system:serviceaccounts
|
||||
|
|
@ -279,11 +272,9 @@ subjects:
|
|||
- kind: Group
|
||||
name: system:authenticated
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
```
|
||||
```所有未认证的用户（version 1.5+）：
|
||||
|
||||
所有未认证的用户（version 1.5+）：
|
||||
|
||||
```yaml
|
||||
```yaml
|
||||
subjects:
|
||||
- kind: Group
|
||||
name: system:unauthenticated
|
||||
|
|
@ -342,7 +333,7 @@ API Server会创建一组默认的`ClusterRole`和`ClusterRoleBinding`对象。
|
|||
| ---------------------------------- | ---------------------------------------- | ---------------------------------------- |
|
||||
| **system:kube-scheduler** | **system:kube-scheduler** user | 允许访问 kube-scheduler 组件所需要的资源。 |
|
||||
| **system:kube-controller-manager** | **system:kube-controller-manager** user | 允许访问 kube-controller-manager 组件所需要的资源。 单个控制循环所需要的权限请参阅 [控制器（controller）角色](https://k8smeetup.github.io/docs/admin/authorization/rbac/#controller-roles). |
|
||||
| **system:node** | **system:nodes** group (deprecated in 1.7) | 允许对kubelet组件所需要的资源的访问，**包括读取所有secret和对所有pod的写访问**。 自Kubernetes 1.7开始, 相比较于这个角色，更推荐使用[Node authorizer](https://kubernetes.io/docs/admin/authorization/node/) 以及[NodeRestriction admission plugin](https://kubernetes.io/docs/admin/admission-controllers#NodeRestriction)， 并允许根据调度运行在节点上的pod授予kubelets API访问的权限。 自Kubernetes 1.7开始，当启用`Node`授权模式时，对`system:nodes`用户组的绑定将不会被自动创建。 |
|
||||
| **system:node** | **system:nodes** group (deprecated in 1.7) | 允许对 kubelet 组件所需要的资源的访问，**包括读取所有 secret 和对所有 pod 的写访问**。 自 Kubernetes 1.7 开始，相比较于这个角色，更推荐使用 [Node authorizer](https://kubernetes.io/docs/admin/authorization/node/) 以及 [NodeRestriction admission plugin](https://kubernetes.io/docs/admin/admission-controllers#NodeRestriction)， 并允许根据调度运行在节点上的 pod 授予 kubelets API 访问的权限。 自 Kubernetes 1.7 开始，当启用 `Node` 授权模式时，对 `system:nodes` 用户组的绑定将不会被自动创建。 |
|
||||
| **system:node-proxier** | **system:kube-proxy** user | 允许对 kube-proxy 组件所需要资源的访问。 |
|
||||
|
||||
### 其它组件角色
|
||||
|
|
@ -563,9 +554,7 @@ subjects:
|
|||
|
||||
同时运行 RBAC 和 ABAC 授权器，并包括旧版 ABAC 策略：
|
||||
|
||||
```
|
||||
--authorization-mode=RBAC,ABAC --authorization-policy-file=mypolicy.jsonl
|
||||
```
|
||||
```--authorization-mode=RBAC,ABAC --authorization-policy-file=mypolicy.jsonl```
|
||||
|
||||
RBAC 授权器将尝试首先授权请求。如果 RBAC 授权器拒绝 API 请求，则 ABAC 授权器将被运行。这意味着 RBAC 策略 *或者* ABAC 策略所允许的任何请求都是可通过的。
|
||||
|
||||
|
|
|
|||
|
|
@ -55,4 +55,3 @@ spec:
|
|||
ports:
|
||||
- containerPort: 80
|
||||
```
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue