Browse Source

remove repetitive words (#9671)

Signed-off-by: hishope <csqiye@126.com>
pull/9737/head
John 9 months ago committed by GitHub
parent
commit
ec5d34dac0
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
  1. 2
      docs/adrs/agent-join-token.md
  2. 2
      docs/release/expanded/setup_k3s_repos.md
  3. 2
      docs/release/expanded/setup_k8s_repos.md
  4. 2
      docs/release/expanded/setup_rc.md
  5. 2
      docs/release/expanded/update_kdm.md
  6. 2
      scripts/hardened/hardened-k3s-netpol.yaml

2
docs/adrs/agent-join-token.md

@ -50,7 +50,7 @@ documentation can be referenced for more information.
* K3s will allow joining agents to the cluster using bootstrap token secrets. * K3s will allow joining agents to the cluster using bootstrap token secrets.
* K3s will NOT allow joining servers to the cluster using bootstrap token secrets. * K3s will NOT allow joining servers to the cluster using bootstrap token secrets.
* K3s will include a `k3s token` subcommand that allows for token create/list/delete operations, similar to * K3s will include a `k3s token` subcommand that allows for token create/list/delete operations, similar to
the the functionality offered by `kubeadm`. the functionality offered by `kubeadm`.
* K3s will enable the `tokencleaner` controller, in order to ensure that bootstrap token secrets are cleaned * K3s will enable the `tokencleaner` controller, in order to ensure that bootstrap token secrets are cleaned
up when their TTL expires. up when their TTL expires.
* K3s agent bootstrap functionality will allow a agent to connect the cluster using existing [Node * K3s agent bootstrap functionality will allow a agent to connect the cluster using existing [Node

2
docs/release/expanded/setup_k3s_repos.md

@ -7,6 +7,6 @@
1. if you already have a fork, sync it 1. if you already have a fork, sync it
1. add your fork repo as "origin" 1. add your fork repo as "origin"
1. fetch all objects from both repos into your local copy 1. fetch all objects from both repos into your local copy
1. it is important to follow these steps because Go is very particular about the file structure (it uses the the file structure to infer the urls it will pull dependencies from) 1. it is important to follow these steps because Go is very particular about the file structure (it uses the file structure to infer the urls it will pull dependencies from)
1. this is why it is important that the repo is in the github.com/k3s-io directory, and that the repo's directory is "k3s" matching the upstream copy's name 1. this is why it is important that the repo is in the github.com/k3s-io directory, and that the repo's directory is "k3s" matching the upstream copy's name
`$HOME/go/src/github.com/k3s-io/k3s` `$HOME/go/src/github.com/k3s-io/k3s`

2
docs/release/expanded/setup_k8s_repos.md

@ -5,5 +5,5 @@
1. clone kubernetes/kubernetes repo into that directory as "upstream" 1. clone kubernetes/kubernetes repo into that directory as "upstream"
1. add k3s-io/kubernetes repo as "k3s-io" 1. add k3s-io/kubernetes repo as "k3s-io"
1. fetch all objects from both repos into your local copy 1. fetch all objects from both repos into your local copy
1. it is important to follow these steps because Go is very particular about the file structure (it uses the the file structure to infer the urls it will pull dependencies from) 1. it is important to follow these steps because Go is very particular about the file structure (it uses the file structure to infer the urls it will pull dependencies from)
1. this is why it is important that the repo is in the github.com/kubernetes directory, and that the repo's directory is "kubernetes" matching the upstream copy's name `$HOME/go/src/github.com/kubernetes/kubernetes` 1. this is why it is important that the repo is in the github.com/kubernetes directory, and that the repo's directory is "kubernetes" matching the upstream copy's name `$HOME/go/src/github.com/kubernetes/kubernetes`

2
docs/release/expanded/setup_rc.md

@ -13,7 +13,7 @@ This guide helps you navigate the creation of those variables.
1. set NEW_K8S_CLIENT to the client version which corresponds with the newly released k8s version 1. set NEW_K8S_CLIENT to the client version which corresponds with the newly released k8s version
1. set OLD_K3S_VER to the previous k3s version (the one which corresponds to the previous k8s version), replacing the plus symbol with a dash (eg. for "v1.25.0+k3s1" use "v1.25.0-k3s1") 1. set OLD_K3S_VER to the previous k3s version (the one which corresponds to the previous k8s version), replacing the plus symbol with a dash (eg. for "v1.25.0+k3s1" use "v1.25.0-k3s1")
1. set NEW_K3S_VER to the k3s version which corresponds to the newly released k8s version, replacing the plus symbol with a dash 1. set NEW_K3S_VER to the k3s version which corresponds to the newly released k8s version, replacing the plus symbol with a dash
1. set RELEASE_BRANCH to the the k3s release branch which corresponds to the newly released k8s version 1. set RELEASE_BRANCH to the k3s release branch which corresponds to the newly released k8s version
1. set GOPATH to the path to the "go" directory (usually $HOME/go) 1. set GOPATH to the path to the "go" directory (usually $HOME/go)
1. set GOVERSION to the version of go which the newly released k8s version uses 1. set GOVERSION to the version of go which the newly released k8s version uses
1. you can find this in the kubernetes/kubernetes repo 1. you can find this in the kubernetes/kubernetes repo

2
docs/release/expanded/update_kdm.md

@ -8,7 +8,7 @@ After the RCs are cut you need to generate the KDM PR within a few hours
1. clear out (remove) kontainer-driver-metadata repo if is already there (just makes things smoother with a new clone) 1. clear out (remove) kontainer-driver-metadata repo if is already there (just makes things smoother with a new clone)
1. fork kdm repo 1. fork kdm repo
1. clone your fork into that directory as "origin" (you won't need a local copy of upstream) 1. clone your fork into that directory as "origin" (you won't need a local copy of upstream)
1. it is important to follow these steps because Go is very particular about the file structure (it uses the the file structure to infer the urls it will pull dependencies from) 1. it is important to follow these steps because Go is very particular about the file structure (it uses the file structure to infer the urls it will pull dependencies from)
1. go generate needs to be able to fully use Go as expected, so it is important to get the file structure correct 1. go generate needs to be able to fully use Go as expected, so it is important to get the file structure correct
1. this is why it is important that the repo is in the github.com/rancher directory, and that the repo's directory is "kontainer-driver-metadata" matching the upstream copy's name 1. this is why it is important that the repo is in the github.com/rancher directory, and that the repo's directory is "kontainer-driver-metadata" matching the upstream copy's name
1. $HOME/go/src/github.com/rancher/kontainer-driver-metadata 1. $HOME/go/src/github.com/rancher/kontainer-driver-metadata

2
scripts/hardened/hardened-k3s-netpol.yaml

@ -81,7 +81,7 @@ spec:
policyTypes: policyTypes:
- Ingress - Ingress
--- ---
# Allow all access to the the servicelb traefik HTTP/HTTPS ports # Allow all access to the servicelb traefik HTTP/HTTPS ports
apiVersion: networking.k8s.io/v1 apiVersion: networking.k8s.io/v1
kind: NetworkPolicy kind: NetworkPolicy
metadata: metadata:

Loading…
Cancel
Save