Skip to content

Commit

Permalink
Fixes a manifest link bug for 3.19-2
Browse files Browse the repository at this point in the history
  • Loading branch information
@ctauchen
ctauchen committed May 16, 2024
1 parent 18c125b commit b88263c
Show file tree
Hide file tree
Showing 39 changed files with 4,054 additions and 29 deletions.
185 changes: 185 additions & 0 deletions ...rise_versioned_docs/version-3.19-2/_includes/components-temp/CalicoWindowsInstall-temp.js
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,185 @@
import React from 'react';

import Admonition from '@theme/Admonition';
import CodeBlock from '@theme/CodeBlock';
import Link from '@docusaurus/Link';

import { prodname, prodnameWindows } from '../../variables';

function CalicoWindowsInstallFirstStep(props) {
if (props.networkingType === 'vxlan') {
return (
<li>
Ensure that BGP is disabled.
<ul>
<li>If you installed {prodname} using the manifest, BGP is already disabled.</li>
<li>If you installed {prodname} using the operator, run this command:</li>
<br />
<CodeBlock language='bash'>
{`kubectl patch installation default --type=merge -p '{"spec": {"calicoNetwork": {"bgp": "Disabled"}}}'`}
</CodeBlock>
</ul>
</li>
);
}

return (
<li>
<p>
Enable BGP service on the Windows nodes. Install the RemoteAccess service using the following Powershell
commands:
</p>
<CodeBlock language='powershell'>
Install-WindowsFeature RemoteAccess{'\n'}
Install-WindowsFeature RSAT-RemoteAccess-PowerShell
{'\n'}
Install-WindowsFeature Routing
</CodeBlock>
<p>Then restart the computer:</p>
<CodeBlock language='powershell'>Restart-Computer -Force</CodeBlock>
<p>before running:</p>
<CodeBlock language='powershell'>Install-RemoteAccess -VpnType RoutingOnly</CodeBlock>
<p>
Sometimes the remote access service fails to start automatically after install. To make sure it is running, run
the following command:
</p>
<CodeBlock language='powershell'>Start-Service RemoteAccess</CodeBlock>
</li>
);
}

