SEO优化
This commit is contained in:
huanqing.shao
@ -1,6 +1,6 @@
|
||||
---
|
||||
layout: LearningLayout
|
||||
description: 在 Kubernetes 中，将 Pod 容器组调度到指定的节点
|
||||
description: Kubernete教程_在Kubernetes中将Pod容器组调度到指定的节点
|
||||
---
|
||||
|
||||
# 将容器组调度到指定的节点
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
layout: LearningLayout
|
||||
description: 在 Kubernetes 中，管理和分配容器的计算资源
|
||||
description: Kubernete教程_在Kubernetes中管理和分配容器的计算资源
|
||||
---
|
||||
|
||||
# 管理容器的计算资源
|
||||
|
||||
@ -1,9 +1,9 @@
|
||||
---
|
||||
layout: LearningLayout
|
||||
description: Kubernetes ConfigMap 可以将配置信息和容器镜像解耦，以使得容器化的应用程序可移植。本文提供了一系列的实例，解释如何通过 Kuboard 创建 ConfigMap 以及如何使用 ConfigMap 中的数据配置 Pod（容器组）。
|
||||
description: Kubernete教程_Kubernetes_ConfigMap可以将配置信息和容器镜像解耦_以使得容器化的应用程序可移植_本文提供了一系列的实例_解释如何通过Kuboard创建ConfigMap以及如何使用ConfigMap中的数据配置Pod（容器组）。
|
||||
---
|
||||
|
||||
# 使用 ConfigMap 配置您的应用程序
|
||||
# 使用ConfigMap配置您的应用程序
|
||||
|
||||
本文参考了 Kubernetes 官网 [Configure a Pod to Use a ConfigMap](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap)，并有所改写
|
||||
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
layout: LearningLayout
|
||||
description: 在 Kubernetes 中，配置和使用 Secrets
|
||||
description: Kubernete教程_在Kubernetes中_配置和使用_Secrets
|
||||
---
|
||||
|
||||
# Secrets
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
layout: LearningLayout
|
||||
description: 在 Kubernetes 中，配置 污点和容忍 taints and toleration
|
||||
description: Kubernete教程_在Kubernetes中_配置污点和容忍taints_and_toleration
|
||||
---
|
||||
|
||||
# 污点和容忍 taints and toleration
|
||||
|
||||
@ -1,9 +1,9 @@
|
||||
---
|
||||
layout: LearningLayout
|
||||
description: 本文描述如何搭建 NFS 服务，并在 Kubernetes 中配置 StorageClass 使用该 NFS 服务作为存储
|
||||
description: Kubernete教程_本文描述如何搭建NFS服务_并在Kubernetes中配置StorageClass使用该NFS服务作为存储
|
||||
---
|
||||
|
||||
# 搭建 NFS 服务
|
||||
# 搭建NFS服务
|
||||
|
||||
本文描述如何搭建 NFS 服务，仅用于测试
|
||||
|
||||
|
||||
@ -1,9 +1,9 @@
|
||||
---
|
||||
layout: LearningLayout
|
||||
description: 本文介绍了存储卷 PersistentVolume，存储卷声明 PersistentVolumeClaim 的概念，他们的关系，以及如何使用
|
||||
description: Kubernete教程_本文介绍了存储卷PersistentVolume_存储卷声明PersistentVolumeClaim的概念_他们的关系_以及如何使用
|
||||
---
|
||||
|
||||
# 存储卷 PersistentVolume
|
||||
# 存储卷PersistentVolume
|
||||
|
||||
参考文档： Kubernetes 官方文档 [Persistent Volumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/)
|
||||
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
layout: LearningLayout
|
||||
description: 本文介绍了如何选择 Kubernetes 存储卷类型/数据卷类型
|
||||
description: Kubernete教程_本文介绍了如何选择Kubernetes存储卷类型/数据卷类型
|
||||
---
|
||||
|
||||
# 数据卷类型如何选择
|
||||
|
||||
@ -1,9 +1,9 @@
|
||||
---
|
||||
layout: LearningLayout
|
||||
description: 本文介绍了存储类的概念及其使用
|
||||
description: Kubernete教程_本文介绍了存储类的概念及其使用
|
||||
---
|
||||
|
||||
# 存储类 StorageClass
|
||||
# 存储类StorageClass
|
||||
|
||||
参考文档： Kubernetes 官网 [Storage Classes](https://kubernetes.io/docs/concepts/storage/storage-classes/)
|
||||
|
||||
|
||||
@ -1,9 +1,9 @@
|
||||
---
|
||||
layout: LearningLayout
|
||||
description: 本文介绍 Kubernetes 中 Volume（数据卷）的基本概念、用法以及支持的数据卷类型
|
||||
description: Kubernete教程_本文介绍Kubernetes中Volume（数据卷）的基本概念_用法以及支持的数据卷类型
|
||||
---
|
||||
|
||||
# 数据卷 Volume
|
||||
# 数据卷Volume
|
||||
|
||||
参考文档： Kubernetes 官网文档 [Volumes](https://kubernetes.io/docs/concepts/storage/volumes/)
|
||||
|
||||
|
||||
@ -1,9 +1,9 @@
|
||||
---
|
||||
layout: LearningLayout
|
||||
description: 通过Kuboard 配置 Kubernetes，使用私有 registry 中的 docker 镜像
|
||||
description: Kubernete教程_通过Kuboard配置Kubernetes_使用私有registry中的docker镜像
|
||||
---
|
||||
|
||||
# 使用私有仓库中的 docker 镜像
|
||||
# 使用私有仓库中的docker镜像
|
||||
|
||||
企业通常会因为如下几个原因，需要搭建自己的私有 docker registry：
|
||||
* 限制 docker 镜像的分发范围，例如：只允许在内网分发，或者只允许被授权的用户获取 docker 镜像
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 315 KiB |
@ -1,6 +1,6 @@
|
||||
---
|
||||
layout: LearningLayout
|
||||
description: 在 Kubernetes 中，通过 Service 连接应用程序
|
||||
description: Kubernete教程_在Kubernetes中_如何选择合适的网络插件CNI
|
||||
---
|
||||
|
||||
# 如何选择网络插件
|
||||
|
||||
@ -1,8 +1,210 @@
|
||||
---
|
||||
layout: LearningLayout
|
||||
description: 在 Kubernetes 中，通过 Service 连接应用程序
|
||||
description: Kubernete教程_在Kubernetes中_通过Service连接应用程序
|
||||
---
|
||||
|
||||
# Service 连接应用程序
|
||||
# Service连接应用程序
|
||||
|
||||
正在撰写...
|
||||
参考文档： Kubernetes 官网文档 [Connecting Applications with Services](https://kubernetes.io/docs/concepts/services-networking/connect-applications-service/)
|
||||
|
||||
## Kubernetes 的网络模型
|
||||
|
||||
通过前面教程的学习，我们已经可以将容器化的应用程序在 Kubernetes 中运行起来，并且发布到 Kubernetes 内/外的网络上。
|
||||
|
||||
通常，Docker 使用一种 `host-private` 的联网方式，在此情况下，只有两个容器都在同一个节点（主机）上时，一个容器才可以通过网络连接另一个容器。为了使 Docker 容器可以跨节点通信，必须在宿主节点（主机）的 IP 地址上分配端口，并将该端口接收到的网络请求转发（或代理）到容器中。这意味着，用户必须非常小心地为容器分配宿主节点（主机）的端口号，或者端口号可以自动分配。
|
||||
|
||||
在一个集群中，多个开发者之间协调分配端口号是非常困难的。Kubernetes 认为集群中的两个 Pod 应该能够互相通信，无论他们各自在哪个节点上。每一个 Pod 都被分配自己的 **“cluster-private-IP”**，因此，您无需在 Pod 间建立连接，或者将容器的端口映射到宿主机的端口。因此：
|
||||
* Pod 中的任意容器可以使用 localhost 直连同 Pod 中另一个容器的端口
|
||||
* 集群中的任意 Pod 可以使用另一的 Pod 的 **cluster-private-IP** 直连对方的端口，（无需 NAT 映射）
|
||||
|
||||
本文档的后续章节使用了一个 nginx server 的例子，详细阐述了如何使用这种网络模型发布 Service。
|
||||
|
||||
## 在集群中部署 Pod
|
||||
|
||||
在前面的学习中，我们已经部署过 nginx 应用，此处，我们将该应用再部署一次，并将关注点放在网络连接方面（请留意该 Pod 指定了一个 containerPort）。
|
||||
|
||||
* 创建文件 `run-my-nginx.yaml`，文件内容如下
|
||||
|
||||
``` yaml {19}
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: my-nginx
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
run: my-nginx
|
||||
replicas: 2
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
run: my-nginx
|
||||
spec:
|
||||
containers:
|
||||
- name: my-nginx
|
||||
image: nginx
|
||||
ports:
|
||||
- containerPort: 80
|
||||
```
|
||||
|
||||
* 执行以下命令，部署 Pod 并检查运行情况：
|
||||
|
||||
```sh
|
||||
kubectl apply -f ./run-my-nginx.yaml
|
||||
kubectl get pods -l run=my-nginx -o wide
|
||||
```
|
||||
|
||||
输出结果如下：
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE IP NODE
|
||||
my-nginx-3800858182-jr4a2 1/1 Running 0 13s 10.244.3.4 kubernetes-minion-905m
|
||||
my-nginx-3800858182-kna2y 1/1 Running 0 13s 10.244.2.5 kubernetes-minion-ljyd
|
||||
```
|
||||
|
||||
* 执行命令 `kubectl get pods -l run=my-nginx -o yaml | grep podIP`， 检查 Pod 的 IP 地址，输出结果如下：
|
||||
|
||||
```
|
||||
podIP: 10.244.3.4
|
||||
podIP: 10.244.2.5
|
||||
```
|
||||
|
||||
在集群中的任意节点上，您可以执行 `curl 10.244.3.4` 或 `curl 10.244.2.5` 获得 nginx 的响应。此时：
|
||||
* 容器并没有使用节点上的 80 端口
|
||||
* 没有使用 NAT 规则对容器端口进行映射
|
||||
|
||||
这意味着，您可以
|
||||
* 在同一节点上使用 80 端口运行多个 nginx Pod
|
||||
* 在集群的任意节点/Pod 上使用 nginx Pod 的 clusterIP 访问 nginx 的 80 端口
|
||||
|
||||
同 Docker 一样，Kubernets 中，仍然可以将 Pod 的端口映射到宿主节点的网络地址上（使用 nodePort），但是使用 Kubernetes 的网络模型时，这类需求已经大大减少了。
|
||||
|
||||
如果对该网络模型的实现细节感兴趣，请参考 [Cluster Networking](https://kubernetes.io/docs/concepts/cluster-administration/networking/)
|
||||
|
||||
|
||||
## 创建 Service
|
||||
|
||||
上面的步骤中，我们已经创建了 nginx Pod，运行在集群的 IP 地址空间。您可以直接通过 Pod 的地址访问其端口，但是如果某一个 Pod 终止了该怎么办？Pod 因为故障或其他原因终止后，Deployment Controller 将创建一个新的 Pod 以替代该 Pod，但是 IP 地址将发生变化。Kubernetes Service 解决了这样的问题。
|
||||
|
||||
Kubernetes Service：
|
||||
* 定义了集群中一组 Pod 的逻辑集合，该集合中的 Pod 提供了相同的功能
|
||||
* 被创建后，获得一个唯一的 IP 地址（ClusterIP）。直到该 Service 被删除，此地址不会发生改变
|
||||
* Pod 可以直接连接 Service IP 地址上的端口，且发送到该 IP 地址的网络请求被自动负载均衡分发到 Service 所选取的 Pod 集合中
|
||||
|
||||
执行命令 `kubectl expose deployment/my-nginx` 可以为上面的两个 nginx Pod 创建 Service，输出结果如下所示：
|
||||
|
||||
```
|
||||
service/my-nginx exposed
|
||||
```
|
||||
|
||||
该命令等价于 `kubectl apply -f nginx-svc.yaml`，其中 nginx-svc.yaml 文件的内容如下所示：
|
||||
|
||||
``` yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: my-nginx
|
||||
labels:
|
||||
run: my-nginx
|
||||
spec:
|
||||
ports:
|
||||
- port: 80
|
||||
targetPort: 80
|
||||
protocol: TCP
|
||||
selector:
|
||||
run: my-nginx
|
||||
```
|
||||
|
||||
该 yaml 文件将创建一个 Service：
|
||||
* 该 Service 通过 label selector 选取包含 `run: my-nginx` 标签的 Pod 作为后端 Pod
|
||||
* 该 Service 暴露一个端口 80（`spec.ports[*].port`）
|
||||
* 该 Service 将 80 端口上接收到的网络请求转发到后端 Pod 的 80 （`spec.ports[*].targetPort`）端口上，支持负载均衡
|
||||
|
||||
执行命令 `kubectl get svc my-nginx`，输出结果如下所示：
|
||||
|
||||
```
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
my-nginx ClusterIP 10.0.162.149 <none> 80/TCP 21s
|
||||
```
|
||||
|
||||
Service 的后端 Pod 实际上通过 `Endpoints` 来暴露。Kubernetes 会持续检查 Service 的 label selector `spec.selector`，并将符合条件的 Pod 更新到与 Service 同名（my-nginx）的 Endpoints 对象。如果 Pod 终止了，该 Pod 将被自动从 Endpoints 中移除，新建的 Pod 将自动被添加到该 Endpoint。
|
||||
|
||||
执行命令 `kubectl describe svc my-nginx`，输出结果如下，请注意 Endpoints 中的 IP 地址与上面获得的 Pod 地址相同：
|
||||
|
||||
``` {9}
|
||||
Name: my-nginx
|
||||
Namespace: default
|
||||
Labels: run=my-nginx
|
||||
Annotations: <none>
|
||||
Selector: run=my-nginx
|
||||
Type: ClusterIP
|
||||
IP: 10.0.162.149
|
||||
Port: <unset> 80/TCP
|
||||
Endpoints: 10.244.2.5:80,10.244.3.4:80
|
||||
Session Affinity: None
|
||||
Events: <none>
|
||||
```
|
||||
|
||||
执行命令 `kubectl get ep my-nginx`，输出结果如下：
|
||||
|
||||
```
|
||||
NAME ENDPOINTS AGE
|
||||
my-nginx 10.244.2.5:80,10.244.3.4:80 1m
|
||||
```
|
||||
|
||||
此时，您可以在集群的任意节点上执行 `curl 10.0.162.149:80`，通过 Service 的 ClusterIP:Port 访问 nginx。
|
||||
|
||||
::: tip
|
||||
Service 的 IP 地址是虚拟地址。请参考 [虚拟 IP 的实现](./service-details.html#虚拟-ip-的实现)
|
||||
:::
|
||||
|
||||
## 访问 Service
|
||||
|
||||
Kubernetes 支持两种方式发现服务：
|
||||
* 环境变量 参考 [环境变量](./service-details.html#环境变量)
|
||||
* DNS 参考 [DNS](./service-details.html#dns)
|
||||
|
||||
::: tip
|
||||
由于如下原因，您可能不想激活 Service 的环境变量发现机制：
|
||||
* 可能与应用程序的环境变量冲突
|
||||
* 太多的环境变量
|
||||
* 只想使用 DNS 等
|
||||
|
||||
您可以在 Pod 的定义中，将 `enableServiceLinks` 标记设置为 `false`
|
||||
:::
|
||||
|
||||
### 环境变量
|
||||
|
||||
针对每一个有效的 Service，kubelet 在创建 Pod 时，向 Pod 添加一组环境变量。这种做法引发了一个 Pod 和 Service 的顺序问题。例如，
|
||||
* 执行命令 `kubectl exec my-nginx-3800858182-jr4a2 -- printenv | grep SERVICE` （您的 Pod 名字可能不一样），输出结果如下：
|
||||
|
||||
```
|
||||
KUBERNETES_SERVICE_HOST=10.0.0.1
|
||||
KUBERNETES_SERVICE_PORT=443
|
||||
KUBERNETES_SERVICE_PORT_HTTPS=443
|
||||
```
|
||||
请注意，此时环境变量中没有任何与您的 Service 相关的内容。因为在本教程的前面部分，我们先创建了 Pod 的副本，后创建了 Service。如果我们删除已有的两个 Pod，Deployment 将重新创建 Pod 以替代被删除的 Pod。此时，因为在创建 Pod 时，Service 已经存在，所以我们可以在新的 Pod 中查看到 Service 的环境变量被正确设置。
|
||||
|
||||
* 执行命令 `kubectl get pods -l run=my-nginx`以删除 Pod
|
||||
* 执行命令 `kubectl get pods -l run=my-nginx -o wide` 查看新建Pod，输出结果如下：
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE IP NODE
|
||||
my-nginx-3800858182-e9ihh 1/1 Running 0 5s 10.244.2.7 kubernetes-minion-ljyd
|
||||
my-nginx-3800858182-j4rm4 1/1 Running 0 5s 10.244.3.8 kubernetes-minion-905m
|
||||
```
|
||||
* 执行命令 `kubectl exec my-nginx-3800858182-e9ihh -- printenv | grep SERVICE` （Pod 重建后，名字将会发生变化。请使用您的 Pod 名），输出结果如下，Service 相关的环境变量已经被正确设置
|
||||
```
|
||||
KUBERNETES_SERVICE_PORT=443
|
||||
MY_NGINX_SERVICE_HOST=10.0.162.149
|
||||
KUBERNETES_SERVICE_HOST=10.0.0.1
|
||||
MY_NGINX_SERVICE_PORT=80
|
||||
KUBERNETES_SERVICE_PORT_HTTPS=443
|
||||
```
|
||||
|
||||
### DNS
|
||||
|
||||
Kubernetes 提供了一个 DNS cluster addon Service，可自动为 Service 分配
|
||||
|
||||
## 保护 Service 的安全
|
||||
|
||||
## 暴露 Service
|
||||
|
||||
@ -1,9 +1,9 @@
|
||||
---
|
||||
layout: LearningLayout
|
||||
description: 本文介绍了 Kubernetes 中 Service 和 Pod 的 DNS 分配规则
|
||||
description: Kubernete教程_本文介绍了Kubernetes中Service和Pod的DNS分配规则
|
||||
---
|
||||
|
||||
# Service/Pod 的 DNS
|
||||
# Service/Pod的DNS
|
||||
|
||||
参考文档： Kubernetes 官网文档 [DNS for Services and Pods](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/)
|
||||
|
||||
@ -115,7 +115,92 @@ spec:
|
||||
|
||||
* **ClusterFirstWithHostNet**： 对于运行在节点网络上的 Pod，其 dnsPolicy 必须指定为 `ClusterFirstWithHostNet`
|
||||
|
||||
*
|
||||
* **None**： 允许 Pod 忽略 Kubernetes 环境中的 DNS 设置。此时，该 Pod 的 DNS 的所有设置必须通过 `spce.dnsConfig` 指定。 参考 [Pod 的 DNS 配置](#pod-的-dns-配置)
|
||||
|
||||
“ClusterFirstWithHostNet“: For Pods running with hostNetwork, you should explicitly set its DNS policy “ClusterFirstWithHostNet”.
|
||||
“None“: It allows a Pod to ignore DNS settings from the Kubernetes environment. All DNS settings are supposed to be provided using the dnsConfig field in the Pod Spec. See Pod’s DNS config subsection below.
|
||||
::: warning dnsPolicy的默认值
|
||||
**“Default”** 并非是默认的 DNS Policy。如果 `spec.dnsPolicy` 字段未指定，则 **“ClusterFirst”** 将被默认使用
|
||||
:::
|
||||
|
||||
下面的例子中的 Pod，其 DNS Policy 必须设置为 **“ClusterFirstWithHostNet”**，因为它的 `hostNetwork` 字段为 `true`
|
||||
|
||||
``` yaml {15,16}
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: busybox
|
||||
namespace: default
|
||||
spec:
|
||||
containers:
|
||||
- image: busybox:1.28
|
||||
command:
|
||||
- sleep
|
||||
- "3600"
|
||||
imagePullPolicy: IfNotPresent
|
||||
name: busybox
|
||||
restartPolicy: Always
|
||||
hostNetwork: true
|
||||
dnsPolicy: ClusterFirstWithHostNet
|
||||
```
|
||||
|
||||
### Pod 的 DNS 配置 <Badge text="Kuboard 暂不支持" type="warn"/>
|
||||
|
||||
在 Kubernetes 中，您可以直接配置 Pod 的 DNS 设置。
|
||||
|
||||
Pod 定义中的 `spec.dnsConfig` 是可选字段，且可以与任何类型的 `spec.dnsPolicy` 配合使用。如果 `spec.dnsPolicy` 被设置为 **“None”**，则 `spec.dnsConfig` 必须被指定。
|
||||
|
||||
`spec.dnsConfig` 中有如下字段可以配置：
|
||||
|
||||
* **nameservers**： Pod 的 DNS Server IP 地址列表。最多可以执行 3 个 IP 地址。当 `spec.dnsPolicy` 为 **“None”**，至少需要指定一个 IP 地址，其他情况下该字段是可选的。DNS Server 的 IP 地址列表将会与 DNS Policy 所产生的 DNS Server 地址列表合并（重复的条目被去除）。
|
||||
|
||||
* **searches**：Pod 中执行域名查询时搜索域的列表。该字段是可选的。如果指定了该字段，则指定的搜索域列表将与 DNS Policy 所产生的搜索域列表合并（重复的条目被去除）。合并后的列表最多不超过 6 个域。
|
||||
|
||||
* **options**：可选数组，其中每个元素由 **name** 字段（必填）和 **value** 字段（选填）组成。该列表中的内容将与 DNS Policy 所产生的 DNS 选项合并（重复的条目被去除）
|
||||
|
||||
``` yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
namespace: default
|
||||
name: dns-example
|
||||
spec:
|
||||
containers:
|
||||
- name: test
|
||||
image: nginx
|
||||
dnsPolicy: "None"
|
||||
dnsConfig:
|
||||
nameservers:
|
||||
- 1.2.3.4
|
||||
searches:
|
||||
- ns1.svc.cluster-domain.example
|
||||
- my.dns.search.suffix
|
||||
options:
|
||||
- name: ndots
|
||||
value: "2"
|
||||
- name: edns0
|
||||
```
|
||||
|
||||
上述 Pod 创建后，容器 `test` 的 `etc/resolv.conf` 文件如下所示（从 `spec.dnsConfig` 的配置产生），执行命令 `kubectl exec -it dns-example -- cat /etc/resolv.conf` 可查看该文件内容：
|
||||
|
||||
```
|
||||
nameserver 1.2.3.4
|
||||
search ns1.svc.cluster-domain.example my.dns.search.suffix
|
||||
options ndots:2 edns0
|
||||
```
|
||||
|
||||
如果集群使用的是 IPv6，执行命令 `kubectl exec -it dns-example -- cat /etc/resolv.conf` 的输出结果如下所示：
|
||||
|
||||
```
|
||||
nameserver fd00:79:30::a
|
||||
search default.svc.cluster-domain.example svc.cluster-domain.example cluster-domain.example
|
||||
options ndots:5
|
||||
```
|
||||
|
||||
### 版本兼容性
|
||||
|
||||
Pod 定义中的 `spec.dnsConfig` 和 `spec.dnsPolicy=None` 的兼容性如下：
|
||||
|
||||
| Kubernetes 版本号 | 支持情况 |
|
||||
| ----------------- | ---------------- |
|
||||
| 1.14 | Stable |
|
||||
| 1.10 | Beta（默认启用） |
|
||||
| 1.9 | Alpha |
|
||||
|
||||
@ -1,9 +1,9 @@
|
||||
---
|
||||
layout: LearningLayout
|
||||
description: 本文介绍 Kubernetes Ingress 的概念，包括Ingress 基本概念、如何配置 Ingress Controller、如何使用 kubectl/Kuboard 操作 Ingress 信息
|
||||
description: Kubernete教程_本文介绍Kubernetes_Ingress的概念_包括Ingress基本概念_如何配置Ingress_Controller_如何使用kubectl_Kuboard操作Ingress信息
|
||||
---
|
||||
|
||||
# Ingress 通过互联网访问您的应用
|
||||
# Ingress通过互联网访问您的应用
|
||||
|
||||
参考文档：
|
||||
* Kubernetes 官网 [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/)
|
||||
|
||||
@ -1,9 +1,9 @@
|
||||
---
|
||||
layout: LearningLayout
|
||||
description: 本文介绍了 Kubernetes 中服务发现的机制，以及如何使用服务发现
|
||||
description: Kubernete教程_本文介绍了Kubernetes中服务发现的机制以及如何使用服务发现
|
||||
---
|
||||
|
||||
# Service 详细描述
|
||||
# Service详细描述
|
||||
|
||||
参考文档：Kubernetes 官网文档：[Service](https://kubernetes.io/docs/concepts/services-networking/service/)
|
||||
|
||||
|
||||
@ -1,9 +1,9 @@
|
||||
---
|
||||
layout: LearningLayout
|
||||
description: Kubernetes 中发布 Service 的方式，ServiceType
|
||||
description: Kubernete教程_Kubernetes中发布Service的方式_ServiceType
|
||||
---
|
||||
|
||||
# 发布 Service
|
||||
# 发布Service
|
||||
|
||||
Kubernetes Service 支持的不同访问方式。
|
||||
|
||||
|
||||
@ -1,9 +1,9 @@
|
||||
---
|
||||
layout: LearningLayout
|
||||
description: 本文介绍了 Kubernetes 中服务发现的机制，以及如何使用服务发现
|
||||
description: Kubernete教程_本文介绍了Kubernetes中服务发现的机制以及如何使用服务发现
|
||||
---
|
||||
|
||||
# Service 概述
|
||||
# Service概述
|
||||
|
||||
参考文档：Kubernetes 官网文档：[Service](https://kubernetes.io/docs/concepts/services-networking/service/)
|
||||
|
||||
|
||||
@ -1,9 +1,9 @@
|
||||
---
|
||||
layout: LearningLayout
|
||||
description: 本文描述了 Kubernetes Pod 中的初始化容器的概念、使用场景和使用方法。初始化容器是容器组中 app 容器启动之前执行的容器。可能包含 setup 脚本，或其他工具进程
|
||||
description: Kubernete教程_本文描述了Kubernetes_Pod中的初始化容器的概念_使用场景和使用方法_初始化容器是容器组中app容器启动之前执行的容器_可能包含setup脚本或其他工具进程
|
||||
---
|
||||
|
||||
# 容器组 - 初始化容器
|
||||
# 容器组_初始化容器
|
||||
|
||||
参考文档： Kubernetes 官网 [Init Containers](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/)
|
||||
|
||||
|
||||
@ -1,8 +1,8 @@
|
||||
---
|
||||
description: 本文描述了 Kuboard 如何处理 Kubernetes 容器组
|
||||
description: Kubernete教程_本文描述了Kuboard如何处理Kubernetes容器组
|
||||
---
|
||||
|
||||
# 容器组 - Kuboard
|
||||
# 容器组_Kuboard
|
||||
|
||||
## 通过 Kuboard 创建容器组
|
||||
|
||||
|
||||
@ -1,9 +1,9 @@
|
||||
---
|
||||
layout: LearningLayout
|
||||
description: 本文描述了 Kubernetes 中 Pod 容器组的生命周期
|
||||
description: Kubernete教程_本文描述了Kubernetes中Pod容器组的生命周期
|
||||
---
|
||||
|
||||
# 容器组 - 生命周期
|
||||
# 容器组_生命周期
|
||||
|
||||
参考文档： Kubernetes 官网文档 [Pod Lifecycle](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/)
|
||||
|
||||
|
||||
@ -1,12 +1,12 @@
|
||||
---
|
||||
description: 在 Kubernetes 中为 Pod 中的容器开启 privileged 模式
|
||||
description: Kubernete教程_在Kubernetes中为Pod中的容器开启privileged 模式
|
||||
---
|
||||
|
||||
# 容器组 - Privileged 模式
|
||||
# 容器组_Privileged 模式
|
||||
|
||||
|
||||
## Privilged 模式运行容器
|
||||
|
||||
Pod 中的任何容器都可以开启 privileged 模式，只需要
|
||||
|
||||
Any container in a Pod can enable privileged mode, using the privileged flag on the security context of the container spec. This is useful for containers that want to use Linux capabilities like manipulating the network stack and accessing devices. Processes within the container get almost the same privileges that are available to processes outside a container. With privileged mode, it should be easier to write network and volume plugins as separate Pods that don’t need to be compiled into the kubelet.
|
||||
<!-- Any container in a Pod can enable privileged mode, using the privileged flag on the security context of the container spec. This is useful for containers that want to use Linux capabilities like manipulating the network stack and accessing devices. Processes within the container get almost the same privileges that are available to processes outside a container. With privileged mode, it should be easier to write network and volume plugins as separate Pods that don’t need to be compiled into the kubelet. -->
|
||||
|
||||
@ -1,9 +1,9 @@
|
||||
---
|
||||
layout: LearningLayout
|
||||
description: 本文介绍 Kubernetes 中的最小可调度单元 Pod 容器组的概念，以及如何使用容器组
|
||||
description: Kubernete教程_本文介绍Kubernetes中的最小可调度单元Pod容器组的概念以及如何使用容器组
|
||||
---
|
||||
|
||||
# 容器组 - 概述
|
||||
# 容器组_概述
|
||||
|
||||
参考文档：Kubernetes 官方文档 [Pod Overview](https://kubernetes.io/docs/concepts/workloads/pods/pod-overview/) [Pods](https://kubernetes.io/docs/concepts/workloads/pods/pod/)
|
||||
|
||||
|
||||
@ -1,9 +1,9 @@
|
||||
---
|
||||
layout: LearningLayout
|
||||
description: 本文介绍了 Kubernetes Controller（控制器）的概念，以及控制器的种类
|
||||
description: Kubernete教程_本文介绍了Kubernetes_Controller控制器的概念以及控制器的种类
|
||||
---
|
||||
|
||||
# 控制器 - 概述
|
||||
# 控制器_概述
|
||||
|
||||
## 概述
|
||||
|
||||
|
||||
Reference in New Issue
Block a user