From 6ec1b0bf4b41c301687758de8bbbd42ca15f1b85 Mon Sep 17 00:00:00 2001 From: Stewart-YU Date: Sat, 28 Oct 2017 04:41:33 +0800 Subject: [PATCH] Fix some format (#5996) * Update index.md Fix format * Update fedora_manual_config.md Fix format. * Update libvirt-coreos.md Fix format. * Update libvirt-coreos.md * Update libvirt-coreos.md * Update libvirt-coreos.md update libvirt-coreos.md * Update libvirt-coreos.md --- docs/admin/authorization/index.md | 4 ++-- .../fedora/fedora_manual_config.md | 12 +++++------ docs/getting-started-guides/libvirt-coreos.md | 20 ++++++++++--------- 3 files changed, 19 insertions(+), 17 deletions(-) diff --git a/docs/admin/authorization/index.md b/docs/admin/authorization/index.md index 54ccdc6350..b77a27db39 100644 --- a/docs/admin/authorization/index.md +++ b/docs/admin/authorization/index.md @@ -61,8 +61,8 @@ of the `bind` verb on `roles` and `clusterroles` resources in the `rbac.authoriz * **Node** - A special-purpose authorizer that grants permissions to kubelets based on the pods they are scheduled to run. To learn more about using the Node authorization mode, see [Node Authorization](/docs/admin/authorization/node/). * **ABAC** - Attribute-based access control (ABAC) defines an access control paradigm whereby access rights are granted to users through the use of policies which combine attributes together. The policies can use any type of attributes (user attributes, resource attributes, object, environment attributes etc). To learn more about using the ABAC mode, see [ABAC Mode](/docs/admin/authorization/abac/). * **RBAC** - Role-based access control (RBAC) is a method of regulating access to computer or network resources based on the roles of individual users within an enterprise. In this context, access is the ability of an individual user to perform a specific task, such as view, create, or modify a file. To learn more about using the RBAC mode, see [RBAC Mode](/docs/admin/authorization/rbac/) - ..* When specified "RBAC" (Role-Based Access Control) uses the "rbac.authorization.k8s.io" API group to drive authorization decisions, allowing admins to dynamically configure permission policies through the Kubernetes API. - ..* To enable RBAC, start the apiserver with `--authorization-mode=RBAC`. + * When specified "RBAC" (Role-Based Access Control) uses the "rbac.authorization.k8s.io" API group to drive authorization decisions, allowing admins to dynamically configure permission policies through the Kubernetes API. + * To enable RBAC, start the apiserver with `--authorization-mode=RBAC`. * **Webhook** - A WebHook is an HTTP callback: an HTTP POST that occurs when something happens; a simple event-notification via HTTP POST. A web application implementing WebHooks will POST a message to a URL when certain things happen. To learn more about using the Webhook mode, see [Webhook Mode](/docs/admin/authorization/webhook/). #### Checking API Access diff --git a/docs/getting-started-guides/fedora/fedora_manual_config.md b/docs/getting-started-guides/fedora/fedora_manual_config.md index 6f32409623..8200465b1c 100644 --- a/docs/getting-started-guides/fedora/fedora_manual_config.md +++ b/docs/getting-started-guides/fedora/fedora_manual_config.md @@ -19,7 +19,7 @@ This is a getting started guide for Fedora. It is a manual configuration so you This guide will only get ONE node (previously minion) working. Multiple nodes require a functional [networking configuration](/docs/concepts/cluster-administration/networking/) done outside of Kubernetes. Although the additional Kubernetes configuration requirements should be obvious. -The Kubernetes package provides a few services: kube-apiserver, kube-scheduler, kube-controller-manager, kubelet, kube-proxy. These services are managed by systemd and the configuration resides in a central location: /etc/kubernetes. We will break the services up between the hosts. The first host, fed-master, will be the Kubernetes master. This host will run the kube-apiserver, kube-controller-manager, and kube-scheduler. In addition, the master will also run _etcd_ (not needed if _etcd_ runs on a different host but this guide assumes that _etcd_ and Kubernetes master run on the same host). The remaining host, fed-node will be the node and run kubelet, proxy and docker. +The Kubernetes package provides a few services: kube-apiserver, kube-scheduler, kube-controller-manager, kubelet, kube-proxy. These services are managed by systemd and the configuration resides in a central location: `/etc/kubernetes`. We will break the services up between the hosts. The first host, fed-master, will be the Kubernetes master. This host will run the kube-apiserver, kube-controller-manager, and kube-scheduler. In addition, the master will also run _etcd_ (not needed if _etcd_ runs on a different host but this guide assumes that _etcd_ and Kubernetes master run on the same host). The remaining host, fed-node will be the node and run kubelet, proxy and docker. **System Information:** @@ -45,14 +45,14 @@ dnf -y install kubernetes dnf -y install etcd ``` -* Add master and node to /etc/hosts on all machines (not needed if hostnames already in DNS). Make sure that communication works between fed-master and fed-node by using a utility such as ping. +* Add master and node to `/etc/hosts` on all machines (not needed if hostnames already in DNS). Make sure that communication works between fed-master and fed-node by using a utility such as ping. ```shell echo "192.168.121.9 fed-master 192.168.121.65 fed-node" >> /etc/hosts ``` -* Edit /etc/kubernetes/config (which should be the same on all hosts) to set +* Edit `/etc/kubernetes/config` (which should be the same on all hosts) to set the name of the master server: ```shell @@ -69,7 +69,7 @@ systemctl stop iptables-services firewalld **Configure the Kubernetes services on the master.** -* Edit /etc/kubernetes/apiserver to appear as such. The service-cluster-ip-range IP addresses must be an unused block of addresses, not used anywhere else. They do not need to be routed or assigned to anything. +* Edit `/etc/kubernetes/apiserver` to appear as such. The service-cluster-ip-range IP addresses must be an unused block of addresses, not used anywhere else. They do not need to be routed or assigned to anything. ```shell # The address on the local server to listen to. @@ -85,7 +85,7 @@ KUBE_SERVICE_ADDRESSES="--service-cluster-ip-range=10.254.0.0/16" KUBE_API_ARGS="" ``` -* Edit /etc/etcd/etcd.conf to let etcd listen on all available IPs instead of 127.0.0.1. If you have not done this, you might see an error such as "connection refused". +* Edit `/etc/etcd/etcd.conf` to let etcd listen on all available IPs instead of 127.0.0.1. If you have not done this, you might see an error such as "connection refused". ```shell ETCD_LISTEN_CLIENT_URLS="http://0.0.0.0:2379" @@ -139,7 +139,7 @@ a Kubernetes node (fed-node) below. ***We need to configure the kubelet on the node.*** -* Edit /etc/kubernetes/kubelet to appear as such: +* Edit `/etc/kubernetes/kubelet` to appear as such: ```shell ### diff --git a/docs/getting-started-guides/libvirt-coreos.md b/docs/getting-started-guides/libvirt-coreos.md index 16fe70d66c..c862bce2bf 100644 --- a/docs/getting-started-guides/libvirt-coreos.md +++ b/docs/getting-started-guides/libvirt-coreos.md @@ -41,15 +41,17 @@ On the other hand, `libvirt-coreos` might be useful for people investigating low ### Prerequisites 1. Install [dnsmasq](http://www.thekelleys.org.uk/dnsmasq/doc.html) -2. Install [ebtables](http://ebtables.netfilter.org/) -3. Install [qemu](http://wiki.qemu.org/Main_Page) -4. Install [libvirt](http://libvirt.org/) -5. Install [openssl](http://openssl.org/) -6. Enable and start the libvirt daemon, e.g.: - * ``systemctl enable libvirtd && systemctl start libvirtd`` # for systemd-based systems - * ``/etc/init.d/libvirt-bin start`` # for init.d-based systems -7. [Grant libvirt access to your user¹](https://libvirt.org/aclpolkit.html) -8. Check that your $HOME is accessible to the qemu user² +1. Install [ebtables](http://ebtables.netfilter.org/) +1. Install [qemu](http://wiki.qemu.org/Main_Page) +1. Install [libvirt](http://libvirt.org/) +1. Install [openssl](http://openssl.org/) +1. Enable and start the libvirt daemon, e.g.: + + - `systemctl enable libvirtd && systemctl start libvirtd` for systemd-based systems + - `/etc/init.d/libvirt-bin start` for init.d-based systems + +1. [Grant libvirt access to your user¹](https://libvirt.org/aclpolkit.html) +1. Check that your $HOME is accessible to the qemu user² #### ¹ Depending on your distribution, libvirt access may be denied by default or may require a password at each access.