export default function CalicoWindowsInstall(props) {
return (
<ol>
<CalicoWindowsInstallFirstStep {...props} />
<li>
<p>
Get the cluster's Kubernetes API server host and port, which will be used to update the {prodnameWindows}{' '}
config map. The API server host and port is required so that the {prodnameWindows} installation script can
create a kubeconfig file for {prodname} services. If your Windows nodes already have {prodnameWindows}{' '}
installed manually, skip this step. The installation script will use the API server host and port from your
node's existing kubeconfig file if the <code>KUBERNETES_SERVICE_HOST</code> and{' '}
<code>KUBERNETES_SERVICE_PORT</code> variables are not provided in the <code>calico-windows-config</code>{' '}
ConfigMap.
</p>
<p>First, make a note of the address of the API server:</p>
<ul>
<li>
<p>
If you have a single API server with a static IP address, you can use its IP address and port. The IP can
be found by running:
</p>
<CodeBlock language='bash'>kubectl get endpoints kubernetes -o wide</CodeBlock>
<p>The output should look like the following, with a single IP address and port under "ENDPOINTS":</p>
<CodeBlock>
{`NAME ENDPOINTS AGE
kubernetes 172.16.101.157:6443 40m`}
</CodeBlock>
<p>
If there are multiple entries under "ENDPOINTS", then your cluster must have more than one API server. In
this case, use the appropriate load balancing option below for your cluster.
</p>
</li>
<li>
<p>
If using DNS load balancing (as used by <code>kops</code>), use the FQDN and port of the API server{' '}
<code>
api.internal.{'<'}clustername{'>'}
</code>
.
</p>
</li>
<li>
<p>
If you have multiple API servers with a load balancer in front, you should use the IP and port of the load
balancer.
</p>
</li>
<Admonition type='tip'>
<p>
If your cluster uses a ConfigMap to configure <code>kube-proxy</code> you can find the "right" way to
reach the API server by examining the config map. For example:
</p>
<CodeBlock>
kubectl get configmap -n kube-system kube-proxy -o yaml | grep server{'\n'}
server: https://d881b853ae312e00302a84f1e346a77.gr7.us-west-2.eks.amazonaws.com
</CodeBlock>
<p>
In this case, the server is <code>d881b853aea312e00302a84f1e346a77.gr7.us-west-2.eks.amazonaws.com</code>{' '}
and the port is 443 (the standard HTTPS port).
</p>
</Admonition>
</ul>
</li>
<li>
<p>
Create the <code>kubernetes-services-endpoint</code> ConfigMap with the Kubernetes API server
host and port (discovered in the previous step) used to create a kubeconfig file for {prodname} services.
<CodeBlock language='bash'>{`kubectl apply -f - << EOF
kind: ConfigMap
apiVersion: v1
metadata:
name: kubernetes-services-endpoint
namespace: tigera-operator
data:
KUBERNETES_SERVICE_HOST: "$\{APISERVER_ADDR\}"
KUBERNETES_SERVICE_PORT: "$\{APISERVER_PORT\}"
EOF`}
</CodeBlock>
</p>
</li>
<li>
<p>
Get the Kubernetes service clusterIP range configured in your cluster. This must
match the service-cluster-ip-range used by kube-apiserver.
</p>
</li>
<li>
<p>
Add the Kubernetes service CIDR (discovered in the previous step) enable {prodnameWindows} on the Tigera operator installation resource.
</p>
<p>
For example, with a Kubernetes service clusterIP range of 10.96.0.0/12:
<CodeBlock language='bash'>{`kubectl patch installation default --type merge --patch='{"spec": {"serviceCIDRs": ["10.96.0.0/12"], "calicoNetwork": {"windowsDataplane": "HNS"}}}'`}</CodeBlock>
</p>
</li>
<li>
Install kube-proxy on Windows nodes.
<p>
Depending on your platform, you may already have kube-proxy running on your Windows nodes. If kube-proxy is
already running on your Windows nodes, skip this step. If kube-proxy is not running, you must install and run
kube-proxy on each of the Windows nodes in your cluster. Note: The <Link href="https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/hostprocess/calico/kube-proxy/kube-proxy.yml">
manifest provided in the kubernetes-sigs sig-windows-tools repository</Link> depends on the kubeconfig
provided by the <code>kube-proxy</code> ConfigMap in the <code>kube-system</code> namespace.
</p>
<p>
You <b>must</b> replace <code>KUBE_PROXY_VERSION</code> with your cluster's Kubernetes version in <code>kube-proxy.yml</code> to ensure the daemonset uses a kube-proxy Windows image that is compatible with your Kubernetes cluster. Use a command like the following to retrieve the YAML file, replace the version, and apply it:
<CodeBlock language='bash'>{`curl -L https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/hostprocess/calico/kube-proxy/kube-proxy.yml | sed "s/KUBE_PROXY_VERSION/\<YOUR_KUBERNETES_VERSION>/g" | kubectl apply -f -`}</CodeBlock>
</p>
</li>
<li>
<p>Monitor the installation.</p>
The {prodnameWindows} HPC installation has 2 initContainers: <code>uninstall-calico</code>, which deals with removing previous manually installed {prodnameWindows} services, if any
and <code>install-cni</code>, which installs needed CNI binaries and configuration, when using Calico CNI.
<CodeBlock language='bash'>
kubectl logs -f -n calico-system -l k8s-app=calico-node-windows -c uninstall-calico{'\n'}
kubectl logs -f -n calico-system -l k8s-app=calico-node-windows -c install-cni{'\n'}
</CodeBlock>
<p>
After these initContainers finish their execution, installation is complete. Next, the
{prodnameWindows} services are started in separate containers:
</p>
<CodeBlock language='bash'>
kubectl logs -f -n calico-system -l k8s-app=calico-node-windows -c node{'\n'}
kubectl logs -f -n calico-system -l k8s-app=calico-node-windows -c felix{'\n'}
{props.networkingType === 'windows-bgp'
? `kubectl logs -f -n calico-system -l k8s-app=calico-node-windows -c confd`
: null}
</CodeBlock>
<p>
The <code>calico-node-windows</code> pods will be ready after their containers finish initializing.
</p>
</li>
</ol>
);
}
53 changes: 53 additions & 0 deletions ...enterprise_versioned_docs/version-3.19-2/_includes/components-temp/CliConfigIntro-temp.js
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,53 @@
import React from 'react';

