This section describes each of the properties that you can define for a GreenplumPXFService
configuration in the VMware Tanzu Greenplum manifest file.
apiVersion: "greenplum.pivotal.io/v1beta1"
kind: "GreenplumPXFService"
metadata:
name: <string>
namespace: <string>
spec:
replicas: <integer>
cpu: <cpu-limit>
memory: <memory-limit>
workerSelector: {
<label>: "<value>"
[ ... ]
}
pxfConf:
s3Source:
secret: <Secrets name string>
endpoint: <valid URL string>
protocol: <http|https>
bucket: <string>
folder: <string> [Optional]
You specify Greenplum PXF configuration properties to the Greenplum Operator via the YAML-formatted Greenplum manifest file. A sample manifest file is provided in workspace/samples/my-gp-with-pxf-instance.yaml
. The current version of the manifest supports configuring the cluster name, number of PXF replicas, and the memory, CPU, and remote PXF_CONF configs. See also Deploying PXF with Greenplum for information about deploying a new Greenplum cluster with PXF using a manifest file.
Note: As a best practice, keep the PXF configuration properties in the same manifest file as Greenplum Database, to simplify upgrades or changes to the related service objects.
name: <string>
kubectl
commands using this name.
namespace: <string>
$ kubectl config set-context $(kubectl config current-context) --namespace=<NAMESPACE>
namespace
value.
replicas: <int>
memory: <memory-limit>
4.5Gi
.). If omitted, the pod has no upper bound on the memory resource it can use or inherits the default limit if one is specified in its deployed namespace. See
Assign Memory Resources to Containers and Pods in the Kubernetes documentation for more information.
memory:
keyword from the YAML file.
cpu: <cpu-limit>
cpu: "1.2"
). If omitted, the pod has no upper bound on the CPU resource it can use or inherits the default limit if one is specified in its deployed namespace. See
Assign CPU Resources to Containers and Pods in the Kubernetes documentation for more information.
cpu:
keyword from the YAML file.
workerSelector: <map of key-value pairs>
nodeSelector
attribute. If a
workerSelector
is not desired, remove the
workerSelector
attribute from the manifest file.
worker=gpdb-pxf
to one or more pods using the command:
$ kubectl label node <node_name> worker=gpdb-pxf
With the above labels present in your cluster, you would edit the Greenplum Operator manifest file to specify the same key-value pairs in the workerSelector
attribute. This shows the relevant excerpt from the manifest file:
...
workerSelector: {
worker: "gpdb-pxf"
}
...
pxfConf: <s3Source>
PXF_CONF
directory (
/etc/pxf
). You must ensure that the bucket-folder path contains the complete directory structure and customized files for one or more PXF server configurations. See
Deploying PXF with the Default Configuration for information about deploying Greenplum with a default, initialized PXF configuration directory that you can customize for accessing your data sources.
s3Source
secret: <string>
$ kubectl create secret generic my-greenplum-pxf-configs --from-literal=‘access_key_id=<accessKey>’ --from-literal=‘secret_access_key=<secretKey>’
my-greenplum-pxf-configs
using the S3 access and secret keys that you provide. Replace
<accessKey>
and
<secretKey>
with the actual S3 access and secret key values for your system. If necessary, use your S3 implementation documentation to generate a secret access key.
endpoint: <string>
protocol: <http|https>
https
.
bucket: <string>
folder: <string>
See the workspace/samples/my-gp-with-pxf-instance.yaml
file for an example manifest that configures the PXF resource.