mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-25 04:28:15 +00:00
Convert line break tags causing errors
This commit is contained in:
Billy Tat
+3
-3
@@ -11,10 +11,10 @@ The following table lists the permissions required for the vSphere user account:
|
||||
|
||||
| Privilege Group | Operations |
|
||||
|:----------------------|:-----------------------------------------------------------------------|
|
||||
| Datastore | AllocateSpace </br> Browse </br> FileManagement (Low level file operations) </br> UpdateVirtualMachineFiles </br> UpdateVirtualMachineMetadata |
|
||||
| Datastore | AllocateSpace <br/> Browse <br/> FileManagement (Low level file operations) <br/> UpdateVirtualMachineFiles <br/> UpdateVirtualMachineMetadata |
|
||||
| Network | Assign |
|
||||
| Resource | AssignVMToPool |
|
||||
| Virtual Machine | Config (All) </br> GuestOperations (All) </br> Interact (All) </br> Inventory (All) </br> Provisioning (All) |
|
||||
| Virtual Machine | Config (All) <br/> GuestOperations (All) <br/> Interact (All) <br/> Inventory (All) <br/> Provisioning (All) |
|
||||
|
||||
The following steps create a role with the required privileges and then assign it to a new user in the vSphere console:
|
||||
|
||||
@@ -37,7 +37,7 @@ The following steps create a role with the required privileges and then assign i
|
||||
7. Create a new Global Permission. Add the user you created earlier and assign it the role you created earlier. Click **OK**.
|
||||
|
||||
{{< img "/img/rancher/globalpermissionuser.png" "image" >}}
|
||||
|
||||
|
||||
{{< img "/img/rancher/globalpermissionrole.png" "image" >}}
|
||||
|
||||
**Result:** You now have credentials that Rancher can use to manipulate vSphere resources.
|
||||
|
||||
@@ -13,25 +13,25 @@ This page contains frequently asked questions about the changes between Rancher
|
||||
|
||||
Rancher v2.x is a complete container management platform built 100% on Kubernetes leveraging its Custom Resource and Controller framework. All features are written as a CustomResourceDefinition (CRD) which extends the existing Kubernetes API and can leverage native features such as RBAC.
|
||||
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
**Do you plan to implement upstream Kubernetes, or continue to work on your own fork?**
|
||||
|
||||
We're still going to provide our distribution when you select the default option of having us create your Kubernetes cluster, but it will be very close to upstream.
|
||||
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
**Does this release mean that we need to re-train our support staff in Kubernetes?**
|
||||
|
||||
Yes. Rancher will offer the native Kubernetes functionality via `kubectl` but will also offer our own UI dashboard to allow you to deploy Kubernetes workload without having to understand the full complexity of Kubernetes. However, to fully leverage Kubernetes, we do recommend understanding Kubernetes. We do plan on improving our UX with subsequent releases to make Kubernetes easier to use.
|
||||
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
**Is a Rancher compose going to make a Kubernetes pod? Do we have to learn both now? We usually use the filesystem layer of files, not the UI.**
|
||||
|
||||
No. Unfortunately, the differences were enough such that we cannot support Rancher compose anymore in 2.x. We will be providing both a tool and guides to help with this migration.
|
||||
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
**If we use Kubernetes native YAML files for creating resources, should we expect that to work as expected, or do we need to use Rancher/Docker compose files to deploy infrastructure?**
|
||||
|
||||
@@ -43,7 +43,7 @@ Absolutely.
|
||||
|
||||
Cattle will not supported in v2.x as Rancher has been re-architected to be based on Kubernetes. You can, however, expect majority of Cattle features you use will exist and function similarly on Kubernetes. We will develop migration tools in Rancher v2.1 to help you transform your existing Rancher Compose files into Kubernetes YAML files.
|
||||
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
**Can I migrate existing Cattle workloads into Kubernetes?**
|
||||
|
||||
@@ -55,19 +55,19 @@ Yes. In the upcoming Rancher v2.1 release we will provide a tool to help transla
|
||||
|
||||
Yes. You can manage Kubernetes storage, networking, and its vast ecosystem of add-ons.
|
||||
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
**Are there changes to default roles available now or going forward? Will the Kubernetes alignment impact plans for roles/RBAC?**
|
||||
|
||||
The default roles will be expanded to accommodate the new Rancher 2.x features, and will also take advantage of the Kubernetes RBAC (Role-Based Access Control) capabilities to give you more flexibility.
|
||||
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
**Will there be any functions like network policies to separate a front-end container from a back-end container through some kind of firewall in v2.x?**
|
||||
|
||||
Yes. You can do so by leveraging Kubernetes' network policies.
|
||||
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
**What about the CLI? Will that work the same way with the same features?**
|
||||
|
||||
@@ -81,7 +81,7 @@ Starting with 2.0, the concept of an environment has now been changed to a Kuber
|
||||
|
||||
Kubernetes RKE Templates is on our roadmap for 2.x. Please refer to our Release Notes and documentation for all the features that we currently support.
|
||||
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
**Can you still add an existing host to an environment? (i.e. not provisioned directly from Rancher)**
|
||||
|
||||
@@ -93,7 +93,7 @@ Yes. We still provide you with the same way of executing our Rancher agents dire
|
||||
|
||||
Due to the technical difficulty in transforming a Docker container into a pod running Kubernetes, upgrading will require users to "replay" those workloads from v1.x into new v2.x environments. We plan to ship with a tool in v2.1 to translate existing Rancher Compose files into Kubernetes YAML files. You will then be able to deploy those workloads on the v2.x platform.
|
||||
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
**Is it possible to upgrade from Rancher v1.x to v2.x without any disruption to Cattle and Kubernetes clusters?**
|
||||
|
||||
|
||||
+1
-1
@@ -117,7 +117,7 @@ This reference contains variables that you can use in `questions.yml` nested und
|
||||
| max_length | int | false | Max character length.|
|
||||
| min | int | false | Min integer length. |
|
||||
| max | int | false | Max integer length. |
|
||||
| options | []string | false | Specify the options when the variable type is `enum`, for example: options:<br> - "ClusterIP" <br> - "NodePort" <br> - "LoadBalancer"|
|
||||
| options | []string | false | Specify the options when the variable type is `enum`, for example: options:<br/> - "ClusterIP" <br/> - "NodePort" <br/> - "LoadBalancer"|
|
||||
| valid_chars | string | false | Regular expression for input chars validation. |
|
||||
| invalid_chars | string | false | Regular expression for invalid input chars validation.|
|
||||
| subquestions | []subquestion | false| Add an array of subquestions.|
|
||||
|
||||
+2
-2
@@ -61,8 +61,8 @@ When Rancher is installed on an air gapped Kubernetes cluster, there are two rec
|
||||
|
||||
| Configuration | Chart option | Description | Requires cert-manager |
|
||||
| ------------------------------------------ | ---------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------- |
|
||||
| Rancher Generated Self-Signed Certificates | `ingress.tls.source=rancher` | Use certificates issued by Rancher's generated CA (self signed)<br> This is the **default** and does not need to be added when rendering the Helm template. | yes |
|
||||
| Certificates from Files | `ingress.tls.source=secret` | Use your own certificate files by creating Kubernetes Secret(s). <br> This option must be passed when rendering the Rancher Helm template. | no |
|
||||
| Rancher Generated Self-Signed Certificates | `ingress.tls.source=rancher` | Use certificates issued by Rancher's generated CA (self signed)<br/> This is the **default** and does not need to be added when rendering the Helm template. | yes |
|
||||
| Certificates from Files | `ingress.tls.source=secret` | Use your own certificate files by creating Kubernetes Secret(s). <br/> This option must be passed when rendering the Rancher Helm template. | no |
|
||||
|
||||
### C. Render the Rancher Helm Template
|
||||
|
||||
|
||||
+9
-9
@@ -29,9 +29,9 @@ By default, we provide the steps of how to populate your private registry assumi
|
||||
|
||||
For Rancher servers that will only provision Linux clusters, these are the steps to populate your private registry.
|
||||
|
||||
A. Find the required assets for your Rancher version <br>
|
||||
B. Collect all the required images <br>
|
||||
C. Save the images to your workstation <br>
|
||||
A. Find the required assets for your Rancher version <br/>
|
||||
B. Collect all the required images <br/>
|
||||
C. Save the images to your workstation <br/>
|
||||
D. Populate the private registry
|
||||
|
||||
### Prerequisites
|
||||
@@ -115,9 +115,9 @@ For Rancher servers that will provision Linux and Windows clusters, there are di
|
||||
|
||||
The Windows images need to be collected and pushed from a Windows server workstation.
|
||||
|
||||
A. Find the required assets for your Rancher version <br>
|
||||
B. Save the images to your Windows Server workstation <br>
|
||||
C. Prepare the Docker daemon <br>
|
||||
A. Find the required assets for your Rancher version <br/>
|
||||
B. Save the images to your Windows Server workstation <br/>
|
||||
C. Prepare the Docker daemon <br/>
|
||||
D. Populate the private registry
|
||||
|
||||
{{% accordion label="Collecting and Populating Windows Images into the Private Registry"%}}
|
||||
@@ -189,9 +189,9 @@ Move the images in the `rancher-windows-images.tar.gz` to your private registry
|
||||
|
||||
The Linux images needs to be collected and pushed from a Linux host, but _must be done after_ populating the Windows images into the private registry. These step are different from the Linux only steps as the Linux images that are pushed will actually manifests that support Windows and Linux images.
|
||||
|
||||
A. Find the required assets for your Rancher version <br>
|
||||
B. Collect all the required images <br>
|
||||
C. Save the images to your Linux workstation <br>
|
||||
A. Find the required assets for your Rancher version <br/>
|
||||
B. Collect all the required images <br/>
|
||||
C. Save the images to your Linux workstation <br/>
|
||||
D. Populate the private registry
|
||||
|
||||
{{% accordion label="Collecting and Populating Linux Images into the Private Registry" %}}
|
||||
|
||||
+1
-1
@@ -187,7 +187,7 @@ spec:
|
||||
|
||||
1. Generate a load for the service to test that your pods autoscale as intended. You can use any load-testing tool (Hey, Gatling, etc.), but we're using [Hey](https://github.com/rakyll/hey).
|
||||
|
||||
1. Test that pod autoscaling works as intended.<br/></br>
|
||||
1. Test that pod autoscaling works as intended.<br/><br/>
|
||||
**To Test Autoscaling Using Resource Metrics:**
|
||||
{{% accordion id="observe-upscale-2-pods-cpu" label="Upscale to 2 Pods: CPU Usage Up to Target" %}}
|
||||
Use your load testing tool to scale up to two pods based on CPU Usage.
|
||||
|
||||
Reference in New Issue
Block a user