import Admonition from '@theme/Admonition';
import CodeBlock from '@theme/CodeBlock';
import Link from '@docusaurus/Link';

import { prodname, baseUrl } from '../../variables';

export default function CliConfigIntro(props) {
return (
<>
<p>
Many <code>{props.cli}</code> commands require access to the {prodname} datastore. In most circumstances,{' '}
<code>{props.cli}</code> cannot achieve this connection by default. You can provide
<code>{props.cli}</code> with the information it needs using either of the following.
</p>
<ol>
<li>
<p>
<strong>Configuration file</strong>: by default, <code>{props.cli}</code> will look for a configuration file
at <code>/etc/calico/{props.cli}.cfg</code>. You can override this using the <code>--config</code> option
with commands that require datastore access. The file can be in either YAML or JSON format. It must be valid
and readable by <code>{props.cli}</code>. A YAML example follows.
</p>
<CodeBlock language='yaml'>
{`apiVersion: projectcalico.org/v3
kind: CalicoAPIConfig
metadata:
spec:
datastoreType: "kdd"
...`}
</CodeBlock>
</li>
<li>
<p>
<strong>Environment variables</strong>: If <code>{props.cli}</code> cannot locate, read, or access a
configuration file, it will check a specific set of environment variables.
</p>
</li>
</ol>
<p>
See the section that corresponds to your <Link href={`${baseUrl}/operations/clis`}>datastore type</Link> for a
full set of options and examples.
</p>
<Admonition type='note'>
When running <code>{props.cli}</code> inside a container, any environment variables and configuration files must
be passed to the container so they are available to the process inside. It can be useful to keep a running
container (that sleeps) configured for your datastore, then it is possible to <code>exec</code> into the
container and have an already configured environment.
</Admonition>
</>
);
}
67 changes: 67 additions & 0 deletions ...erprise_versioned_docs/version-3.19-2/_includes/components-temp/ComponentVersions-temp.js
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,67 @@
import React from 'react';
import Link from '@docusaurus/Link';
import Heading from '@theme/Heading';

import { toKebab } from '@site/src/components/utils/formatters';

import variables from '../../variables';

export default function ComponentVersions() {
const { prodname, version, downloadsurl } = variables;

const releases = variables.releases.map((release) => {
return release;
}).filter(release => release);

return (
<>
{releases.map((release) => (
<div key={release.title}>
<p>
This page lists the specific component versions that go into {variables.prodname} patch releases.
</p>
<Heading
as='h2'
id={`component-versions-${toKebab(release.title)}`}
data-bz-version={toKebab(release.title)}
>
Component versions for {variables.prodname} {release.title.startsWith('v') ? release.title.substring(1) : release.title}
</Heading>
<p>
{release.title !== 'master' && (
<p>
<Link
href={`${downloadsurl}/ee/archives/release-${release.title}-${release['tigera-operator'].version}.tgz`}
>
Release archive
</Link>{' '}
with Kubernetes manifests. Based on Calico {releases[0].calico.minor_version}.
</p>
)}
This release comprises the following components, and can be installed using{' '}
<code>
{release['tigera-operator'].registry}/{release['tigera-operator'].image}:
{release['tigera-operator'].version}
</code>
</p>
<table>
<thead>
<tr>
<th>Component</th>
<th>Version</th>
</tr>
</thead>
<tbody>
{Object.keys(release.components).map((componentName) => (
<tr key={componentName}>
<td>{componentName}</td>
<td>{release.components[componentName].version}</td>
</tr>
))}
</tbody>
</table>
</div>
))}
</>
);
}
Loading

0 comments on commit b88263c

Please sign in to comment.