From 8203383c037b4d8bdc9eeca0f736ecaa6be3cd4b Mon Sep 17 00:00:00 2001 From: Spencer Smith Date: Fri, 16 Jun 2017 13:25:46 -0400 Subject: [PATCH] rename almost all mentions of kargo --- .github/ISSUE_TEMPLATE.md | 2 +- README.md | 10 +++--- RELEASE.md | 18 +++++------ ...nventory.py => kubespray-aws-inventory.py} | 4 +-- contrib/azurerm/README.md | 8 ++--- contrib/network-storage/glusterfs/README.md | 14 ++++---- contrib/terraform/aws/README.md | 4 +-- .../terraform/aws/create-infrastructure.tf | 2 +- .../docs/{aws_kargo.png => aws_kubespray.png} | Bin docs/ansible.md | 10 +++--- docs/aws.md | 8 ++--- docs/calico.md | 6 ++-- docs/comparisons.md | 12 +++---- docs/dns-stack.md | 16 +++++----- docs/downloads.md | 2 +- ...-calico-rr.png => kubespray-calico-rr.png} | Bin docs/getting-started.md | 6 ++-- docs/ha-mode.md | 6 ++-- docs/netcheck.md | 4 +-- docs/roadmap.md | 30 +++++++++--------- docs/upgrades.md | 8 ++--- docs/vars.md | 16 +++++----- docs/vault.md | 2 +- extra_playbooks/upgrade-only-k8s.yml | 12 +++---- roles/dnsmasq/templates/dnsmasq-deploy.yml | 2 +- roles/kargo-defaults/tasks/main.yaml | 5 --- .../manifests/kube-apiserver.manifest.j2 | 2 +- .../preinstall/tasks/dhclient-hooks-undo.yml | 6 ++-- .../defaults/main.yaml | 0 roles/kubespray-defaults/tasks/main.yaml | 5 +++ 30 files changed, 110 insertions(+), 110 deletions(-) rename contrib/aws_inventory/{kargo-aws-inventory.py => kubespray-aws-inventory.py} (96%) rename contrib/terraform/aws/docs/{aws_kargo.png => aws_kubespray.png} (100%) rename docs/figures/{kargo-calico-rr.png => kubespray-calico-rr.png} (100%) delete mode 100644 roles/kargo-defaults/tasks/main.yaml rename roles/{kargo-defaults => kubespray-defaults}/defaults/main.yaml (100%) create mode 100644 roles/kubespray-defaults/tasks/main.yaml diff --git a/.github/ISSUE_TEMPLATE.md b/.github/ISSUE_TEMPLATE.md index b82daadde..0f81faeac 100644 --- a/.github/ISSUE_TEMPLATE.md +++ b/.github/ISSUE_TEMPLATE.md @@ -24,7 +24,7 @@ explain why. - **Version of Ansible** (`ansible --version`): -**Kargo version (commit) (`git rev-parse --short HEAD`):** +**Kubespray version (commit) (`git rev-parse --short HEAD`):** **Network plugin used**: diff --git a/README.md b/README.md index aa1360a77..50f6e3977 100644 --- a/README.md +++ b/README.md @@ -14,12 +14,12 @@ If you have questions, join us on the [kubernetes slack](https://slack.k8s.io), To deploy the cluster you can use : [**kargo-cli**](https://github.com/kubespray/kargo-cli)
-**Ansible** usual commands and [**inventory builder**](https://github.com/kubernetes-incubator/kargo/blob/master/contrib/inventory_builder/inventory.py)
+**Ansible** usual commands and [**inventory builder**](https://github.com/kubernetes-incubator/kubespray/blob/master/contrib/inventory_builder/inventory.py)
**vagrant** by simply running `vagrant up` (for tests purposes)
* [Requirements](#requirements) -* [Kargo vs ...](docs/comparisons.md) +* [Kubespray vs ...](docs/comparisons.md) * [Getting started](docs/getting-started.md) * [Ansible inventory and tags](docs/ansible.md) * [Deployment data variables](docs/vars.md) @@ -100,13 +100,13 @@ See also [Network checker](docs/netcheck.md). - [kubernetes.io/docs/getting-started-guides/kargo/](https://kubernetes.io/docs/getting-started-guides/kargo/) - [kargo, monitoring and logging](https://github.com/gregbkr/kubernetes-kargo-logging-monitoring) by @gregbkr - [Deploy Kubernetes w/ Ansible & Terraform](https://rsmitty.github.io/Terraform-Ansible-Kubernetes/) by @rsmitty - - [Deploy a Kubernets Cluster with Kargo (video)](https://www.youtube.com/watch?v=N9q51JgbWu8) + - [Deploy a Kubernetes Cluster with Kargo (video)](https://www.youtube.com/watch?v=N9q51JgbWu8) -## Tools and projects on top of Kargo +## Tools and projects on top of Kubespray - [Digital Rebar](https://github.com/digitalrebar/digitalrebar) - [Kargo-cli](https://github.com/kubespray/kargo-cli) - [Fuel-ccp-installer](https://github.com/openstack/fuel-ccp-installer) - - [Terraform Contrib](https://github.com/kubernetes-incubator/kargo/tree/master/contrib/terraform) + - [Terraform Contrib](https://github.com/kubernetes-incubator/kubespray/tree/master/contrib/terraform) ## CI Tests diff --git a/RELEASE.md b/RELEASE.md index 56f0b2e0f..0679667a1 100644 --- a/RELEASE.md +++ b/RELEASE.md @@ -1,16 +1,16 @@ # Release Process -The Kargo Project is released on an as-needed basis. The process is as follows: +The Kubespray Project is released on an as-needed basis. The process is as follows: 1. An issue is proposing a new release with a changelog since the last release 2. At least on of the [OWNERS](OWNERS) must LGTM this release 3. An OWNER runs `git tag -s $VERSION` and inserts the changelog and pushes the tag with `git push $VERSION` 4. The release issue is closed -5. An announcement email is sent to `kubernetes-dev@googlegroups.com` with the subject `[ANNOUNCE] kargo $VERSION is released` +5. An announcement email is sent to `kubernetes-dev@googlegroups.com` with the subject `[ANNOUNCE] Kubespray $VERSION is released` ## Major/minor releases, merge freezes and milestones -* Kargo does not maintain stable branches for releases. Releases are tags, not +* Kubespray does not maintain stable branches for releases. Releases are tags, not branches, and there are no backports. Therefore, there is no need for merge freezes as well. @@ -20,21 +20,21 @@ The Kargo Project is released on an as-needed basis. The process is as follows: support lifetime, which ends once the milestone closed. Then only a next major or minor release can be done. -* Kargo major and minor releases are bound to the given ``kube_version`` major/minor +* Kubespray major and minor releases are bound to the given ``kube_version`` major/minor version numbers and other components' arbitrary versions, like etcd or network plugins. Older or newer versions are not supported and not tested for the given release. -* There is no unstable releases and no APIs, thus Kargo doesn't follow +* There is no unstable releases and no APIs, thus Kubespray doesn't follow [semver](http://semver.org/). Every version describes only a stable release. Breaking changes, if any introduced by changed defaults or non-contrib ansible roles' playbooks, shall be described in the release notes. Other breaking changes, if any in the contributed addons or bound versions of Kubernetes and other components, are - considered out of Kargo scope and are up to the components' teams to deal with and + considered out of Kubespray scope and are up to the components' teams to deal with and document. * Minor releases can change components' versions, but not the major ``kube_version``. - Greater ``kube_version`` requires a new major or minor release. For example, if Kargo v2.0.0 + Greater ``kube_version`` requires a new major or minor release. For example, if Kubespray v2.0.0 is bound to ``kube_version: 1.4.x``, ``calico_version: 0.22.0``, ``etcd_version: v3.0.6``, - then Kargo v2.1.0 may be bound to only minor changes to ``kube_version``, like v1.5.1 + then Kubespray v2.1.0 may be bound to only minor changes to ``kube_version``, like v1.5.1 and *any* changes to other components, like etcd v4, or calico 1.2.3. - And Kargo v3.x.x shall be bound to ``kube_version: 2.x.x`` respectively. + And Kubespray v3.x.x shall be bound to ``kube_version: 2.x.x`` respectively. diff --git a/contrib/aws_inventory/kargo-aws-inventory.py b/contrib/aws_inventory/kubespray-aws-inventory.py similarity index 96% rename from contrib/aws_inventory/kargo-aws-inventory.py rename to contrib/aws_inventory/kubespray-aws-inventory.py index d379be349..65741bbda 100755 --- a/contrib/aws_inventory/kargo-aws-inventory.py +++ b/contrib/aws_inventory/kubespray-aws-inventory.py @@ -33,10 +33,10 @@ class SearchEC2Tags(object): hosts = {} hosts['_meta'] = { 'hostvars': {} } - ##Search ec2 three times to find nodes of each group type. Relies on kargo-role key/value. + ##Search ec2 three times to find nodes of each group type. Relies on kubespray-role key/value. for group in ["kube-master", "kube-node", "etcd"]: hosts[group] = [] - tag_key = "kargo-role" + tag_key = "kubespray-role" tag_value = ["*"+group+"*"] region = os.environ['REGION'] diff --git a/contrib/azurerm/README.md b/contrib/azurerm/README.md index d8cd28e7f..ac2548c85 100644 --- a/contrib/azurerm/README.md +++ b/contrib/azurerm/README.md @@ -5,7 +5,7 @@ Provision the base infrastructure for a Kubernetes cluster by using [Azure Resou ## Status This will provision the base infrastructure (vnet, vms, nics, ips, ...) needed for Kubernetes in Azure into the specified -Resource Group. It will not install Kubernetes itself, this has to be done in a later step by yourself (using kargo of course). +Resource Group. It will not install Kubernetes itself, this has to be done in a later step by yourself (using kubespray of course). ## Requirements @@ -47,7 +47,7 @@ $ ./clear-rg.sh **WARNING** this really deletes everything from your resource group, including everything that was later created by you! -## Generating an inventory for kargo +## Generating an inventory for kubespray After you have applied the templates, you can generate an inventory with this call: @@ -55,10 +55,10 @@ After you have applied the templates, you can generate an inventory with this ca $ ./generate-inventory.sh ``` -It will create the file ./inventory which can then be used with kargo, e.g.: +It will create the file ./inventory which can then be used with kubespray, e.g.: ```shell -$ cd kargo-root-dir +$ cd kubespray-root-dir $ ansible-playbook -i contrib/azurerm/inventory -u devops --become -e "@inventory/group_vars/all.yml" cluster.yml ``` diff --git a/contrib/network-storage/glusterfs/README.md b/contrib/network-storage/glusterfs/README.md index d09c10c7f..d7aea26aa 100644 --- a/contrib/network-storage/glusterfs/README.md +++ b/contrib/network-storage/glusterfs/README.md @@ -1,4 +1,4 @@ -# Deploying a Kargo Kubernetes Cluster with GlusterFS +# Deploying a Kubespray Kubernetes Cluster with GlusterFS You can either deploy using Ansible on its own by supplying your own inventory file or by using Terraform to create the VMs and then providing a dynamic inventory to Ansible. The following two sections are self-contained, you don't need to go through one to use the other. So, if you want to provision with Terraform, you can skip the **Using an Ansible inventory** section, and if you want to provision with a pre-built ansible inventory, you can neglect the **Using Terraform and Ansible** section. @@ -6,7 +6,7 @@ You can either deploy using Ansible on its own by supplying your own inventory f In the same directory of this ReadMe file you should find a file named `inventory.example` which contains an example setup. Please note that, additionally to the Kubernetes nodes/masters, we define a set of machines for GlusterFS and we add them to the group `[gfs-cluster]`, which in turn is added to the larger `[network-storage]` group as a child group. -Change that file to reflect your local setup (adding more machines or removing them and setting the adequate ip numbers), and save it to `inventory/k8s_gfs_inventory`. Make sure that the settings on `inventory/group_vars/all.yml` make sense with your deployment. Then execute change to the kargo root folder, and execute (supposing that the machines are all using ubuntu): +Change that file to reflect your local setup (adding more machines or removing them and setting the adequate ip numbers), and save it to `inventory/k8s_gfs_inventory`. Make sure that the settings on `inventory/group_vars/all.yml` make sense with your deployment. Then execute change to the kubespray root folder, and execute (supposing that the machines are all using ubuntu): ``` ansible-playbook -b --become-user=root -i inventory/k8s_gfs_inventory --user=ubuntu ./cluster.yml @@ -28,7 +28,7 @@ k8s-master-node-2 ansible_ssh_host=192.168.0.146 ip=192.168.0.146 ansible_ssh_us ## Using Terraform and Ansible -First step is to fill in a `my-kargo-gluster-cluster.tfvars` file with the specification desired for your cluster. An example with all required variables would look like: +First step is to fill in a `my-kubespray-gluster-cluster.tfvars` file with the specification desired for your cluster. An example with all required variables would look like: ``` cluster_name = "cluster1" @@ -65,15 +65,15 @@ $ echo Setting up Terraform creds && \ export TF_VAR_auth_url=${OS_AUTH_URL} ``` -Then, standing on the kargo directory (root base of the Git checkout), issue the following terraform command to create the VMs for the cluster: +Then, standing on the kubespray directory (root base of the Git checkout), issue the following terraform command to create the VMs for the cluster: ``` -terraform apply -state=contrib/terraform/openstack/terraform.tfstate -var-file=my-kargo-gluster-cluster.tfvars contrib/terraform/openstack +terraform apply -state=contrib/terraform/openstack/terraform.tfstate -var-file=my-kubespray-gluster-cluster.tfvars contrib/terraform/openstack ``` This will create both your Kubernetes and Gluster VMs. Make sure that the ansible file `contrib/terraform/openstack/group_vars/all.yml` includes any ansible variable that you want to setup (like, for instance, the type of machine for bootstrapping). -Then, provision your Kubernetes (Kargo) cluster with the following ansible call: +Then, provision your Kubernetes (kubespray) cluster with the following ansible call: ``` ansible-playbook -b --become-user=root -i contrib/terraform/openstack/hosts ./cluster.yml @@ -88,5 +88,5 @@ ansible-playbook -b --become-user=root -i contrib/terraform/openstack/hosts ./co If you need to destroy the cluster, you can run: ``` -terraform destroy -state=contrib/terraform/openstack/terraform.tfstate -var-file=my-kargo-gluster-cluster.tfvars contrib/terraform/openstack +terraform destroy -state=contrib/terraform/openstack/terraform.tfstate -var-file=my-kubespray-gluster-cluster.tfvars contrib/terraform/openstack ``` diff --git a/contrib/terraform/aws/README.md b/contrib/terraform/aws/README.md index de858b2a9..451fc58a7 100644 --- a/contrib/terraform/aws/README.md +++ b/contrib/terraform/aws/README.md @@ -33,7 +33,7 @@ export AWS_DEFAULT_REGION="zzz" - Terraform automatically creates an Ansible Inventory file called `hosts` with the created infrastructure in the directory `inventory` -- Once the infrastructure is created, you can run the kargo playbooks and supply inventory/hosts with the `-i` flag. +- Once the infrastructure is created, you can run the kubespray playbooks and supply inventory/hosts with the `-i` flag. **Troubleshooting** @@ -54,4 +54,4 @@ It could happen that Terraform doesnt create an Ansible Inventory file automatic Pictured is an AWS Infrastructure created with this Terraform project distributed over two Availability Zones. -![AWS Infrastructure with Terraform ](docs/aws_kargo.png) +![AWS Infrastructure with Terraform ](docs/aws_kubespray.png) diff --git a/contrib/terraform/aws/create-infrastructure.tf b/contrib/terraform/aws/create-infrastructure.tf index 781edea86..a58bca53c 100644 --- a/contrib/terraform/aws/create-infrastructure.tf +++ b/contrib/terraform/aws/create-infrastructure.tf @@ -157,7 +157,7 @@ resource "aws_instance" "k8s-worker" { /* -* Create Kargo Inventory File +* Create Kubespray Inventory File * */ data "template_file" "inventory" { diff --git a/contrib/terraform/aws/docs/aws_kargo.png b/contrib/terraform/aws/docs/aws_kubespray.png similarity index 100% rename from contrib/terraform/aws/docs/aws_kargo.png rename to contrib/terraform/aws/docs/aws_kubespray.png diff --git a/docs/ansible.md b/docs/ansible.md index 4da6edb48..a9e38bf53 100644 --- a/docs/ansible.md +++ b/docs/ansible.md @@ -75,25 +75,25 @@ According to the [ansible docs](http://docs.ansible.com/ansible/playbooks_variab those cannot be overriden from the group vars. In order to override, one should use the `-e ` runtime flags (most simple way) or other layers described in the docs. -Kargo uses only a few layers to override things (or expect them to +Kubespray uses only a few layers to override things (or expect them to be overriden for roles): Layer | Comment ------|-------- -**role defaults** | provides best UX to override things for Kargo deployments +**role defaults** | provides best UX to override things for Kubespray deployments inventory vars | Unused **inventory group_vars** | Expects users to use ``all.yml``,``k8s-cluster.yml`` etc. to override things inventory host_vars | Unused playbook group_vars | Unuses playbook host_vars | Unused -**host facts** | Kargo overrides for internal roles' logic, like state flags +**host facts** | Kubespray overrides for internal roles' logic, like state flags play vars | Unused play vars_prompt | Unused play vars_files | Unused registered vars | Unused -set_facts | Kargo overrides those, for some places +set_facts | Kubespray overrides those, for some places **role and include vars** | Provides bad UX to override things! Use extra vars to enforce -block vars (only for tasks in block) | Kargo overrides for internal roles' logic +block vars (only for tasks in block) | Kubespray overrides for internal roles' logic task vars (only for the task) | Unused for roles, but only for helper scripts **extra vars** (always win precedence) | override with ``ansible-playbook -e @foo.yml`` diff --git a/docs/aws.md b/docs/aws.md index 91bded11c..8bdbc06fa 100644 --- a/docs/aws.md +++ b/docs/aws.md @@ -3,7 +3,7 @@ AWS To deploy kubespray on [AWS](https://aws.amazon.com/) uncomment the `cloud_provider` option in `group_vars/all.yml` and set it to `'aws'`. -Prior to creating your instances, you **must** ensure that you have created IAM roles and policies for both "kubernetes-master" and "kubernetes-node". You can find the IAM policies [here](https://github.com/kubernetes-incubator/kargo/tree/master/contrib/aws_iam/). See the [IAM Documentation](https://aws.amazon.com/documentation/iam/) if guidance is needed on how to set these up. When you bring your instances online, associate them with the respective IAM role. Nodes that are only to be used for Etcd do not need a role. +Prior to creating your instances, you **must** ensure that you have created IAM roles and policies for both "kubernetes-master" and "kubernetes-node". You can find the IAM policies [here](https://github.com/kubernetes-incubator/kubespray/tree/master/contrib/aws_iam/). See the [IAM Documentation](https://aws.amazon.com/documentation/iam/) if guidance is needed on how to set these up. When you bring your instances online, associate them with the respective IAM role. Nodes that are only to be used for Etcd do not need a role. The next step is to make sure the hostnames in your `inventory` file are identical to your internal hostnames in AWS. This may look something like `ip-111-222-333-444.us-west-2.compute.internal`. You can then specify how Ansible connects to these instances with `ansible_ssh_host` and `ansible_ssh_user`. @@ -45,12 +45,12 @@ This will produce an inventory that is passed into Ansible that looks like the f Guide: - Create instances in AWS as needed. -- Either during or after creation, add tags to the instances with a key of `kargo-role` and a value of `kube-master`, `etcd`, or `kube-node`. You can also share roles like `kube-master, etcd` -- Copy the `kargo-aws-inventory.py` script from `kargo/contrib/aws_inventory` to the `kargo/inventory` directory. +- Either during or after creation, add tags to the instances with a key of `kubespray-role` and a value of `kube-master`, `etcd`, or `kube-node`. You can also share roles like `kube-master, etcd` +- Copy the `kubespray-aws-inventory.py` script from `kubespray/contrib/aws_inventory` to the `kubespray/inventory` directory. - Set the following AWS credentials and info as environment variables in your terminal: ``` export AWS_ACCESS_KEY_ID="xxxxx" export AWS_SECRET_ACCESS_KEY="yyyyy" export REGION="us-east-2" ``` -- We will now create our cluster. There will be either one or two small changes. The first is that we will specify `-i inventory/kargo-aws-inventory.py` as our inventory script. The other is conditional. If your AWS instances are public facing, you can set the `VPC_VISIBILITY` variable to `public` and that will result in public IP and DNS names being passed into the inventory. This causes your cluster.yml command to look like `VPC_VISIBILITY="public" ansible-playbook ... cluster.yml` +- We will now create our cluster. There will be either one or two small changes. The first is that we will specify `-i inventory/kubespray-aws-inventory.py` as our inventory script. The other is conditional. If your AWS instances are public facing, you can set the `VPC_VISIBILITY` variable to `public` and that will result in public IP and DNS names being passed into the inventory. This causes your cluster.yml command to look like `VPC_VISIBILITY="public" ansible-playbook ... cluster.yml` diff --git a/docs/calico.md b/docs/calico.md index eefbcb6e2..00ff748c1 100644 --- a/docs/calico.md +++ b/docs/calico.md @@ -96,7 +96,7 @@ You need to edit your inventory and add: * `cluster_id` by route reflector node/group (see details [here](https://hub.docker.com/r/calico/routereflector/)) -Here's an example of Kargo inventory with route reflectors: +Here's an example of Kubespray inventory with route reflectors: ``` [all] @@ -145,11 +145,11 @@ cluster_id="1.0.0.1" The inventory above will deploy the following topology assuming that calico's `global_as_num` is set to `65400`: -![Image](figures/kargo-calico-rr.png?raw=true) +![Image](figures/kubespray-calico-rr.png?raw=true) ##### Optional : Define default endpoint to host action -By default Calico blocks traffic from endpoints to the host itself by using an iptables DROP action. When using it in kubernetes the action has to be changed to RETURN (default in kargo) or ACCEPT (see https://github.com/projectcalico/felix/issues/660 and https://github.com/projectcalico/calicoctl/issues/1389). Otherwise all network packets from pods (with hostNetwork=False) to services endpoints (with hostNetwork=True) withing the same node are dropped. +By default Calico blocks traffic from endpoints to the host itself by using an iptables DROP action. When using it in kubernetes the action has to be changed to RETURN (default in kubespray) or ACCEPT (see https://github.com/projectcalico/felix/issues/660 and https://github.com/projectcalico/calicoctl/issues/1389). Otherwise all network packets from pods (with hostNetwork=False) to services endpoints (with hostNetwork=True) withing the same node are dropped. To re-define default action please set the following variable in your inventory: diff --git a/docs/comparisons.md b/docs/comparisons.md index 63cb60102..cf34e37d5 100644 --- a/docs/comparisons.md +++ b/docs/comparisons.md @@ -1,25 +1,25 @@ -Kargo vs [Kops](https://github.com/kubernetes/kops) +Kubespray vs [Kops](https://github.com/kubernetes/kops) --------------- -Kargo runs on bare metal and most clouds, using Ansible as its substrate for +Kubespray runs on bare metal and most clouds, using Ansible as its substrate for provisioning and orchestration. Kops performs the provisioning and orchestration itself, and as such is less flexible in deployment platforms. For people with familiarity with Ansible, existing Ansible deployments or the desire to run a -Kubernetes cluster across multiple platforms, Kargo is a good choice. Kops, +Kubernetes cluster across multiple platforms, Kubespray is a good choice. Kops, however, is more tightly integrated with the unique features of the clouds it supports so it could be a better choice if you know that you will only be using one platform for the foreseeable future. -Kargo vs [Kubeadm](https://github.com/kubernetes/kubeadm) +Kubespray vs [Kubeadm](https://github.com/kubernetes/kubeadm) ------------------ Kubeadm provides domain Knowledge of Kubernetes clusters' life cycle management, including self-hosted layouts, dynamic discovery services and so on. Had it belong to the new [operators world](https://coreos.com/blog/introducing-operators.html), -it would've likely been named a "Kubernetes cluster operator". Kargo however, +it would've likely been named a "Kubernetes cluster operator". Kubespray however, does generic configuration management tasks from the "OS operators" ansible world, plus some initial K8s clustering (with networking plugins included) and -control plane bootstrapping. Kargo [strives](https://github.com/kubernetes-incubator/kargo/issues/553) +control plane bootstrapping. Kubespray [strives](https://github.com/kubernetes-incubator/kubespray/issues/553) to adopt kubeadm as a tool in order to consume life cycle management domain knowledge from it and offload generic OS configuration things from it, which hopefully benefits both sides. diff --git a/docs/dns-stack.md b/docs/dns-stack.md index 67afb6b43..f4de31544 100644 --- a/docs/dns-stack.md +++ b/docs/dns-stack.md @@ -1,7 +1,7 @@ -K8s DNS stack by Kargo +K8s DNS stack by Kubespray ====================== -For K8s cluster nodes, kargo configures a [Kubernetes DNS](http://kubernetes.io/docs/admin/dns/) +For K8s cluster nodes, Kubespray configures a [Kubernetes DNS](http://kubernetes.io/docs/admin/dns/) [cluster add-on](http://releases.k8s.io/master/cluster/addons/README.md) to serve as an authoritative DNS server for a given ``dns_domain`` and its ``svc, default.svc`` default subdomains (a total of ``ndots: 5`` max levels). @@ -44,13 +44,13 @@ DNS servers to be added *after* the cluster DNS. Used by all ``resolvconf_mode`` DNS servers in early cluster deployment when no cluster DNS is available yet. These are also added as upstream DNS servers used by ``dnsmasq`` (when deployed with ``dns_mode: dnsmasq_kubedns``). -DNS modes supported by kargo +DNS modes supported by Kubespray ============================ -You can modify how kargo sets up DNS for your cluster with the variables ``dns_mode`` and ``resolvconf_mode``. +You can modify how Kubespray sets up DNS for your cluster with the variables ``dns_mode`` and ``resolvconf_mode``. ## dns_mode -``dns_mode`` configures how kargo will setup cluster DNS. There are three modes available: +``dns_mode`` configures how Kubespray will setup cluster DNS. There are three modes available: #### dnsmasq_kubedns (default) This installs an additional dnsmasq DaemonSet which gives more flexibility and lifts some @@ -67,7 +67,7 @@ This does not install any of dnsmasq and kubedns/skydns. This basically disables leaves you with a non functional cluster. ## resolvconf_mode -``resolvconf_mode`` configures how kargo will setup DNS for ``hostNetwork: true`` PODs and non-k8s containers. +``resolvconf_mode`` configures how Kubespray will setup DNS for ``hostNetwork: true`` PODs and non-k8s containers. There are three modes available: #### docker_dns (default) @@ -100,7 +100,7 @@ used as a backup nameserver. After cluster DNS is running, all queries will be a servers, which in turn will forward queries to the system nameserver if required. #### host_resolvconf -This activates the classic kargo behaviour that modifies the hosts ``/etc/resolv.conf`` file and dhclient +This activates the classic Kubespray behaviour that modifies the hosts ``/etc/resolv.conf`` file and dhclient configuration to point to the cluster dns server (either dnsmasq or kubedns, depending on dns_mode). As cluster DNS is not available on early deployment stage, this mode is split into 2 stages. In the first @@ -120,7 +120,7 @@ cluster service names. Limitations ----------- -* Kargo has yet ways to configure Kubedns addon to forward requests SkyDns can +* Kubespray has yet ways to configure Kubedns addon to forward requests SkyDns can not answer with authority to arbitrary recursive resolvers. This task is left for future. See [official SkyDns docs](https://github.com/skynetservices/skydns) for details. diff --git a/docs/downloads.md b/docs/downloads.md index 2c3f3085f..50d9ef107 100644 --- a/docs/downloads.md +++ b/docs/downloads.md @@ -1,7 +1,7 @@ Downloading binaries and containers =================================== -Kargo supports several download/upload modes. The default is: +Kubespray supports several download/upload modes. The default is: * Each node downloads binaries and container images on its own, which is ``download_run_once: False``. diff --git a/docs/figures/kargo-calico-rr.png b/docs/figures/kubespray-calico-rr.png similarity index 100% rename from docs/figures/kargo-calico-rr.png rename to docs/figures/kubespray-calico-rr.png diff --git a/docs/getting-started.md b/docs/getting-started.md index 6e323d9cd..167dcaea2 100644 --- a/docs/getting-started.md +++ b/docs/getting-started.md @@ -23,12 +23,12 @@ Building your own inventory Ansible inventory can be stored in 3 formats: YAML, JSON, or INI-like. There is an example inventory located -[here](https://github.com/kubernetes-incubator/kargo/blob/master/inventory/inventory.example). +[here](https://github.com/kubernetes-incubator/kubespray/blob/master/inventory/inventory.example). You can use an -[inventory generator](https://github.com/kubernetes-incubator/kargo/blob/master/contrib/inventory_builder/inventory.py) +[inventory generator](https://github.com/kubernetes-incubator/kubespray/blob/master/contrib/inventory_builder/inventory.py) to create or modify an Ansible inventory. Currently, it is limited in -functionality and is only use for making a basic Kargo cluster, but it does +functionality and is only use for making a basic Kubespray cluster, but it does support creating large clusters. It now supports separated ETCD and Kubernetes master roles from node role if the size exceeds a certain threshold. Run inventory.py help for more information. diff --git a/docs/ha-mode.md b/docs/ha-mode.md index 20578f705..5036345b7 100644 --- a/docs/ha-mode.md +++ b/docs/ha-mode.md @@ -22,7 +22,7 @@ Kube-apiserver -------------- K8s components require a loadbalancer to access the apiservers via a reverse -proxy. Kargo includes support for an nginx-based proxy that resides on each +proxy. Kubespray includes support for an nginx-based proxy that resides on each non-master Kubernetes node. This is referred to as localhost loadbalancing. It is less efficient than a dedicated load balancer because it creates extra health checks on the Kubernetes apiserver, but is more practical for scenarios @@ -30,12 +30,12 @@ where an external LB or virtual IP management is inconvenient. This option is configured by the variable `loadbalancer_apiserver_localhost` (defaults to `True`). You may also define the port the local internal loadbalancer users by changing, `nginx_kube_apiserver_port`. This defaults to the value of `kube_apiserver_port`. -It is also import to note that Kargo will only configure kubelet and kube-proxy +It is also import to note that Kubespray will only configure kubelet and kube-proxy on non-master nodes to use the local internal loadbalancer. If you choose to NOT use the local internal loadbalancer, you will need to configure your own loadbalancer to achieve HA. Note that deploying a loadbalancer is up to -a user and is not covered by ansible roles in Kargo. By default, it only configures +a user and is not covered by ansible roles in Kubespray. By default, it only configures a non-HA endpoint, which points to the `access_ip` or IP address of the first server node in the `kube-master` group. It can also configure clients to use endpoints for a given loadbalancer type. The following diagram shows how traffic to the diff --git a/docs/netcheck.md b/docs/netcheck.md index bee04cbb3..80679cd73 100644 --- a/docs/netcheck.md +++ b/docs/netcheck.md @@ -1,7 +1,7 @@ Network Checker Application =========================== -With the ``deploy_netchecker`` var enabled (defaults to false), Kargo deploys a +With the ``deploy_netchecker`` var enabled (defaults to false), Kubespray deploys a Network Checker Application from the 3rd side `l23network/k8s-netchecker` docker images. It consists of the server and agents trying to reach the server by usual for Kubernetes applications network connectivity meanings. Therefore, this @@ -17,7 +17,7 @@ any of the cluster nodes: ``` curl http://localhost:31081/api/v1/connectivity_check ``` -Note that Kargo does not invoke the check but only deploys the application, if +Note that Kubespray does not invoke the check but only deploys the application, if requested. There are related application specifc variables: diff --git a/docs/roadmap.md b/docs/roadmap.md index c0a3a7527..fb038ae1f 100644 --- a/docs/roadmap.md +++ b/docs/roadmap.md @@ -1,23 +1,23 @@ -Kargo's roadmap +Kubespray's roadmap ================= ### Kubeadm - Propose kubeadm as an option in order to setup the kubernetes cluster. -That would probably improve deployment speed and certs management [#553](https://github.com/kubespray/kargo/issues/553) +That would probably improve deployment speed and certs management [#553](https://github.com/kubespray/kubespray/issues/553) -### Self deployment (pull-mode) [#320](https://github.com/kubespray/kargo/issues/320) +### Self deployment (pull-mode) [#320](https://github.com/kubespray/kubespray/issues/320) - the playbook would install and configure docker/rkt and the etcd cluster - the following data would be inserted into etcd: certs,tokens,users,inventory,group_vars. - a "kubespray" container would be deployed (kargo-cli, ansible-playbook, kpm) - to be discussed, a way to provide the inventory -- **self deployment** of the node from inside a container [#321](https://github.com/kubespray/kargo/issues/321) +- **self deployment** of the node from inside a container [#321](https://github.com/kubespray/kubespray/issues/321) ### Provisionning and cloud providers - [ ] Terraform to provision instances on **GCE, AWS, Openstack, Digital Ocean, Azure** - [ ] On AWS autoscaling, multi AZ -- [ ] On Azure autoscaling, create loadbalancer [#297](https://github.com/kubespray/kargo/issues/297) -- [ ] On GCE be able to create a loadbalancer automatically (IAM ?) [#280](https://github.com/kubespray/kargo/issues/280) -- [x] **TLS boostrap** support for kubelet [#234](https://github.com/kubespray/kargo/issues/234) +- [ ] On Azure autoscaling, create loadbalancer [#297](https://github.com/kubespray/kubespray/issues/297) +- [ ] On GCE be able to create a loadbalancer automatically (IAM ?) [#280](https://github.com/kubespray/kubespray/issues/280) +- [x] **TLS boostrap** support for kubelet [#234](https://github.com/kubespray/kubespray/issues/234) (related issues: https://github.com/kubernetes/kubernetes/pull/20439
https://github.com/kubernetes/kubernetes/issues/18112) @@ -37,14 +37,14 @@ That would probably improve deployment speed and certs management [#553](https:/ - [ ] test scale up cluster: +1 etcd, +1 master, +1 node ### Lifecycle -- [ ] Adopt the kubeadm tool by delegating CM tasks it is capable to accomplish well [#553](https://github.com/kubespray/kargo/issues/553) -- [x] Drain worker node when upgrading k8s components in a worker node. [#154](https://github.com/kubespray/kargo/issues/154) +- [ ] Adopt the kubeadm tool by delegating CM tasks it is capable to accomplish well [#553](https://github.com/kubespray/kubespray/issues/553) +- [x] Drain worker node when upgrading k8s components in a worker node. [#154](https://github.com/kubespray/kubespray/issues/154) - [ ] Drain worker node when shutting down/deleting an instance - [ ] Upgrade granularity: select components to upgrade and skip others ### Networking -- [ ] romana.io support [#160](https://github.com/kubespray/kargo/issues/160) -- [ ] Configure network policy for Calico. [#159](https://github.com/kubespray/kargo/issues/159) +- [ ] romana.io support [#160](https://github.com/kubespray/kubespray/issues/160) +- [ ] Configure network policy for Calico. [#159](https://github.com/kubespray/kubespray/issues/159) - [ ] Opencontrail - [x] Canal - [x] Cloud Provider native networking (instead of our network plugins) @@ -60,7 +60,7 @@ While waiting for the issue [kubernetes/kubernetes#18174](https://github.com/kub - switch to Terraform instead of Ansible for provisionning - update $HOME/.kube/config when a cluster is deployed. Optionally switch to this context -### Kargo API +### Kubespray API - Perform all actions through an **API** - Store inventories / configurations of mulltiple clusters - make sure that state of cluster is completely saved in no more than one config file beyond hosts inventory @@ -87,8 +87,8 @@ Include optionals deployments to init the cluster: ### Others - remove nodes (adding is already supported) - being able to choose any k8s version (almost done) -- **rkt** support [#59](https://github.com/kubespray/kargo/issues/59) +- **rkt** support [#59](https://github.com/kubespray/kubespray/issues/59) - Review documentation (split in categories) - **consul** -> if officialy supported by k8s -- flex volumes options (e.g. **torrus** support) [#312](https://github.com/kubespray/kargo/issues/312) -- Clusters federation option (aka **ubernetes**) [#329](https://github.com/kubespray/kargo/issues/329) +- flex volumes options (e.g. **torrus** support) [#312](https://github.com/kubespray/kubespray/issues/312) +- Clusters federation option (aka **ubernetes**) [#329](https://github.com/kubespray/kubespray/issues/329) diff --git a/docs/upgrades.md b/docs/upgrades.md index cb431d4c0..9a21cbdc4 100644 --- a/docs/upgrades.md +++ b/docs/upgrades.md @@ -1,11 +1,11 @@ -Upgrading Kubernetes in Kargo +Upgrading Kubernetes in Kubespray ============================= #### Description -Kargo handles upgrades the same way it handles initial deployment. That is to +Kubespray handles upgrades the same way it handles initial deployment. That is to say that each component is laid down in a fixed order. You should be able to -upgrade from Kargo tag 2.0 up to the current master without difficulty. You can +upgrade from Kubespray tag 2.0 up to the current master without difficulty. You can also individually control versions of components by explicitly defining their versions. Here are all version vars for each component: @@ -35,7 +35,7 @@ ansible-playbook cluster.yml -i inventory/inventory.cfg -e kube_version=v1.4.6 #### Graceful upgrade -Kargo also supports cordon, drain and uncordoning of nodes when performing +Kubespray also supports cordon, drain and uncordoning of nodes when performing a cluster upgrade. There is a separate playbook used for this purpose. It is important to note that upgrade-cluster.yml can only be used for upgrading an existing cluster. That means there must be at least 1 kube-master already diff --git a/docs/vars.md b/docs/vars.md index 603a614b2..4b9da186e 100644 --- a/docs/vars.md +++ b/docs/vars.md @@ -1,4 +1,4 @@ -Configurable Parameters in Kargo +Configurable Parameters in Kubespray ================================ #### Generic Ansible variables @@ -12,7 +12,7 @@ Some variables of note include: * *ansible_default_ipv4.address*: IP address Ansible automatically chooses. Generated based on the output from the command ``ip -4 route get 8.8.8.8`` -#### Common vars that are used in Kargo +#### Common vars that are used in Kubespray * *calico_version* - Specify version of Calico to use * *calico_cni_version* - Specify version of Calico CNI plugin to use @@ -35,16 +35,16 @@ Some variables of note include: * *access_ip* - IP for other hosts to use to connect to. Often required when deploying from a cloud, such as OpenStack or GCE and you have separate public/floating and private IPs. -* *ansible_default_ipv4.address* - Not Kargo-specific, but it is used if ip +* *ansible_default_ipv4.address* - Not Kubespray-specific, but it is used if ip and access_ip are undefined * *loadbalancer_apiserver* - If defined, all hosts will connect to this address instead of localhost for kube-masters and kube-master[0] for kube-nodes. See more details in the - [HA guide](https://github.com/kubernetes-incubator/kargo/blob/master/docs/ha-mode.md). + [HA guide](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/ha-mode.md). * *loadbalancer_apiserver_localhost* - makes all hosts to connect to the apiserver internally load balanced endpoint. Mutual exclusive to the `loadbalancer_apiserver`. See more details in the - [HA guide](https://github.com/kubernetes-incubator/kargo/blob/master/docs/ha-mode.md). + [HA guide](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/ha-mode.md). #### Cluster variables @@ -79,13 +79,13 @@ other settings from your existing /etc/resolv.conf are lost. Set the following variables to match your requirements. * *upstream_dns_servers* - Array of upstream DNS servers configured on host in - addition to Kargo deployed DNS + addition to Kubespray deployed DNS * *nameservers* - Array of DNS servers configured for use in dnsmasq * *searchdomains* - Array of up to 4 search domains * *skip_dnsmasq* - Don't set up dnsmasq (use only KubeDNS) For more information, see [DNS -Stack](https://github.com/kubernetes-incubator/kargo/blob/master/docs/dns-stack.md). +Stack](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/dns-stack.md). #### Other service variables @@ -114,5 +114,5 @@ The possible vars are: #### User accounts -Kargo sets up two Kubernetes accounts by default: ``root`` and ``kube``. Their +Kubespray sets up two Kubernetes accounts by default: ``root`` and ``kube``. Their passwords default to changeme. You can set this by changing ``kube_api_pwd``. diff --git a/docs/vault.md b/docs/vault.md index 446d914c9..3850d04b5 100644 --- a/docs/vault.md +++ b/docs/vault.md @@ -39,7 +39,7 @@ vault group. It is *highly* recommended that these secrets are removed from the servers after your cluster has been deployed, and kept in a safe location of your choosing. Naturally, the seriousness of the situation depends on what you're doing with -your Kargo cluster, but with these secrets, an attacker will have the ability +your Kubespray cluster, but with these secrets, an attacker will have the ability to authenticate to almost everything in Kubernetes and decode all private (HTTPS) traffic on your network signed by Vault certificates. diff --git a/extra_playbooks/upgrade-only-k8s.yml b/extra_playbooks/upgrade-only-k8s.yml index f10259b07..c2af6a301 100644 --- a/extra_playbooks/upgrade-only-k8s.yml +++ b/extra_playbooks/upgrade-only-k8s.yml @@ -11,7 +11,7 @@ - hosts: localhost gather_facts: False roles: - - { role: kargo-defaults} + - { role: kubespray-defaults} - { role: bastion-ssh-config, tags: ["localhost", "bastion"]} - hosts: k8s-cluster:etcd:calico-rr @@ -22,7 +22,7 @@ # fail. bootstrap-os fixes this on these systems, so in later plays it can be enabled. ansible_ssh_pipelining: false roles: - - { role: kargo-defaults} + - { role: kubespray-defaults} - { role: bootstrap-os, tags: bootstrap-os} - hosts: k8s-cluster:etcd:calico-rr @@ -34,7 +34,7 @@ - hosts: k8s-cluster:etcd:calico-rr any_errors_fatal: "{{ any_errors_fatal | default(true) }}" roles: - - { role: kargo-defaults} + - { role: kubespray-defaults} - { role: kubernetes/preinstall, tags: preinstall } #Handle upgrades to master components first to maintain backwards compat. @@ -42,7 +42,7 @@ any_errors_fatal: "{{ any_errors_fatal | default(true) }}" serial: 1 roles: - - { role: kargo-defaults} + - { role: kubespray-defaults} - { role: upgrade/pre-upgrade, tags: pre-upgrade } - { role: kubernetes/node, tags: node } - { role: kubernetes/master, tags: master } @@ -53,8 +53,8 @@ any_errors_fatal: "{{ any_errors_fatal | default(true) }}" serial: "{{ serial | default('20%') }}" roles: - - { role: kargo-defaults} + - { role: kubespray-defaults} - { role: upgrade/pre-upgrade, tags: pre-upgrade } - { role: kubernetes/node, tags: node } - { role: upgrade/post-upgrade, tags: post-upgrade } - - { role: kargo-defaults} + - { role: kubespray-defaults} diff --git a/roles/dnsmasq/templates/dnsmasq-deploy.yml b/roles/dnsmasq/templates/dnsmasq-deploy.yml index ed74c3e06..e811e1995 100644 --- a/roles/dnsmasq/templates/dnsmasq-deploy.yml +++ b/roles/dnsmasq/templates/dnsmasq-deploy.yml @@ -19,7 +19,7 @@ spec: labels: k8s-app: dnsmasq kubernetes.io/cluster-service: "true" - kargo/dnsmasq-checksum: "{{ dnsmasq_stat.stat.checksum }}" + kubespray/dnsmasq-checksum: "{{ dnsmasq_stat.stat.checksum }}" spec: containers: - name: dnsmasq diff --git a/roles/kargo-defaults/tasks/main.yaml b/roles/kargo-defaults/tasks/main.yaml deleted file mode 100644 index 91d0bc463..000000000 --- a/roles/kargo-defaults/tasks/main.yaml +++ /dev/null @@ -1,5 +0,0 @@ -- name: Configure defaults - debug: - msg: "Check roles/kargo-defaults/defaults/main.yml" - tags: - - always diff --git a/roles/kubernetes/master/templates/manifests/kube-apiserver.manifest.j2 b/roles/kubernetes/master/templates/manifests/kube-apiserver.manifest.j2 index 851cca060..1cee58282 100644 --- a/roles/kubernetes/master/templates/manifests/kube-apiserver.manifest.j2 +++ b/roles/kubernetes/master/templates/manifests/kube-apiserver.manifest.j2 @@ -5,7 +5,7 @@ metadata: namespace: {{system_namespace}} labels: k8s-app: kube-apiserver - kargo: v2 + kubespray: v2 spec: hostNetwork: true {% if kube_version | version_compare('v1.6', '>=') %} diff --git a/roles/kubernetes/preinstall/tasks/dhclient-hooks-undo.yml b/roles/kubernetes/preinstall/tasks/dhclient-hooks-undo.yml index 10e5bba68..91fb9c694 100644 --- a/roles/kubernetes/preinstall/tasks/dhclient-hooks-undo.yml +++ b/roles/kubernetes/preinstall/tasks/dhclient-hooks-undo.yml @@ -1,9 +1,9 @@ --- -# These tasks will undo changes done by kargo in the past if needed (e.g. when upgrading from kargo 2.0.x +# These tasks will undo changes done by kubespray in the past if needed (e.g. when upgrading from kubespray 2.0.x # or when changing resolvconf_mode) -- name: Remove kargo specific config from dhclient config +- name: Remove kubespray specific config from dhclient config blockinfile: dest: "{{dhclientconffile}}" state: absent @@ -13,7 +13,7 @@ when: dhclientconffile is defined notify: Preinstall | restart network -- name: Remove kargo specific dhclient hook +- name: Remove kubespray specific dhclient hook file: path: "{{ dhclienthookfile }}" state: absent diff --git a/roles/kargo-defaults/defaults/main.yaml b/roles/kubespray-defaults/defaults/main.yaml similarity index 100% rename from roles/kargo-defaults/defaults/main.yaml rename to roles/kubespray-defaults/defaults/main.yaml diff --git a/roles/kubespray-defaults/tasks/main.yaml b/roles/kubespray-defaults/tasks/main.yaml new file mode 100644 index 000000000..5b2cb96a0 --- /dev/null +++ b/roles/kubespray-defaults/tasks/main.yaml @@ -0,0 +1,5 @@ +- name: Configure defaults + debug: + msg: "Check roles/kubespray-defaults/defaults/main.yml" + tags: + - always