This chapter discusses the configuration metadata that you provide to define the attributes of your TimesTen database. This configuration metadata is used by TimesTen and the Operator when TimesTen runs in the Kubernetes cluster. The chapter also discusses the Kubernetes facilities that you can use to get the configuration metadata into your TimesTen containers. The chapter also includes various examples that show you how to define the configuration metadata, and how to use the Kubernetes facilities. It then discussed additional configuration options.
Configuration metadata, in the form of metadata files, enables you to specify the attributes of your TimesTen database, and how that database is to interact with other applications and components. Each metadata file has a specific name. You create this file and add specific metadata to it. For example, the TimesTen Operator provides support for a file named db.ini for the TimesTen connection attributes. You create this file, and in it you include your database's specific connection attributes. See "The supported metadata files" for details.
Kubernetes supports various facilities to enable you to get the metadata files into the TimesTen containers. Specifically, when the Operator creates each Pod, that Pod has a container that runs TimesTen. This container accesses the metadata files by looking for their existence in the /ttconfig directory. By using a Kubernetes facility, the metadata files are placed in the /ttconfig directory of the TimesTen containers. See "Populating the /ttconfig directory" for information on these facilities.
These are the supported metadata files. Use these files to specify the attributes and the metadata for your database. After you create these files, and you choose a facility to get these files in your TimesTen containers, TimesTen can then access them to determine the attributes and the metadata that is specific to your database.
These metadata files apply to all databases:
These metadata files are specific to TimesTen Cache:
These metadata files are specific to TLS support:
The epilog.sql metadata file is used for operations that occur after the replication scheme has been created.
The Operator can automatically create a named user with ADMIN privileges in your database when it is created. Create the adminUser file for this purpose. This file should contain one line of the form:
user/password
If you are using TimesTen Cache, you must specify the cachegroups.sql file. This file contains the create cache group and the load cache group definitions. Specifically, in this file, you specify CREATE CACHE GROUP statements. In addition, if you want to load data from the Oracle Database into your cache groups, you can specify one or more LOAD CACHE GROUP statements. You can also specify the ttOptUpdateStats or the ttOptEstimateStats TimesTen built-in procedures to update statistics on the cache tables after the LOAD CACHE GROUP operation completes. Ensure these built-in procedures follow the LOAD CACHE GROUP statements in the cachegroups.sql file.
This file is required as cache groups must be created before replication can be configured.
For more information, see:
"CREATE CACHE GROUP" and "LOAD CACHE GROUP" in the Oracle TimesTen In-Memory Database SQL Reference.
"ttOptUpdateStats" and "ttOptEstimateStats" in the Oracle TimesTen In-Memory Database Reference.
"Cache group types" in the Oracle TimesTen Application-Tier Database Cache User's Guide.
Here is an example of a cachegroups.sql file. The file defines two cache groups and loads data into one cache group:
CREATE DYNAMIC ASYNCHRONOUS WRITETHROUGH CACHE GROUP writecache FROM oratt.writetab ( pk NUMBER NOT NULL PRIMARY KEY, attr VARCHAR2(40) ); CREATE READONLY CACHE GROUP readcache AUTOREFRESH INTERVAL 5 SECONDS FROM oratt.readtab ( keyval NUMBER NOT NULL PRIMARY KEY, str VARCHAR2(32) ); LOAD CACHE GROUP readcache COMMIT EVERY 256 ROWS;
If you are using TimesTen Cache, you must specify the cacheUser metadata file. This file must contain one line of the form:
cacheUser/ttPassword/oraPassword
The cacheUser is the user you want to designate as the TimesTen cache manager user. This user must have the same name as the user whom you designated as the cache administration user in the Oracle Database. This user must already exist in the Oracle database. Specify ttPassword as the TimesTen password for the TimesTen cacheUser user (the TimesTen cache manager). The oraPassword is the Oracle Database password you specified when you created the cacheUser user in the Oracle Database.
For example, assume you have created the cacheuser2 cache administration user in the Oracle Database with password oraclepwd. Also assume you want to designate this cacheuser2 user as the TimesTen cache manager user with a TimesTen password of ttpwd. In this example, the cacheUser metadata file contains this one line:
cacheuser2/ttpwd/oraclepwd
In this example, the Operator creates the cacheuser2 user with the ttpwd in the TimesTen database. This cacheuser2 user then serves as the cache manager user in your TimesTen database. (Note that you do not need to create this TimesTen user. The Operator does it for you.) See "Create the TimesTen users" in the Oracle TimesTen Application-Tier Database Cache User's Guide for information on the TimesTen users. Also see "Overview" and "Creating the metadata files and the Kubernetes facility" in this book.
The Operator grants privileges to the TimesTen cacheUser user (cacheuser2, in this example) that are appropriate for this user's role as the cache manager. These privileges are:
CREATE SESSION
CACHE MANAGER
CREATE ANY TABLE
LOAD ANY CACHE GROUP
REFRESH ANY CACHE GROUP
FLUSH ANY CACHE GROUP
DROP ANY CACHE GROUP
ALTER ANY CACHE GROUP
UNLOAD ANY CACHE GROUP
SELECT ANY TABLE
INSERT ANY TABLE
UPDATE ANY TABLE
DELETE ANY TABLE
By default, in a TimesTen Client/Server environment, data is transmitted between your client applications and your TimesTen database unencrypted. However, you can configure TLS for Client/Server to ensure secure network communication between TimesTen clients and servers. To encrypt Client/Server traffic, specify the /ttconfig/csWallet file. This file contains the Oracle wallet for the server, which contains the credentials that are used for configuring TLS encryption between your TimesTen database and your Client/Server applications. The file will be available in the containers of your TimesTen databases in the directory /tt/home/oracle/csWallet. You can reference this directory in your db.ini file (by specifying the wallet connection attribute). See "Creating TLS certificates for replication and Client/Server" and "Configuring TLS for Client/Server" for details.
The client wallet must also be available to your client applications. See "Creating TLS certificates for replication and Client/Server" and "Configuring TLS for Client/Server" for details.
The db.ini file contains the TimesTen connection attributes for your TimesTen database. The connection attributes you specify in the db.ini file will be included in TimesTen's sys.odbc.ini file. You can specify data store attributes, first connection attributes, and general connection attributes in the db.ini file, except do not specify the DataStore or the LogDir connection attributes. These two attributes are set by the Operator. The name of the DSN is the name of the TimesTenClassic object. (For example, if your TimesTenClassic object is called sample, the name of your DSN is sample.)
If you are using TimesTen Cache, you must specify this db.ini file. In it, you must specify the OracleNetServiceName and the DatabaseCharacterSet connection attributes. The DatabaseCharacterSet value must match the value of the database character set in the Oracle Database.
See "List of attributes" in the Oracle TimesTen In-Memory Database Reference for information on the TimesTen connection attributes.
Note:
If the/ttconfig/db.ini file is not present in a TimesTen container, TimesTen creates a default sys.odbc.ini file. For this default sys.odbc.ini, the connection attributes are:Permsize=200DatabaseCharacterSet=AL32UTF8
If you are using TimesTen Cache, ensure you specify the db.ini file.
This example shows a sample db.ini file, which contains the connection attributes for your TimesTen database:
PermSize=500 LogFileSize=1024 LogBufMB=1024 DatabaseCharacterSet=AL32UTF8 OracleNetServiceName=OraCache
Use this file for operations that occur after the replication scheme has been created and the replication agent has been started. For example, if you want to create replicated bookmarks in XLA, you can call the ttXlaBookmarkCreate built-in procedure in this file.
Here is an example of an epilog.sql file. The example calls the ttXlaBookmarkCreate built-in procedure to create XLA bookmarks. See the "ttXlaBookmarkCreate" built-in procedure in the Oracle TimesTen In-Memory Database Reference for more information.
call ttXlaBookmarkCreate('mybookmark',0x01);
By default, TimesTen replication transmits data between your TimesTen databases unencrypted. However, you can configure TLS for replication to ensure secure network communication between your replicated TimesTen databases. To do this, you must specify the /ttconfig/replicationWallet file. This file contains an Oracle wallet, which contains the credentials that are used by TimesTen replication for configuring TLS encryption between your active standby pair of TimesTen databases. See "Creating TLS certificates for replication and Client/Server" and "Configuring TLS for replication" for details.
You must also include the replicationCipherSuite field and optionally include the replicationSSLMandatory field in your TimesTenClassic object definition. See the replicationCipherSuite entry and the replicationSSLMandatory entry in Table 11-3, "TimesTenClassicSpecSpec" and see "Configuring TLS for replication" for details.
The Operator can automatically initialize your database with schema objects, such as users, tables, and sequences. To have the Operator do this, create the schema.sql file.
The instance administrator runs this file (by using the ttIsql utility) immediately after the database is created. The file is run before the Operator configures replication or cache in your TimesTen database.
In TimesTen Cache, one or more cache table users own the cache tables. If this cache table user is not the cache manager user, then you must specify the schema.sql file and in it you must include the schema user and assign the appropriate privileges to this schema user. For example, if the oratt schema user was created in the Oracle Database, and this user is not the TimesTen cache manager user, you must create the TimesTen oratt user in this file. See "Create the Oracle Database users" for more information on the schema users in the Oracle Database. Also see "Create the TimesTen users" in the Oracle TimesTen Application-Tier Database Cache User's Guide.
Do not include cache definitions in this file. Instead, use the cachegroups.sql metadata file. See "cachegroups.sql" for information.
The Oracle Database sqlnet.ora file defines options for how client applications communicate with the Oracle Database. To use TimesTen Cache or to use tools like ttLoadFromOracle, define a sqlnet.ora file. This file describes how applications, including TimesTen, can connect to your Oracle database. Note: If you define a sqlnet.ora file, you must define a tnsnames.ora file. See "tnsnames.ora file" for information on the tnsnames.ora file.
This is an example of a sqlnet.ora file:
NAME.DIRECTORY_PATH= {TNSNAMES, EZCONNECT, HOSTNAME}
SQLNET.EXPIRE_TIME = 10
SSL_VERSION = 1.2
The Oracle Database tnsnames.ora file defines Oracle Net Services to which applications connect. You need to use tnsnames.ora (and perhaps a sqlnet.ora file, described in sqlnet.ora file) if you are using:
TimesTen Cache
SQL APIs, such as Pro*C, OCI, or ODPI-C
The ttLoadFromOracle feature (See "ttLoadFromOracle" in the Oracle TimesTen In-Memory Database Reference for more information).
This is an example of a tnsnames.ora file:
OraTest =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = database.myhost.svc.cluster.local)
(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = OraTest.my.domain.com)))
OraCache =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = database.myhost.svc.cluster.local)
(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = OraCache.my.domain.com)))
To configure TimesTen with the supported metadata files, you must ensure the files are placed in the /ttconfig directory of the TimesTen containers. (See "The supported metadata files" for details on the supported metadata files.)
There is no requirement as to how you get the files into the /ttconfig directory. However, Kubernetes does provide these facilities for you to consider:
You can use one or more ConfigMaps and (or) one or more Secrets to incorporate the metadata files into the TimesTen containers. This enables you to give different deployments of TimesTen different metadata by using different objects for each deployment. In addition, you can use Secrets for metadata that contains sensitive data, like passwords and certificates.
The use of a ConfigMap to populate the metadata into Pods is a standard Kubernetes technique. One benefit is that you can modify the ConfigMap after it is created, which results in the immediate update of the files that are in the Pod.
Note:
TimesTen may not immediately notice and act on the changed content of the files.To use ConfigMaps and Secrets, follow this process:
Decide what facilities will contain what metadata files. For example, you can use one ConfigMap for all the metadata files. Or, as another example, you can use one ConfigMap for the db.ini metadata file and one Secret for the adminUser and the schema.sql metadata files. There is no specific requirement.
Create the directory (or directories) that will contain the metadata files.
Use the kubectl create command to create the ConfigMap and the Secrets in the Kubernetes cluster.
Include the ConfigMaps and Secrets in your TimesTenClassic object definition. See "Understanding the deployment process" for a detailed explanation of how to create your TimesTenClassic object. In the following sections, there are examples that illustrate how and where to reference the ConfigMaps and Secrets in your TimesTenClassic object definition (in your YAML file). But, see "Understanding the deployment process" for the details of how to create the TimesTenClassic object.
When you use ConfigMaps and Secrets to hold your metadata and then reference them in the TimesTenClassic object definition, the Operator creates a ProjectedVolume called tt-config. This tt-config volume contains the contents of all the ConfigMaps and all the Secrets specified in the dbConfigMap and the dbSecret fields of your TimesTenClassic object. This volume is mounted as /ttconfig in the TimesTen containers.
Here are two examples illustrating how to use ConfigMaps and Secrets:
This example uses one ConfigMap (called sample) for the db.ini, the adminUser, and the schema.sql metadata files.
On your Linux development host:
From the directory of your choice, create an empty subdirectory for the metadata files. This example creates the cm_sample subdirectory. (The cm_sample directory is used in the remainder of this example to denote this directory.)
% mkdir -p cm_sample
Navigate to the ConfigMap directory.
% cd cm_sample
Create the db.ini file in this ConfigMap directory (cm_sample, in this example). In this db.ini file, define the PermSize and DatabaseCharacterSet connection attributes.
vi db.ini
PermSize=200 DatabaseCharacterSet=AL32UTF8
Create the adminUser file in this ConfigMap directory (cm_sample in this example). In this adminUser file, create the scott user with the tiger password.
vi adminUser
scott/tiger
Create the schema.sql file in this ConfigMap directory (cm_sample in this example). In this schema.sql file, define the s sequence and the emp table for the scott user. The Operator will automatically initialize your database with these object definitions.
vi schema.sql
create sequence scott.s; create table scott.emp ( id number not null primary key, name char(32) );
Create the ConfigMap. The files in the cm_sample directory are included in the ConfigMap and, later, will be available in the TimesTen containers.
In this example:
The name of the ConfigMap is sample. Replace sample with a name of your choosing. (sample is represented in bold in this example.)
This example uses cm_sample as the directory where the files that will be copied into the ConfigMap reside. If you use a different directory, replace cm_sample with the name of your directory. (cm_sample is represented in bold in this example.)
Use the kubectl create command to create the ConfigMap:
% kubectl create configmap sample --from-file=cm_sample configmap/sample created
Use the kubectl describe command to verify the contents of the ConfigMap. (sample, in this example.)
% kubectl describe configmap sample Name: sample Namespace: mynamespace Labels: <none> Annotations: <none> Data ==== adminUser: ---- scott/tiger db.ini: ---- PermSize=200 DatabaseCharacterSet=AL32UTF8 schema.sql: ---- create sequence scott.s; create table scott.emp ( id number not null primary key, name char(32) ); Events: <none>
You successfully created and deployed the sample ConfigMap.
Include the ConfigMap in the TimesTenClassic object definition. In the dbConfigMap field, specify the name of the your ConfigMap (sample, in this example, represented in bold).
Note this example uses a storageSize of 250G (suitable for a production environment). For demonstration purposes, a storageSize of 50G is adequate. See the storageSize and the logStorageSize entries in the Table 11-3, "TimesTenClassicSpecSpec" for information.
apiVersion: timesten.oracle.com/v1
kind: TimesTenClassic
metadata:
name: sample
spec:
ttspec:
storageClassName: oci
storageSize: 250G
image: phx.ocir.io/youracount/tt1814110:3
imagePullSecret: sekret
dbConfigMap:
- sample
The sample ConfigMap holds the metadata files. The tt-config volume contains the contents of the sample ConfigMap.
See "TimesTenClassicSpecSpec" for information on the dbConfigMap attribute. See "Defining and creating the TimesTenClassic object" for information on creating the TimesTenClassic object.
This example uses one ConfigMap (called myconfig) for the db.ini metadata file and one Secret (called mysecret) for the adminUser and the schema.sql metadata files.
On your Linux development host:
From the directory of your choice:
Create one empty subdirectory for the ConfigMap. This example creates the cm_myconfig subdirectory. (The cm_myconfig directory is used in the remainder of this example to denote this directory.) This directory will contain the db.ini metadata file.
Create a second empty subdirectory for the Secret. This example creates the secret_mysecret subdirectory. (The secret_mysecret directory is used in the remainder of this example to denote this directory.) This directory will contain the adminUser and the schema.sql metadata files.
% mkdir -p cm_myconfig % mkdir -p secret_mysecret
Navigate to the ConfigMap directory.
% cd cm_myconfig
Create the db.ini file in this ConfigMap directory (cm_myconf, in this example). In this db.ini file, define the PermSize and DatabaseCharacterSet connection attributes.
vi db.ini
PermSize=200 DatabaseCharacterSet=AL32UTF8
Navigate to the Secret directory.
% cd secret_mysecret
Create the adminUser file in this Secret directory (secret_mysecret in this example). In this adminUser file, create the scott user with the tiger password.
vi adminUser
scott/tiger
Create the schema.sql file in this Secret directory (secret_mysecret in this example). In this schema.sql file, define the s sequence and the emp table for the scott user. The Operator will automatically initialize your database with these object definitions.
vi schema.sql
create sequence scott.s; create table scott.emp ( id number not null primary key, name char(32) );
Create the ConfigMap. The files in the cm_myconfig directory are included in the ConfigMap and, later, will be available in the TimesTen containers.
In this example:
The name of the ConfigMap is myconfig. Replace myconfig with a name of your choosing. (myconfig is represented in bold in this example.)
This example uses cm_myconfig as the directory where the files that will be copied into the ConfigMap reside. If you use a different directory, replace cm_myconfig with the name of your directory. (cm_myconfig is represented in bold in this example.)
Use the kubectl create command to create the ConfigMap:
% kubectl create configmap myconfig --from-file=cm_myconfig configmap/myconfig created
You successfully created and deployed the myconfig ConfigMap.
Use the kubectl describe command to verify the contents of the ConfigMap. (myconfig, in this example.)
% kubectl describe configmap myconf Name: myconfig Namespace: mynamespace Labels: <none> Annotations: <none> Data ==== db.ini: ---- PermSize=200 DatabaseCharacterSet=AL32UTF8 Events: <none>
Create the Secret. The files in the secret_mysecret directory are included in the Secret and, later, will be available in the TimesTen containers.
In this example:
The name of the Secret is mysecret. Replace mysecret with a name of your choosing. (mysecret is represented in bold in this example.)
This example uses secret_mysecret as the directory where the files that will be copied into the Secret reside. If you use a different directory, replace secret_mysecret with the name of your directory. (secret_mysecret is represented in bold in this example.)
Use the kubectl create command to create the Secret:
% kubectl create secret generic mysecret --from-file=secret_mysecret secret/mysecret created
You successfully created and deployed the mysecret Secret.
Use the kubectl describe command to view the Secret. (mysecret, in this example.) Note the contents of the adminUser and the schema.sql files are not displayed.
% kubectl describe secret mysecret Name: mysecret Namespace: mynamespace Labels: <none> Annotations: <none> Type: Opaque Data ==== adminUser: 12 bytes schema.sql: 98 bytes
Include the ConfigMap and the Secret in the TimesTenClassic object definition.
In the dbConfigMap field, specify the name of the your ConfigMap (myconfig, in this example, represented in bold).
In the dbSecret field, specify the name of the your Secret (mysecret, in this example, represented in bold).
apiVersion: timesten.oracle.com/v1
kind: TimesTenClassic
metadata:
name: sample
spec:
ttspec:
storageClassName: oci
storageSize: 250G
image: phx.ocir.io/youracount/tt1814110:3
imagePullSecret: sekret
dbConfigMap:
- myconfig
dbSecret:
- mysecret
The myconfig ConfigMap and the mysecret Secret holds the metadata files. The tt-config volume contains the contents of the myconfig ConfigMap and the mysecret Secret.
See "TimesTenClassicSpecSpec" for information on the dbConfigMap and the dbSecret attributes. See "Defining and creating the TimesTenClassic object" for information on creating the TimesTenClassic object.
You can use an init container to get your metadata files into the /ttconfig directory of the TimesTen containers. An init container enables you to create your own scripts to populate the /ttconfig directory with the metadata files. For more information on init containers, see:
https://kubernetes.io/docs/concepts/workloads/pods/init-containers
This example illustrates how to use an init container. It shows you where to specify the script that populates the /ttconfig directory (represented in bold). It also uses the tt-config volume name in the volumes field of the TimesTenClassic object. If you specify a volume with the tt-config name, it will be automatically mounted at /ttconfig in your TimesTen containers. See volumes (represented in bold).
See "The TimesTenClassic object type" and "Understanding the deployment process" for details on the creating the TimesTenClassic object.
apiVersion: timesten.oracle.com/v1
kind: TimesTenClassic
metadata:
name: init1
spec:
ttspec:
storageClassName: oci
storageSize: 250G
image: phx.ocir.io/youraccount/tt1814110:3
imagePullSecret: sekret
template:
spec:
imagePullSecrets:
- name: sekret
initContainers:
- name: init1a
image: phx.ocir.io/youraccount/tt1814110:3
command:
- sh
- "-c"
- |
/bin/bash <<'EOF'
Your script to populate /ttconfig goes here
EOF
volumeMounts:
- name: tt-config
mountPath: /ttconfig
volumes:
- name: tt-config
emptyDir: {}
This section discusses advanced configuration options. These are optional configurations for your environment.
The Operator creates a Kubernetes StatefulSet object with the same name as the TimesTenClassic object. The StatefulSet associates one or more PersistentVolumeClaims with each Pod that it creates. This causes the associated volumes to be mounted in each Pod. These volumes persist across the instantiations of the Pod. If a Pod fails, the files that the Pod created in these volumes remain when Kubernetes creates a new Pod to replace the failed one.
When you create a TimesTenClassic object, you must specify storageClassName and you may specify storageSize. These attributes determine the characteristics of the PersistentVolumes.
The storageClassName must be one that is provided by the Kubernetes environment in which you are using. For example, in Oracle Kubernetes Environment (OKE), you may use oci.
In OKE, 50G of storage is requested by default. Use the storageSize attribute to request a different size. The example in this section uses a storageSize and a logStorageSize that is greater than 50G. 50G of storage may be adequate for demonstration purposes, but in production environments, consider greater storage. See the storageSize and the logStorageSize entries in the Table 11-3, "TimesTenClassicSpecSpec" for information.
TimesTen places the TimesTen installation, the instance, and the database in this storage. It is mounted in each container, in each Pod, as /tt. The TimesTen instance is located at /tt/home/oracle/instances/instance1.
TimesTen best practices recommends that the transaction log files associated with a TimesTen database be located on a different storage volume than the checkpoint files for the database. This provides separate paths to storage for the checkpoint and the transaction log operations. For example, you can store the transaction log files in a high performance storage, while storing the checkpoint files in a slower storage. See "Locate checkpoint and transaction log files on separate physical device" in the Oracle TimesTen In-Memory Database Operations Guide for more information.
To locate the checkpoint files and the transaction log files on a separate path of storage, provide a value for a second persistent storage, that is used for the transaction log files only. Use the logStorageSize attribute for this and control its placement by using the logStorageClassName attribute. This causes a second PersistentVolumeClaim to be created for each Pod, which will then be available in each container at /ttlog. (This second storage volume has a /ttlog mount point.)
See "The TimesTenClassic object type" and "Understanding the deployment process" for details.
For example:
apiVersion: timesten.oracle.com/v1
kind: TimesTenClassic
metadata:
name: sample
spec:
ttspec:
storageClassName: slower
storageSize: 750G
logStorageClassName: faster
logStorageSize: 200G
You can specify specific resources requirements for the tt and the daemonlog containers. For example, you can tell Kubernetes that the tt container will require four CPUs and 20GB of RAM.
To do this, specify the tt and/or the daemonlog containers in the containers element in your TimesTenClassic object. In so doing, the Operator copies the resources datum from those containers verbatim into the definition of the container in the StatefulSet in which the Operator creates. Any other datum other than resources is ignored. If you do not specify resources for the tt container, the resources item is empty. There is no default.
The TimesTen memory and disk requirements are the same in Kubernetes as in any other environment. See "Storage provisioning for TimesTen" in the Oracle TimesTen In-Memory Database Operations Guide for information.
If you do not specify resources for the daemonlog container, there are defaults. (Note that the values are case sensitive. For example, "20Mi" is valid, but "20mi" is invalid.)
The defaults are:
memory:"20Mi"
cpu:"100m"
This example illustrates how to specify the resources requirements (represented in bold) for the tt and the daemonlog containers.
apiVersion:timesten.oracle.com/v1
kind:TimesTenClassic
metadata:
name:sample
spec:
ttspec:
storageClassName:oci
storageSize:250G
image:...
imagePullSecret:...
template:
spec:
containers:
- name:tt
resources:
requests:
memory:"512Mi"
cpu: "1000m"
limits:
memory:"768Mi"
cpu: "2000m"
- name:daemonlog
resources:
requests:
memory:"40Mi"
cpu: "200m"
The Operator configures a replicated pair of TimesTen databases that can be used to provide high availability. However, in order to provide the appropriate level of high availability, you can control the placement of the TimesTen Pods in your Kubernetes cluster. For example, you may want to ensure that the TimesTen Pods are available in different availability zones, or are on different Kubernetes nodes.
Given that the requirements of every environment are different, the Operator does not attempt to control Pod placement. However, you can do this by specifying the affinity option in your TimesTenClassic object's spec's template. The Operator will pass the template to the StatefulSet that it creates.
See "The TimesTenClassic object type" and "Understanding the deployment process" for details.
For example:
apiVersion: timesten.oracle.com/v1
kind: TimesTenClassic
metadata:
name: sample
spec:
…
template:
affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 1
podAffinityTerm:
labelSelector:
matchExpressions:
- key: "app"
operator: In
values:
- ds1
topologyKey: "kubernetes.io/hostname"