Known Issues in Kubernetes Plugin 1.0.0
Table of Contents
Expand all | Collapse all
-
-
-
-
- Features Introduced in Zero Touch Provisioning 2.0
- Known Issues in the Zero Touch Provisioning 2.0.4 Release
- Known Issues in the Zero Touch Provisioning 2.0.3 Release
- Known Issues in the Zero Touch Provisioning 2.0.2 Release
- Known Issues in the Zero Touch Provisioning 2.0.1 Release
- Known Issues in the Zero Touch Provisioning 2.0.0 Release
- Limitations
-
-
Known Issues in Kubernetes Plugin 1.0.0
The following list describes known issues
in the Panorama plugin for Kubernetes 1.0.0.
PLUG-5449
The Kubernetes plugin does not support
custom certificates for connecting with the cluster API server.
PLUG-5320
If you did not allocate adequate tokens,
and some CN-NGFW pods are on the 4-hour license grace period, on
a Panorama HA failover the CN-NGFW pods that connect first are allocated
licenses. Hence, a CN-NGFW pod that was licensed can now be unlicensed based
on the order it connects to Panorama.To ensure that you continuous
coverage, verify that you have allocated the required number of
tokens for securing you deployment.
PLUG-5250
When you uninstall the Kubernetes plugin
on Panorama, you must also delete the default template (K8S-Network-Setup)
that the plugin automatically creates before or after you downgrade
to 9.1 or an earlier version of Panorama. You will be unable to
commit changes on Panorama if this default template with 60 interfaces
is not deleted manually. This commit failure occurs because Panorama
9.1 and earlier versions only support up to 30 interfaces per template,
and this template has 60 interfaces.
Workaround: Delete the K8S-Network-Setup template
before downgrading or after downgrading. The commit on Panorama
will be successful after you remove this template.
PLUG-4888
If you update the number of tokens allocated
for licensing the CN-Series firewalls (KubernetesSetupLicenses),
when the plugin communicates with the IT server, the license Issued
Date is updated to match the current date on Panorama.
PLUG-4724
When the Kubernetes cluster becomes unreachable
from the Panorama plugin, all the nodes that were licensed till
that point will remain licensed.Tokens can be given back to the
licensing server only if there is cluster connectivity and you must
reestablish cluster connectivity in the Panorama plugin to reclaim
tokens.
Workaround: Delete the cluster configuration on Panorama.
PLUG-4549
API calls from the Kubernetes plugin
to the Kubernetes API server become unresponsive sometimes due to
network connectivity issues. When this issue occurs a System Log
is generated with the following message:
Subprocess hanging for <mon-def-name>. Plugin watcher may be in bad state. To resolve please run following command: request plugins reset-plugin plugin-name kubernetesWorkaround: When this issue happens restart the plugin
from the CLI with the following command: request plugins reset-plugin plugin-name kubernetes
PLUG-3543
When you add a large number of Kubernetes
clusters to Panorama, depending on the number of services running
on each cluster, it might up to 10 minutes to create the service
objects and register the IP addresses on Panorama.
PLUG-3524
If you reference the same device group
in more than one monitoring definition on Panorama, (PluginsKubernetesMonitoring Definition, the
tags associated with one cluster and monitoring definition may be
shared with the other clusters associated with the other monitoring definitions.
PLUG-3339
After activating the authorization code on the CSP when
you select Retrieve license key from license server on
Panorama (KubernetesSetupLicenses), the license information
is not displayed successfully.
Workaround: Click the refresh icon on the screen to view
the license information.